[bug #53703] FT232H based programmer returns all 0xFF when reading flash from atmega2560 #474
Labels
bug
Something isn't working
Comments
|
This patch may be a valid one. I will try to set up my FT2232H based programmer to carry out this test. |
|
It seems to me that I can not flash the ATmega2560 with avrftdi (JTAGKey-2 FT2232H based). I will carry out more tests. |
|
Reading also has some problem with content mis-match but not really returns all 0xFF. But using the bootloader and AVR Dragon shows that verification failed at 0x1e000. |
|
Readback differences using FT2232H and AVR Dragon. Using the wiring bootloader to verify -- this shows that AVR Dragon is correct. mega2560_test_dragonisp_read.hex.txt |
|
I can confirm the patch here fixed the reading issue for me. |
|
It also fixed the write issue for me. Before the fix: After the fix: |
|
@dl8dtl and @mariusgreuel My test shows that the patch (I applied the patch on git head) is good. Please apply. Thanks. |
This was referenced Jun 8, 2022
|
Thanks for spending your time and testing this patch! As I don't have any 2232 hardware, @dl8dtl or @mariusgreuel should take a look at this. If they approve, someone should create a PR so we get this fix into the main branch. |
|
Both the old and patched code look fishy. Isn't the purpose of a lext command to set the upper 8 bits of a 24-bit address? To me, it makes little sense to trigger this based on the state of the lower 16 address bits. We need to send an lext when the upper 8 address bits do not match the CPUs upper 8 bits, i.e. the first time we start programming and every time the upper 8 address bits change. Could you try programming a hex file that starts at at address 0x1000? I would assume that breaks the patch. |
Yes I will try. If you can come out with a more proper fix, I can test it out as well. |
|
@mcuee Thanks for all your help! Thinking about this, 0x1000 should probably be 0x11000. |
|
@mariusgreuel Sorry it takes a few iteration for me to generate the correct test hex file. So I have deleted a few posts to avoid cluttering this issue. And you are exactly right, the patch here is not correct. It will fail with the contents starting at 0x11000. |
|
The test hex file is usng the ATmega2560 stk500v2 bootloader contents plus extra contents at 0x11000. The extra contents were generated by srec_cat. |
Is the fix something like this? Or probably the command set is different. |
|
Apparently the test file exceeds 256KB and I need to redo the test with a proper hex file. |
|
@stefanrueger merged hex file |
Yes it is, but why do you want to combine the files? You can use multiple @mariusgreuel is correct in his analysis. It is clear from the code that programming a file that starts at 0x11000 will not work. (no tests needed). There are examples in stk500.c how to treat sending the LOAD_EXT_ADDR command only when needed. If you want a real quick fix then always send the LOAD_EXT_ADDR command when it exists for the part a la That will do. As it is for paged read/writes and as the ATmega2560 has a page size of 256, programming 65k will draw 254 redundant load extended address commands at some 8(?) bytes traffic each, so programming might take 3% longer - you probably won't even notice. |
|
@stefanrueger Still I think my original hex file (simply combined the two files using Notepad++) is still valid for this test as it is using programmer and not bootloader. So 261414 bytes size is still okay and within the 256KB range (262144 bytes). It is not valid for the #994 test since that was for the bootloader (262144 - 768 = 261376). |
@stefanrueger |
|
Test hex file creation (maybe there are better ways to create the offset hex files from the base hex file). |
|
Great. This works perfectly. |
stefanrueger
added a commit
that referenced
this issue
Jul 4, 2022
Fix Issue #474 FT232H support for ATmega2560 et al (load extended address)
|
Fixed in PR #998 |
stefanrueger
added a commit
that referenced
this issue
Jul 4, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Christoph ceaich@gmx.de
Thu 19 Apr 2018 10:07:59 PM UTC
Programmer hardware: FT232H
Device type: m2560
avrftdi.c does not send load extended address byte command when address is lower than 64k word but using a device which need this command. See attached patch for bug-fix.
file #43979: avrftdi.c.patch
This issue was migrated from https://savannah.nongnu.org/bugs/?53703
The text was updated successfully, but these errors were encountered: