Atmega2561 freezing after burning (TFTP)

[janioanselmo]

Hello, I'm having a problem after TFTP file transfer (.hex). When I make simple firmware recordings, such as "blink" (size = <5kB), I succeed! However, when I transfer (by TFTP) my complete code (size = 110kB) the Atmega2561 freezes, does not initialize/freeze. What happens is when I use the USB recorder (USBasp) everything happens normally, successfully! That is, I have problems with TFTP (AVR-Bootloader). I do not find anything about, or similar questions around here. I will leave some information that may be relevant:

makefile.in: MCU = atmega2561 EMB_FLASHEND = 0x3FFFF EMB_BOOTLOADER_SECTION_START = 0x3FC00 EMB_LINKER_SCRIPT = -T ../make.files/eth-avr6.x F_CPU = 16000000 EMB_BOOTLOADER_FLAVOR = 1

size.txt: device_002.sizeelf: section size addr .data 0x0 0x800200 .text 0x34a 0x3fc00 .bootloader 0xe3c 0x0 .bss 0x30f 0x800200 .eeprom 0x72 0x810000 .comment 0x11 0x0 .note.gnu.avr.deviceinfo 0x40 0x0 .debug_aranges 0x1e8 0x0 .debug_info 0x2ece 0x0 .debug_abbrev 0x1678 0x0 .debug_line 0x10a3 0x0 .debug_frame 0x4c8 0x0 .debug_str 0xc7b 0x0 .debug_loc 0x11dc 0x0 .debug_ranges 0x148 0x0 Total 0x9190

BL_CODE_START 0x3EDC4

Note:

• When, I am reducing/deleting the internal functions of my "complete code (110kB)" it initializes, however it hangs/freezes in other functions. Completely unstable;
• I am using Arduino IDE 1.8.5 and the code is: 15% ROM and 37% RAM, with size of 110kB;
• Card package: https://github.com/MCUdude/MegaCore
• USBasp Recorder.

[hubsif]

@janioanselmo Funny that you posted this only one day ago! Because I just ran into the same issue, though I luckily had some more specific indication: My new code would not run whenever it exceeded ~32k of flash memory!

So, I did some test: I had the bootloader write the new code, then read the flash with the programmer and compared. I found that the bootloader only writes 32768 Bytes to address 0x7FFF, everything after that is left unchanged.

Hopefully, this will help @cniweb to better find the bug and fix it. Meanwhile, I'm going to have a look at the bootloader code myself, but my C and AVR knowledge might be too poor and rusty to fix that.

[janioanselmo]

Wow, I'm very happy to see that answer! I was looking for people, on the internet (Google, Github) but, no one with that problem! I was sure this problem was with my code! So as I have this problem a few months ago I will put some more information that might be important for all of us:

