Using Raspberry Pi or similar as I2C boot master directly #20
Replies: 9 comments 12 replies
-
|
Ah, I think for the second question about reset, the convention is that the running program, which is an I2C slave anyway, should implement RESETMCU - and in the blink example that's done by turning the LED off and then enabling the watchdog timer to force a reset within a few milliseconds. I guess a low signal on the REST button would also assuming the fuses allow it. |
Beta Was this translation helpful? Give feedback.
-
|
Hi, just a minor clarification, it is also possible to update the Tiny85 starting from firmware published on a website. This is particularly useful for remote systems where using a serial connection is inconvenient. Here is an example to take a look, the update path would be: Website ... WiFi-AP---))) (((--- ESP8266 --- I2C ---> Tiny85 Now, to your question: Yes, it would be possible to upgrade the Tiny85 from the RPi. It is exactly as you say, you must implement the protocol master side on the RPi, so the RPi would replace the ESP8266 in the I2C master role. This configuration already should be part of this project, but to be honest, I have been procrastinating to adapt the master protocol library on the RPi, always appears something with higher priority to do ¯_(ツ)_/¯ The I2C master functions to control the bootloader are all in this C++ library for Arduino, it would be necessary to compile it for RPi, or else copy its functionality in another language, e.g. Python, as you mentioned to support: RPI---i2c--->Tiny85 The bootloader starts automatically after a Tiny 85 reset, so when you power-cycle the chip or reset it, Timonel takes control of the chip. If the I2C master initializes it, it waits for the commands, e.g. to receive new firmware. Otherwise, it tries to start the current firmware stored in flash memory. If the physical reset pin is not available or is not easy to power-cycle, it is possible to reset the chip through the user application. For this, the application has to "understand" I2C and respond at least to the RESETMCU command, as you mentioned. The risk of this configuration would be to forget to include the application's I2C support on an update. Then controlling remotely the bootloader start would be lost, it would have to be physically restarted. Among the examples, there is a "blink" for the Tiny85 with I2C support that shows how to do this. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you. The reward for answering well is receive new questions
What should I see? I would hope for evidence that the device is connected. As you can guess, I don't see anything yet. TIMONEL_TWI_ADD seems to be 11 but I don't see it. I will check wiring and all the usual steps but I had expected to see a slave device number. Also when you say "After the tiny 85 reset [...] If the I2C master initializes it, it waits for the commands..." how long will Timonel wait for master to take control of i2c bus, i.e. how long before it gives up and runs the existing firmware? The analogy here (although the tech is different) is the micronucleus bootloader which wants for a configurable number of seconds in bootloader mode before starting any loaded firmware. If I've just burned Timonel there isn't any firmware to start, so does it do what micronucleus does and wait indefinitely? |
Beta Was this translation helpful? Give feedback.
-
|
No problem. Your setup seems correct, I use something even barer for testing, just an ESP8266 as the i2c master, a slave Tiny85, and 4 wires: SDA, SCL, + 3V, and GND to connect them. No pull-ups, no decoupling capacitors. Please check carefully that fuses have been well written. I've found that sometimes AVRdude indicates that fuses have been correctly configured, but have not been modified, especially with cheap programmers like USBasp. Until it works, maybe it would be better to use any ESP8266 as I2C master (NodeMCU or bare modules) if you have one. This way you can run any already tested sample application. These applications also allow interaction through a serial terminal, making debugging easier. I would also suggest flashing the Tiny85 with a "not-so-small" Timonel setup, which allows for more interaction. Later, when it works, you can change it to another one that optimizes the space freed up for user applications. Initially, I would go with a config like this that I just added "tml-t85-test-comm", which allows:
Just make all again with Regarding the waiting for initialization by the I2C master, Timonel has two operation modes controlled by the "APP_AUTORUN" option. If it is "true", then it will "wait" for as many cycles of the main bootloader loop as this variable indicates:
If it is disabled "false", then it will never jump to the user application, it will wait forever and the application start must be ordered by the I2C master by sending an "EXITTMNL" command. This setting is useful for multi-slave setups, where updating each Tiny85 on the bus is not that easy if they start their user applications automatically. |
Beta Was this translation helpful? Give feedback.
-
|
Better news! I refreshed my repo, so I have the latest diagnostic build that you mentioned, and went over my circuit with a fine-tooth comb. Guess who discovered no less than three breadboard wires that were open circuit :( Much better now - i2c reports a device on address 0B (11) so that's on track and ready to play. |
Beta Was this translation helpful? Give feedback.
-
|
Glad it worked and that you can discover the "Timonelized" Tiny85 over the I2C bus. The next step would be initializing the bootloader. As the "test-comm" configuration you flashed expects "one-step" initialization, you have to send a "GETTMNLV" (0x82) command from the I2C master to slave 11 to do it. With this, the LED on PB1 should stop flashing and the bootloader gets ready to receive commands. If you need anything else, just drop a message. |
Beta Was this translation helpful? Give feedback.
-
|
I'm wondering about the choice of low fuse values. It looks like all your configurations have 0x62. My barebones tiny85 isn't reliably entering the bootloader on powerup. After programming tml-t85-test-comm the first time, the led on PB1 flashes. But subsequent power-ups don't seem to work. It might be the characteristics of the power supply - I measure 4.8v on Vcc but the BOD/SUT flags in the low fuse might be a bit optimistic if the power supply isn't great. Running 1 MHz
I realise this is hardware but for tml-test-test-comm what would recommend as the most tolerant for less than perfect hardware |
Beta Was this translation helpful? Give feedback.
-
|
Yes, low fuse = 0x62 is the default bootloader setting. This sets the chip to use the 8 MHz internal oscillator and the divider by 8 activated as system clock: a 1 MHz clock, the factory setting. If you take a look, you will see that this can be "overwritten" by the flash-timonel-bootloader.sh script second parameter, e.g. I've tried all clock options presented in the script and they all work fine. The options are intended basically to adapt the chip speed to what the user application needs. Timonel, regardless of this configuration, puts the chip at maximum speed during its operation (16 MHz approx), then, when jumps to the application to exit, it returns the chip to the clock speed configured for the application. Regarding the bootloader reliability after powering the chip on, I've never had the problem you mention. However, if the power supply is not reliable, perhaps the brown-out detector is resetting the chip, you could try disabling it completely (high fuse = 0xD7). A 4.8v power supply should be OK, although the current it delivers should also be stable at startup. If Timonel starts well when the AVR programmer is connected, and it does not start when disconnected, most probably is a supply problem. |
Beta Was this translation helpful? Give feedback.
-
|
Gave up on using an RPI host for now. There's something I'm definitely not getting there, either my particular hardware or maybe some known problems with the RPI implementation of clock stretching. Instead I tried using a regular PC to communicate with the boot loader. I burned the firmware for Burned the Installed smbus2 python library with Ran following python script to read the timonel version. #!/usr/bin/env python3
import smbus2
addr = 0x0b
w = smbus2.i2c_msg.write(addr, [0x82])
r = smbus2.i2c_msg.read(addr, 12)
with smbus2.SMBus(9) as bus:
bus.i2c_rdwr(w, r)
print([hex(x) for x in r])LED went out, the output is ['0x7d', '0x54', '0x1', '0x5', '0xeb', '0x30', '0x19', '0xc0', '0xff', '0xff', '0xe2', '0x2']I checked the first few bytes, looked reasonable, although I was a bit surprised to see the major/minor reported as 1.5 ... should I expect 1.6? This proves the communication from a PC is possible. It is of course some way from a functioning boot loader script, but maybe this will inspire someone to take it forward. I would be happy to collaborate if I can. |
Beta Was this translation helpful? Give feedback.
-
|
It's a shame the RPi didn't work as i2c master. I'll face an RPi master library as soon as I finish adapting Timonel for ATmega328 and the like. That is, to run on chips with i2c hardware and bootloader partition.
Awesome, I had never used a PC as an i2c master. The I2C-Tiny-USB project is very interesting too, I'm going to take a look at it as soon as I have some spare time.
You're right, tml-t85-test-comm has the
That's OK! By this time I guess you already took a look on the i2c command list spreadsheet to grasp the expected handshake. As for the bootloader version, is v1.5 if you're using the master branch. The v1.6 is on its own branch that I'm still checking before merging. I just realized that the master README already mentions the v1.6 release, which is confusing. It's something that sneaked out, it will be fixed with the merge and release. Anyway, since v1.6 only adds support for other ATtiny models, in practice there will be no difference on a Tiny85.
That's great! I can't promise to work thoroughly on it right now, as I commented above, but count on me for any support you may need, just drop a message ... |
Beta Was this translation helpful? Give feedback.
-
|
For the record, good descriptions of "clock stretching is trashed" on the PI can be found here https://www.advamation.com/knowhow/raspberrypi/rpi-i2c-bug.html The canonical solutions apparently are to either limit the hardware clock rate, or to use an alternative bit-bang i2c (lookup i2c-gpio in /boot/overlays/README) |
Beta Was this translation helpful? Give feedback.
-
|
Good information, thank you! It is a problem documented for some time that, unfortunately, apparently is still present in newer RPi models. The "slowing down the read speed" solution seems reasonable, but it would have to be thoroughly tested in the bootloader application case. One thing is losing a couple of sensor readings now and then, but it's another to lose control of a slave device in the middle of a firmware update. Maybe a "bit-banging" i2c master on the RPi is the way to go, but I guess that also would imply lots of testing to make it reliable enough for firmware updating. |
Beta Was this translation helpful? Give feedback.
-
|
I'm getting the hang of this and am making some progress with a proof-of-concept for python-based bootloader, but I have some some concerns still about the "cold start" behaviour
What I've tried
These made very little difference. It's still prone to failing on a cold start, but one of the two MCUs was more likely to fail on startup than another. It is more noticable running at 3.3V. This is going to be a difficult ask, but can you think of any reasons why startup might have any reliance on some undefined condition. It always does something so I assume the RESET is ok, but what then? It could be hardware, of course. But if there are any things you could suggest, I'm up for a discussion. |
Beta Was this translation helpful? Give feedback.
-
|
It is quite strange what you describe, at this point I would suggest going back to the basics for a moment and trying a simple test program. This program should make a LED on PB1 blink 5 times at 1 second intervals if the fuses are set correctly. Then it speeds up the chip by modifying the oscillator calibration and prescaler, just like Timonel does, so the led should blink rapidly for another 5 seconds approx. After that, it returns to the original setting and continues blinking at 1 second intervals. If the initial 5 flashes were not every one second, then the fuses are probably misconfigured. If the chip does not accelerate after 5 seconds, you may have a hardware problem. If so, it is difficult for the bootloader to work properly, as it is quite sensitive to speed. If you decide to try this, let me know how it went. About supply voltage, I have tested Timonel at 3.3V and 5V, it works fine with both, but since I generally use an ESP8266 as I2C master, 90% of the time I use it powered at 3.3V. Please pass me this data to see if I notice anything else on your setup:
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks so much for taking the time to write the test program. avr-gcc (GCC) 5.4.0 Running avrdude -pt85 -cusbasp -Pusb -B4 reports the following fuse values Power supplies: I've tried the following combos and they all seem vulnerable to this intermittent problem
Downloaded the test-10 as advised. From testbed branch https://github.com/casanovg/sw-tests |
Beta Was this translation helpful? Give feedback.
-
|
https://drive.google.com/file/d/1Bh6sLb2XIdQC4ocUJKqfD-AJu2XyORcF/view?usp=sharing Shows T85 on breadboard, powered by standalone PSU at 3.3V. Power switch just out of shot. Pullup resistors for SDA and SCK at left, pullup resistor for RESET at right. The first few powerups get the very rapid flicker. Repeated power cycles eventually get a clean start. It's easier to reproduce at 3.3v but has been seen at 5v. CPU ATTINY85-20PU. Meter reads 3.27 v DC across PSU so it doesn't seem to for lack of power. I don't have a scope to check for AC noise unfortunately. |
Beta Was this translation helpful? Give feedback.
-
You're welcome, your cold start issue really piqued my interest. Until now it had never happened, even after a multitude of tests. As for your setup, it seems correct: compiler (a bit outdated, but it works), programmer, fuses, PSU voltage, and the test program behavior is also correct (the only doubt here is if the slow blinking is at one-second intervals, I guess it is, right?
Thanks for the video, but don't think I'm going to let you go for the Oscar without a fight. I just made two even duller videos, one flashing Timonel on a Digispark, the other flashing it on a bare Tiny85. As you can see, my configuration is even simpler than yours, and in both cases, the LED on PB1 starts blinking as soon as the bootloader loads (three blinks and, then tries to run a user app, and so on). In the bare Tiny85 video, I power-cycle the chip to show how it starts again correctly. I am attaching the .hex file that I built for the videos so that you can flash it on your device if you wish so : tml-t85-test-comm.zip. I would also like you to send me the firmware that your Tiny85 has for testing it. Please get "tml-t85-onboard.hex" with the next command:
This time I did the tests by setting the Tiny85 to 8 MHz (Lfuse = 0xE2, Hfuse = 0xD5, Efuse = 0xFE), if you can, try it like this too. In both cases, I feed the chips with 5V from the USB through the programmer. |
Beta Was this translation helpful? Give feedback.
-
|
Here is a video of your 5-blink test I will try the other steps later and report back. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, the test program behavior looks good, the 5 initial blinks timing seems to be every 1 second. While, as you know, the internal RC oscillator can have subtle variations due to temperature and supply voltage, the AVR fuses are set for 1 MHz in this case. |
Beta Was this translation helpful? Give feedback.
-
|
I must be honest, I'm losing the plot slightly here and it may be worth putting this investigation on hold for a while. After being away from the house a few days, I tried the exact same circuit and found that the AtTiny85 was unreachable by the programmer and may be dead. Maybe it was "on the brink" last week and finally gave up? Frankly, I'm confusing myself more than anything else. It could be poor hardware, but it's so hard to reproduce. For the moment, I think it best to focus on my main goal which was to write a prototype Python loading application. (haha, see the title of this thread). I am going to focus on that, and if I see any patterns emerging maybe we can come back to the detective stuff. PS your video. Have not heard Aztec Camera for a long timw! |
Beta Was this translation helpful? Give feedback.
-
It's okay, if at any time you want to retry and still have problems, just let me know to try to help.
Remember that you always have the HVSP option (simple or elaborated) to save a Tiny85. If you decide to try again at some point, please remember to test with these fuse settings: L=0xE2, H=0xD5, E=0xFE, I think it can be simpler with a higher clock speed.
Yes, it makes sense, the avr-gcc version I used to compile the one I posted above is 9.2.0 for Linux, while the one I used for the GitHub release is 8.3.0 for Windows. Different compiler versions usually produce binaries of different sizes.
Sounds good, if at any point you have something to try on the master side, just drop a message. After all, I have the "bootloader side" working :-)
Yeah, those good bands from the '80s! |
Beta Was this translation helpful? Give feedback.
-
I can see from the README etc. a mention of using a Raspberry PI as a way to update the firmware in the Tiny. The examples shown all involve a serial connection from the computer to the I2C bus master via serial, and then triggering an update from there
Computer ---Serial--> NodeMCU ---i2c---> Tiny85.
Suppose I have a Raspberry PI connected to a Tiny85 via the RPI's I2C bus, with the Tiny as I2C slave reporting to RPI as master. So the hardware connection already exists. It seems possible for the RPI to do what the NodeMCU does in the example above to upload new firmware.
RPI---i2c--->Tiny85
This is very attractive in theory but I can't see how to do it. Let's assume I have python or similar language on the RPI, could I work through the protocol and upload a hex file from there without needing some nodemcu intermediary? I presume I can.
I'm not entirely clear what triggers the bootloader to start - if I've written an arbitrary program such as blink and uploaded that, the bootloader transfers control over to blink - what makes the Tiny85 running blink enter the bootload on demand? Does it require some activity on the reset line of Tiny85?
Thanks for any thoughts on this. It's not something I need but it is a "nice to have".
Beta Was this translation helpful? Give feedback.
All reactions