Basically the patch makes the LIB do the same when jumping to the APP, as the bootloader does when jumping to the LIB: It reads the startup entry (reset handler) from the interrupt vector instead of using a hardcoded address of the startup entry. Using IAR5,app can not work,it means the start address of the app part is wrong.GCC can not work,I think, they have different reasons.Įxactly this issue should be fixed by the patch I suggested in viewtopic.php?p=4498#p4498. If not, it will jump to the lib part.Īt the end of “main” function, it will jump to start address of the app part. It will detect one GPIO to determine whether or not to upgrade. I used IAR5.0 to compile Ben’s code,it passed. The bootloader(just IAP) was compiled by IAR4.X constantly. So whether the intermediate format is elf or ubrof does not matter. The “real” binary content gets stripped out of the elf file into the bin (or dfu) file, which gets loaded on the Nano. Now,I realise that is not the real reason. IAR4 uses UBROF that is IAR’s private format, yet IAR5 and GCC use ELF. Initially, I thought maybe the different binary file format made the issue. I am just learning about GCC,IAR and the startup code. It compiles and links fine,but the final hex file can not work.I just got a blank screen on my DSO.
0 Comments
Leave a Reply. |