1) Through surveys, in the original code (https://code.google.com/archive/p/avr-etherboot/), was developed by a very specialist group of Germans (or the majority); 2) They used (2008-2009 season) a forum (also in German) to exchange information on development. I do not know anything about the German language, so I used Google Translator =) 2) I realized that the main and most important topic (at least for me) is: https://www.mikrocontroller.net/topic/105078; 3) In this link above I found a lot of help, like for example: Do not use EEPROM area with address less than 114 bytes. Because, to this address, TFTP bootloader information is stored; 4) The development of the main files of this TFTP bootloader is Mr. Jan Krause! I even sent him an e-mail about this case. That is, if the email is still what is inside the files; 5) In the forum that I cite above, has a single comment that a user tried to send a file of ~50k per TFTP and presented problems. The indications were: changes are the two "unint32_t" in the two assignments of the "BaseAddress", inside the file "etherflash.c"; 6) I have made the changes, however, as a consequence, the flash start and end positions are changed. And I need to do it calmly and carefully. I'll keep you posted.

Obsertions: Let's stay active, then, you have been my last hope of solution. Thanks for everything!

[cniweb]

I took over the project from Google Code because no one else developed it, I thought it was dead. So that it does not die out, I took it over on GitHub and try to develop it further. @janioanselmo Please keep us up to date. Thank you

[janioanselmo]

Hello, @cniweb first of all, thank you for your response! I'm glad you took over the project! I will dedicate myself to this solution and for sure, I will keep everyone informed - @hubsif! Thank you!

[hubsif]

@janioanselmo We might have different issues here: I think the issue mentioned in the forums (luckily I am German ;) ) most probably is about extended (32bit) addressing in Intel HEX files (see https://en.wikipedia.org/wiki/Intel_HEX#Record_types, code 0x04). To me it seems the "baseAddress" (upper 16bits) calculation gets fixed by the (uint32_t) changes. My issue, though, is that the bootloader won't write beyond 0x7FFF addresses, which is weird, because it is not an extended address, no (unsigned) 8 or 16bit boundary, no special flash area or similar. So, there's actually no obvious reason for it not to work - yet it doesn't. But so far I haven't gotten far. I couldn't even get the bootloader modified to write hardcoded data to some hardcoded address when it starts. But I will keep trying.

I have made the changes, however, as a consequence, the flash start and end positions are changed.

This I don't understand. What do you mean by the "positions are changed"? I think the only thing that should change, is that your bootloader code becomes slightly larger and thus needs a little bit more flash space..

[janioanselmo]

Hello, @hubsif First, I want to thank the EXCELLENT explanation of the "baseAddress"! I believe my forum translations (German-English) were not correct. I was working the wrong way! I fully agree with you! Really, it's weird he does not write in addition to 0x7FFF addresses. And about the "changes" were about the "uint32_t" that had changed to "uint64_t" the wrong way, now I know! And so I think we would have to (possibly) change "FLASHEND", "STAT_BLSECSIZE".... But, now with the understanding you passed I realized I was in the wrong solution! I'll continue, and post new information. Sorry for the mistakes and thanks for all your help!

[hubsif]

Hi guys, I finally found the culprit for my issue: First, I noticed that my code after 0x8000 actually got written to the flash - just not at the desired 0x(0)8000 address, but at 0x38000! I then realized it must have to do with the page address ("currentAddress") that is written and that it gets not calculated correctly.

In file etherflash.c#L531 I then added a cast and changed

currentAddress = baseAddress + (lineBuffer[1] << 8) + lineBuffer[2];

to

currentAddress = baseAddress + ((uint32_t)lineBuffer[1] << 8) + lineBuffer[2];

and Hooray! my code uploaded correctly via TFTP!

I then decided to dig even deeper and find out what's going wrong here. I even had a look at the generated assembler code, but from my poor assembler knowledge all that I can tell is that it looks ok with the uint32 cast and without the cast some weird calculations I don't understand are made. Since the calculations work just fine in a normal c program, I assume it's avr-gcc special.

So, issue resolved for me. The only thing that keeps bugging me is why only I experience this issue...

---

Ah, and in case someone stumbles across here, I found another bug in the code: The flash is not written correctly when the Intel HEX code is non-contiguous, meaning there must not be any address gaps in the hex file! So, always make sure the hex file meets this requirement.

(@janioanselmo I doubt it, but perhaps that's related to your issue?)

[janioanselmo]

Hello, My friend, @hubsif you are incredible! Congratulations! You solved my problem too! I'm here celebrating (and a lot), I was practically a month with this case. You have a great technical knowledge. I am happy to know that I was close to the problem (currentAddress) ... I leave here my true thanks to both of you - @hubsif @cniweb . If you can help with anything, I'm at your disposal! Have a good job!

[cniweb]

Great that the problem was solved! Can I install the code change right away?

[cniweb]

PS: The same is here: https://github.com/cniweb/avr-etherboot/blob/de8dc8d92fe4e819b6a68be3e8e1acc2aa5b3179/etherflash.c#L566 and https://github.com/cniweb/avr-etherboot/blob/de8dc8d92fe4e819b6a68be3e8e1acc2aa5b3179/etherflash.c#L584

[janioanselmo]

Hi, @cniweb @hubsif Well observed, I agree with your considerations! Congratulations to all of you! I did several tests throughout the day, and all of them with success!

[cniweb]

So can I incorporate the change?

[hubsif]

I think you can go ahead. But the baseAddress changes in the mikrocontroller.net forums include more casts, don't know if they're necessary.

If you like, I can create a pull request containing all casts and include the other atmega2560 changes.

[cniweb]

Yes, you are welcome to help me and make a pull request, thank you.