Timeline for AVR program upload overrides unrelated program area
Current License: CC BY-SA 4.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 11, 2019 at 12:45 | comment | added | Dankó Dávid | Randomly: On the original device, after 6 code upload it happend. On a new device, i've uploaded new code at least 15 times but still no error. Ok, maybe it is a device (instance) specific error, but when later happens on a deployed node it will be very frustrating. | |
| Oct 11, 2019 at 12:43 | comment | added | Dankó Dávid | More precisely, i meant a whole page between 0x100 and 0x180 (well yes, i've missed the 0x notation). That shows that erase executed successfully but the write sequence got broken. Meanwhile i try to reporduce this failure on other device, but i can't. Because this failure happens randomly (or for ahidden reson), it makes to reproduce much harder. | |
| Oct 10, 2019 at 11:06 | comment | added | Juraj♦ | so you meant the page at byte address 0x100, not the 100th page | |
| Oct 10, 2019 at 9:31 | comment | added | Dankó Dávid |
So the application area is between 0x2000 and FLASH_END. To override the area i shown in the dump (0x100-180) i, or something* should calls this function with page = 0x100. When this happen somehow, this guard conditions rejects the call. ( note to i or something*): Like restart to bootloader mode, where the execution can walk to this flashing function with uninitialised values, which prevented by the "jmp 0x0" instruction, placed right before this function. Months ago that made randomly failures .
|
|
| Oct 10, 2019 at 9:18 | comment | added | Dankó Dávid |
The host program (which accepts the uploaded code and implements also other functionalities) is placed between 0x0-0x2000. And that host program writes the received paged to the flash area between 0x2000 and FLASH_END. The condition page < 0x2000 should prevent to write any page under the application area (prevent to overwrite the host). This condition page > 0x7900+SPM_PAGESIZE added because documentation says nothing about what happens when you call boot function with higher addresses than we have on flash. Condition size > SPM_PAGESIZE is yet another check for failure condition.
|
|
| Oct 9, 2019 at 9:46 | comment | added | Juraj♦ |
but I don't understand why it is a problem that the page 100 at byte address 0x3200 is written and how and why should the if(page < 0x2000 || (page > 0x7900+SPM_PAGESIZE) prevent it?
|
|
| Oct 9, 2019 at 9:27 | comment | added | Dankó Dávid | It can. However the variable name 'page' is a bad name for that, it's actually stores the start address of the page, not the page offset itself. (This name comes from the original source of this flash function: nongnu.org/avr-libc/user-manual/group__avr__boot.html) There's no call example attached, but this code worked prevously with shorter codes to upload and absolute code addresses. | |
| Oct 9, 2019 at 4:08 | comment | added | Juraj♦ |
then the 'guarding' if can't apply. so what is the problem?
|
|
| Oct 8, 2019 at 21:18 | comment | added | Dankó Dávid | Yes, the 0x3200 is the 100th page of the memory. (On the atmega328, the SPM_PAGESIZE is 128. The 0x3200 in decimal is 12800.). Hmm, that address is acutally writeable and previously i uploaded only shorter codes (under 2 Kbytes, so under the 0x2000+0x800). Maybe that's the root of this weird connection, but i don't have an idea how they connected. | |
| Oct 7, 2019 at 20:05 | comment | added | Juraj♦ | doesn't page 100 start at 0x3200 byte address? | |
| Oct 6, 2019 at 4:28 | history | asked | Dankó Dávid | CC BY-SA 4.0 |