mihaigalos
commented
6 years ago Hi luckwaski,
miniboot is doing exactly as it should. If you check out the datasheet [1], the address 0 (reset) is actually a jump to the application code. In this case, a jump to miniboot!
It does this by taking in the original application and modifying only the first 2 bytes, the ones you identified! If it wouldn't, miniboot would never run again. The 003C is the machine code to jump to the default address of miniboot, futher up in the Flash region.
See, you've already learned something useful today!
Mihai
On Fri, Jul 6, 2018 at 2:34 PM, luckwaski notifications@github.com wrote:
Hello, for few days now I'm debuging a weird issue with miniboot. I'm attaching arduino sketch file + hex sources that will fill i2c memory with a program. Then after a bootloader is loaded to device it starts loading data to internal flash, and then the soft wont start (it just loops on main() of the miniboot as theres nothing to update due to timestamps).
By downloading flash to hex I have noticed that 2 bytes of the code sitting in flash are beeing changed. Whats funny - its always the same bytes, and the resulting "corruption" always have the same values..
What bootloader put in flash: :200000000C94003C0C9452010C9452010C9452010C9452 010C9452010C9452010C9452015F
What does the original data in eeprom look like: 0C942A010C9452010C9452010C9452010C9452010C9452010C9452010C945201
Bolded the issue. The atmega, and eeprom are fine. Any idea?
Thank you what_bootloader_put_in_flash.zip https://github.com/mihaigalos/miniboot/files/2170501/what_bootloader_put_in_flash.zip
test.zip https://github.com/mihaigalos/miniboot/files/2170496/test.zip
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/mihaigalos/miniboot/issues/4, or mute the thread https://github.com/notifications/unsubscribe-auth/APrm0qcFYnCAk92HLDv-GKYCwtbq9gN2ks5uD1k7gaJpZM4VFYrf .
Hello, for few days now I'm debuging a weird issue with miniboot. I'm attaching arduino sketch file + hex sources that will fill i2c memory with a program. Then after a bootloader is loaded to device it starts loading data to internal flash, and then the soft wont start (it just loops on main() of the miniboot as theres nothing to update due to timestamps).
By downloading flash to hex I have noticed that 2 bytes of the code sitting in flash are beeing changed. Whats funny - its always the same bytes, and the resulting "corruption" always have the same values..
What bootloader put in flash:
:200000000C94**003C**0C9452010C9452010C9452010C9452010C9452010C9452010C9452015FWhat does the original data in eeprom look like:
0C94**2A01**0C9452010C9452010C9452010C9452010C9452010C9452010C945201Bolded the issue. The atmega, and eeprom are fine. Any idea?
Thank you
this_is_saved_to_eeprom.zip
what_bootloader_put_in_flash.zip
test.zip