orempel
commented
4 years ago Hey! Unfortunately I've never adapted the twi part of multiboot_tool for a twiboot without clock stretching. And for a Raspberry Pi I2C master you need to disable the clock stretching (that was the target/reason I've implemented it).
As a workaround you could add an usleep() with 5000-10000us after each successful twi_write_memory() in twi.c: https://github.com/orempel/multiboot_tool/blob/1d3988981854bc3dfc730d993309b63c3015639d/twi.c#L409 After that period twiboot should be reachable again (at least for flash page writes, multiple eeprom byte write could take much longer).
A cleaner solution would be to retry the write access multiple times (say < 10) with a small delay in between. Thats how I solved it in the ispprog twiboot bridge code (https://github.com/orempel/ispprog/blob/2d9c71bb8b3224d17fc47bb6c24b5fc33dc2df06/twi_master.c#L115). I will try to implement something like that in the next days..
As for the reading, the hex output tries to be smart and skips all addresses with 0xFF. Thats why you see different start addresses with 0x7F as first byte. But the value 0x7F "smells" a bit strange.. I2C uses MSB first, and the bit before D7 is a previous ACK.
- Can you check if multiboot_tool maybe uses an higher TWI frequency then normal.
- Do you have SDA/SCL pullups?
- Is this by chance an mixed 5V/3V3 system (Raspberry I2C master using 3V3 and the AVR using 5V, and the SDA/SCL pulls are only to the 3V3? So the AVR "sees" a high only after longer period?)
The observed LED behavior is correct. When twiboot is not accessed it will timeout, disable the LED, wait for a short duration, jump to the (empty) application area and then eventually start again. Thats why you see the 20Hz flashing with small pauses in between. When it is accessed, twiboot will stay active, thus the LED keeps flashing. When an operation completes (eg. reading) the bootloader is exited and the flashing/pause behavior starts again.
jl-lewis
I've gone over my settings/configuration for building both twiboot and multiboot_tool, and I don't know for certain if the problem is isolated to one or the other.
twiboot seems to build and program without issue.
I'm building and running multiboot on a raspberry pi. I haven't made any changes to it.
I've left clockstretching off in twiboot, but I'm not sure which way multiboot is handling things. The raspberry pi as far as I can tell does not have support for clock stretching, but I could try that option.
When writing a .hex file to twiboot, I get:
When trying to write, it shows progress and completes without error, but I get erratic results.
Sometimes I get only around 8 lines read back and then end line, and sometimes I get what appears to be the entire flash or at least a much larger amount of it (but mostly empty yet oddly with the first byte on some lines being "7F" instead of all "FF"). Sometimes even when no file has been written, so application space is blank, I get the "7F" at the beginning of the data record and erratic address start point. The address at start of .hex can vary, often 0000 but sometimes some other value, and sometimes the overall length of .hex varies, just from one read-out attempt to the next. I have tried multiple application .hex files that I have tested before and still have the same result. There are no other devices on the TWI bus, and this is a board with known working TWI bus. There's always a chance of bus errors, but that should not cause failure every attempt. On writing, it appears multiboot will do a verify, but that does not seem to be what's engaging here as it's not making it that far.
I have noticed that I get the 20 Hz LED as expected, and I can see every 1 second that the bootloader presumably loops, causing a very slight blip off of the LED. Though, when I run the write operation, the light stays stead at 20 Hz with no 1 second blip. Perhaps when the write fails something in twiboot(AVR) is hanging? The bootloader still responds to new operations and after doing a read operation (which succeeds, more or less), then the LED returns to normal operation.
Other details:
I'm using USBasp for programming so I added the options for that to Makefile. AVRDUDE_PROG := -c usbasp -b 115200 -P usb
I switched one of the LEDs to one my application has available, so I can get visual confirmation (B5 -> B7).
I'm using atmega328p, so that is also set in Makefile.
Fuse settings seem OK as-is. Normally I have used the longest startup time delay, though with internal oscillator, 65ms certainly should not be necessary with internal oscillator. Maybe the 4 ms option is fine, and the settings used here in twiboot are no additional time delay. That should not be a problem? It has not made a difference when I tried 4 ms vs 0. Later I added '-e' to the fuse setting line, to do a full erase at that point, so I always do that first and then install. Did not change the issue but I think should be safer and also resets lock. Also '-v' to fuses and install lines but that's verbosity and shouldn't affect anything. I've tried doing the avrdude calls different ways, but hasn't made a difference that I can see. Unless anything is wrong with how I typically do it, these are the lines that seem best and also protect the bootloader after:
Some of these changes are on the fork I made on GH, but now that I'm just guessing at things to try, I haven't pushed anything to that fork. Thanks if you can provide any insight or more steps I can take to determine what's going on!