ATmega2560 wiring (stk500v2) bootloader flash writing stability issue #994
Labels
invalid
This doesn't seem right
Comments
|
Verified with AVR Dragon as well. |
|
AVR Dragon seems to be okay. And verfied with the Wiring bootloader as well. |
|
The test hex file is usng the ATmega2560 stk500v2 bootloader contents plus extra contents at 0x11000. The extra contents were generated by srec_cat. |
mcuee
changed the title
|
Not only wiring bootloader, the one provided by @stefanrueger here ( https://github.com/avrdudes/avrdude/files/8882669/atmega2560_v3.txt ) in #940 discussion has a problem as well. But the problem may be a bit different. |
You are trying to overwrite the bootloader. Your file is 261414 bytes long, i.e. does not fit into the available flash of 256k minus 768 bytes for the bootloader. My bootloader protects itself from being overwritten, but throws no error when writing (that costs too many code bytes :). You will notice during verification. The |
That is an interesting and unusual address for the first verification error. What I find intriguing is that apparently fails and that works?!? The only difference is 'v' and 'w' in the Perhaps try test files that fit below the bootloader? |
|
Your input file is to blame, I think. |
|
@stefanrueger As for The idea is really to put the offset to the test pattern into offset 0x11000 but apparently it is not correct to simply combine the following hex file with the bootloader hex file. |
|
@stefanrueger |
|
But the stk500v2 wiring bootloader (with eeprom read fix) seems to still have a problem. |
|
Using the optiboot bootloader from megacore from @MCUdude seems to be okay as weel. |
|
BTW, programmer like usbasp and AVR Dragon have no issues. In summary, only stk500v2 wiring bootloader has issues. Full debug log attached: |
|
Would it be fair to summarise that a particular bootloader does not seem to work (stk500v2 wiring) with Have you tried input files that start at 0? Some bootloaders autoincrement the address and ignore any set extended address commands. In this case your input file should have been folded by the defective bootloader into the [0, 0xffff] space. Try to find where your input has been placed (read out the flash and look at it). Anyway, AVRDUDE wouldn't be able to do anything about defective bootloaders... |
|
@stefanrueger They do not bother to fix the issue with regard to EEPROM read for so many years. |
mcuee
changed the title
BTW, putting longer logs into a file is a much better way to give additional information. The best issue descriptions are short and try to pinpoint the problem. I had a glance over the log file, and the protocol send/recv streams seem OK firming up my hypothesis that the bootloader is to blame. (You should prefer mine once I have published them :) |
It seems to write nothing. I can not find the test pattern from anywhere. Here is the readback from usbasp. |
|
Correct - no quick brown fox hiding anywhere. Only an 8k bootloader starting with a vector table at 0x3e000. That doesn't work. |
|
I have some doubts about my own build of the bootlaoder, so I changed to the one used by @MCUdude's MegaCore, but there are quite some warnings and the result bootloader does not seem to work under macOS (time out during writing). |
|
So I go back to the original stk500v2 bootloader hex file from Arduino (with the known EEPROM read bug). Bootloader buring under Arduino macOS seems to work. But the bootloader does not seem to work under macOS (time out during writing). Probably the issue is with the version of avrdude under Arduino under macOS. |
|
Somehow the above process using Arduino under macOS created un-usable bootloader. So I just use usbasp to program the original stk500v2 bootloader (with known EEPROM read bug) using usbasp and there seems to be no issues any more. |
|
@MCUdude The megacore m2560 stk500v2 bootloader burning process seems to have some issues. The following is under Windows. Maybe it is due to the issue of the avrdude version included in Arduino. The bootloader created above does not seem to work. |
|
Going back to the issue with the stk500v2 (wiring) bootloader, it seems to me the issue is with my build of the EEPROM fix. But it is kind of strange that the EEPROM fix will cause issues with flash write. The original official one may just be okay. |
mcuee
changed the title
|
@mcuee I just changed the lock/unlock fuse bits so Avrdude wouldn't complain about setting unused bits. Seems like I'll have to revert that commit and go back to using 0x3f/0x0f. Slightly on topic: The stk500v2 bootloader I've compiled and bundled with MegaCore; does this works as expected (flash read/write, EEPROM read/write) for you? |
Looks like the old version of avrdude bundled with Arduino caused this issue. avrdude-v7.0 is okay with 0xff.
EEPROM read/write is fine. But flash write got problems -- sometimes it times out. I am not so sure why. The official bootloader from Arduino has the EEPROM read problem, but it does not seem to have the flash write problem. |
|
EEPROM is fine. |
|
Flash write sometimes got problems. Example: first time okay, second time not okay |
|
@MCUdude I think your stk500v2 bootloader hex file is fine but my board may have some issue with 115200 baudrate when using the stk500v2 bootloader. I tried the official Arduino stk500v2 bootloader file and I can reproduce the same issue when I tried more times. Same for my own build of the stk500v2 bootloader with the EEPROM fix. I have since closed the following MegaCore issue. |
|
@MCUdude I do not usually need to use this trick with avrdude-7.0. But I think I will give up on the stk500v2 bootloader and use your optiboot bootloader or the bootloader by @stefanrueger mentioned in #940. Both have no issues at all. |
Two programming sessions with optiboot in quick succession can result in a timeout failure the second time, indeed. My hypothesis is that after the first programming session ended optiboot still waits a while for WDT to finally trigger, and any external reset during this period (caused by the second programming session) makes optiboot run the application instead of the bootloader. This hypothesis can be tested by stepping through the optiboot code that decides what to run based on MCUSR. Workaround: Wait a bit longer than the actual optiboot WDT timeout between AVRDUDE runs with optiboot. There is nothing AVRDUDE usefully can do about this, this problem is a side effect of optiboot's desire to keep MCUSR as faithful as possible. I would exclude baud rate mismatch for the observed timeout problems (principally because it always works with my bootloader ;). However, if you see this type of timeout otherwise then it's possible that something is wrong with the timings in AVRDUDE. |
Interestingly I have not seen things like this with optiboot (including your bootloader with EEPROM support) on the ATmega328p (Arduino Uno clones with ATmega16u2 or CH340); only on the ATmega2560 (Arduino Mega2560 clones with CH340). I just did a test to carry out consecutive write (10 times) of the blinky sketch with your m328p bootloader hext file -- and I am not able to reproduce the issue. |
I believe from optiboot v7.0 onwards the "what to start at reset" logic has changed. What is the version of your 328p optiboot? The last two bytes in flash show its version number (at address 0x7ffe for ATmega328P). My bootloaders are different from optiboot and do not exhibit this effect. More crucially, try to see whether waiting between two runs with the stk500v2 bootloader from @MCUdude makes a difference! |
mcuee
changed the title
With the 0x21000 offset hex file, the situation seems to be bad (often failed with 0x45 error and the blinking LED becomes solid RED). I will reopen this issue. Then I need to reset the board for it to work again. And even that does not help sometimes. Waiting do not help at all. |
|
Strange that official Arduino stk500v2 bootloader (with EEPROM read bug) indeed performs better. As long as I wait a bit longer (say 20s), usually it is okay. And even if it runs into problems like Sometimes it will have the error I am not so sure if the fuse settings may play a part. Arduino is using the following. MegaCore is using the following. |
|
The EEPROM bug fix is here. It does fix the EEPROM read issue. I do not think it has anything to do with the Flash write. But strangely even my build of the above fix (same fuse settings as the Arduino as I do not do anything about the fuse) still performs a bit worse than the Arduino official stk500v2 firmware: more prone to the But since there is another possibility that the CH340 clone itself is the problem, hopefully people with official Arduino Mega2560 can chime in and see if the MegaCore hex file is okay or not. |
mcuee
changed the title
|
@stefanrueger Still sometimes it gets the mismatch error. |
|
@MCUdude @stefanrueger The Optiboot version in Arduino Uno is very old at 4.4. It does not support EEPROM. Usually I will use it, unless for EEPROM testing. But I also use your bootloader file mentioned in #940 discussions as it supports EEPROM (maybe I will use it more often from now on), or the big boot optiboot file provided by @WestfW as mentioned here for EEPROM testing. Not so sure about the version number here. I have tested all three bootloaders with very little delay between consecutive runs of flash writing and I can not reproduce the issues. |
I happen to have another Arduino Mega2560 clone with CH340. And it has no Flash stability issues with different hex file (official stk500v2 bootloadder, MegaCore stk500v2 bootloader and the MagaCore optiboot bootloader or the bootloader by Stefan). So in the end, I think this is due to the clone which may have some HW design issues with the reset. I will close this issue again. |
|
Side question @stefanrueger and @WestfW, the big boot optiboot hex file seems to have some warnings if I run the comands by Stefan. Are there any real issues? |
No issues. The warning was caused by -Output_Word and (presumably) the bootloader storing a table with an odd number of bytes.
I am glad you have arrived at a conclusion that looks plausible and explains the issue at hand.
Sorry for the wild goose chase re problems on the second of two consecutive avrdude runs with optiboot. I recall having had this problem in a reproducible way once, but I too cannot reproduce it now. Probably because |
|
Workaround of the reset HW issue is to reset the ATmega2560 before the flash. Interestingly, even though the board may have some HW stability issues (probably reset logic from CH340G to ATmega2560). Somehow optiboot from MegaCore works quite a bit better than the stk500v2 based bootloaders. So I will stick to the MegaCore optiboot loader. The good thing is that it also supports the EEPROM write function. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Using the test hex file and it seems that the wiring bootloader has the same issue as the FT2232H based programmer.
Update: this hex file is not valid for this test. Now the issue is rather on the stability side,
atmega2560_0x11000_offset.hex.txt
The text was updated successfully, but these errors were encountered: