Hi, i have the following problem with a secondary bootloader in LPC54608 custom board. It is very similar to evaluation kit OM13092.
If i load the application program to the address 0x8000 with the JFlash program and later load the bootloader to the 0x0 address, after the reset the secondary bootloader jump to the application program and work OK.
But if the secondary bootloader load the aplication program from SPIFI to RAM and then to flash address 0x8000, after reset the secondary bootloader jump to the application program but it does not work properly ( hard fault ).
We compare how the flash (address 0 to 0x7ffff) is after being recorded, by the jflash and by the secondary bootloader and there are no differences.
If run the application program from address 0x0 ( without secondary bootloader) work OK.
The only way that works is to delete everything with the JFlash, load the application in 0x8000 and then the bootloader.
that could be happening?
Best Regards
Hi Alice :
Sorry for the delay in answering I was without access to the company's mail. About the problem , I was able to make the comparison between, the memory in 0x8000 recorded in the micro by the bootloader, and the .bin file of the compiler, and both are equal.
If the application is well recorded by the bootloader, Can the problem be some configuration?
When for example we flashing the application in 0x8000 and then the bootloader , using the Jflash program, the bootloader when start detect a header valid in 0x8000 and jump to the application. If not application header valid is detected the bootloader try load application from 0x10000000 SPIFI .
The only difference when the application is loaded from SPIFI is that the bootloader use rams for buffering and then flashing. After the bootloader finish of flashing jump to the application with this ram uninitialized. Can be this a problem?
The same application compiled for 0x0000 work OK always, (without the bootloader).
-> Do you meaning, when use JFlash flashing Appplicaiton and bootloader, bootloader can jump to APP, APP also can work well ? YES When using using bootloader get APP code , the flash it to ox8000, it can't work ? YES If yes, I think you need check 0x8000 memory as 1).
Best Regards.
Hello miguel,
If the application code from 0x8000 is the same with two method(directly flash to 0x8000 and copy from SPIFI),
also both can jump to 0x8000, I think it should work. Have you checked debug Disassembly, when copy from SPIFI , does it can jump to 0x8000 ?
"the application with this ram uninitialized."->What about the ram? Application used?
BR
Alice
Hi Alice:
We find the problem , the SystemCoreClock variable it was not initialized, after setting the clock frequency, maintained the default value of 12000000.
Only add this line to code and it started to work well.
The SystemCoreClock variable is used when flashing ram to flash.
Thanks for your advice, kind regards.
De: Alice_Yang
Enviado el: jueves, 18 de abril de 2019 00:24
Para: miguel ibarra <migueli@cointech.com.ar>
Asunto: Re: - Re: secondary bootloader lpc54608
<https://community.freescale.com/resources/statics/1000/35400-NXP-Community-Email-banner-600x75.jpg> NXP Community
Re: secondary bootloader lpc54608
reply from Alice_Yang <https://community.nxp.com/people/Alice_Yang?et=watches.email.thread> in LPC Microcontrollers - View the full discussion <https://community.nxp.com/message/1140967?commentID=1140967&et=watches.email.thread#comment-1140967>
Hello miguel ibarra ,
Please compare application memory data using bootloader load from 0x8000 with only run the application program from address 0x0 ( without secondary bootloader).
Also please pay attention that, before jump to application code, please deinitialize (disable clock) the modules initialized
in bootlaoder project.
Have a great day,
TIC
Hi Alice :
Thanks for answering.
Making the comparison as you indicate, the contents vary. Should they be the same?
Modifying the secondary bootloader firmware so that before jumping to the application, disable the following modules :
- EEPROM
- SPIFI
- RTC
- Watchdog
- Debug console
- Gpio1 , Gpio2, Gpio3
still giving the hard fault, but I cannot continue with the debugger.
It is necessary to disable something more?
It is possible to debug the application once the bootloader jumps to it, from the debugger?
My debugger is the OM13092 board, with the SWD connector plugged into my board and I use the MCUXpresso IDE.
Best Regards.
De: Alice_Yang
Enviado el: martes, 19 de marzo de 2019 23:08
Para: miguel ibarra <migueli@cointech.com.ar>
Asunto: You have been mentioned by Alice_Yang in Re: secondary bootloader lpc54608 in NXP Community
<https://community.freescale.com/resources/statics/1000/35400-NXP-Community-Email-banner-600x75.jpg> NXP Community
You have been mentioned
by Alice_Yang <https://community.nxp.com/people/Alice_Yang?et=notification.mention> in Re: secondary bootloader lpc54608 in NXP Community - View Alice_Yang's reference to you <https://community.nxp.com/message/1127185?commentID=1127185&et=notification.mention#comment-1127185>
Hello miguel,
1) "But if the secondary bootloader load the aplication program from SPIFI to RAM and then to flash address 0x8000, "
-> After this , compare the data from 0x8000 with hex file of application , they are should be the same.
2) "If i load the application program to the address 0x8000 with the JFlash program and later load the bootloader to the 0x0 address, after the reset the secondary bootloader jump to the application program and work OK."
-> Do you meaning, when use JFlash flashing Appplicaiton and bootloader, bootloader can jump to APP, APP also can work well ? When using using bootloader get APP code , the flash it to ox8000, it can't work ? If yes, I think you need check 0x8000 memory as 1).
3) "It is possible to debug the application once the bootloader jumps to it, from the debugger? ", can debug Disassembly
code :
This can Check whether it jump to 0x8000 successfully.
Have a great day,
TIC
-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------