topic Boot from SPIFI in LPC Microcontrollers

Boot from SPIFI

lpcware — Wed, 15 Jun 2016 18:15:56 GMT

Content originally posted in LPCWare by robert on Sun Jan 25 18:42:27 MST 2015
Dear NXPs,

Now use the LPC1830FET180, want to boot from SPIFI, if the hardware not use the boot pins, can programmed the BOOT_SRC to realize? If can, how to program it ?

Thanks.

Re: Boot from SPIFI

lpcware — Wed, 15 Jun 2016 18:15:57 GMT

Content originally posted in LPCWare by mc on Sun Jan 25 22:27:00 MST 2015
Hi robert,
Yes, you can set OTP boot source bits to boot from SPIFI without using boot pins. Please have a look at below app note.
http://www.lpcware.com/content/nxpfile/an11292-lpc1800lpc4300-one-time-programmable-otp-configuration
Please also check pages 27/1264 and 35/1264 of UM10430 Rev. 2.5 — 27 January 2014.

Re: Boot from SPIFI

lpcware — Wed, 15 Jun 2016 18:15:58 GMT

Content originally posted in LPCWare by robert on Mon Jan 26 02:19:51 MST 2015
I have down the project, and debug the Boot_Mode.uvproj code in " internal ram", and watch the value have writed successfully.
Then I programmed my code into the QSPI flash , it is also successful,but could not run.
Then I try to reprograme it, but error " devide could not be powered up "; i want to debug/emulate/run in RAM, also error " devide could not be powered up ". And this time, can read the device/MCU ID by JTAG or SWD.

So what 's prolblem? just becasue programed the boot_src, so could not use it again?

Re: Boot from SPIFI

lpcware — Wed, 15 Jun 2016 18:15:58 GMT

Content originally posted in LPCWare by bavarian on Mon Jan 26 05:26:57 MST 2015
If you did not program any OTP bits which prevents access through JTAG/SWD, then normally you can use the ISP mode to recover from such a situation.
[list]
[*] If you connect P2_7 on ball C10 to GND during power-on (or reset), the bootcode enters ISP mode, waiting for a connection setup on USART0.
[*] If you have USART0 available, you can use the tool Flash Magic to program new software, erase the SPIFI etc.
[*] For JTAG/SWD access this ISP mode should have a positive effect as well. The bootloader hangs forever in a loop, waiting for a sync character on USART0. This is a pretty clean system state, maybe in contradiction to your user software in SPIFI. Maybe it crashes, maybe it goes into power-down, some sort of system state where the JTAG/SWD access is no longer possible.
[*] My usual recommendation: insert a long wait loop at the beginning of your software (e.g. 3 seconds), then a debugger can catch the chip during this period before maybe something dreadful happens which disables the JTAG access somehow.
[/list]

Regards,
NXP Support Team

Re: Boot from SPIFI

lpcware — Wed, 15 Jun 2016 18:15:59 GMT

Content originally posted in LPCWare by robert on Tue Jan 27 19:14:10 MST 2015
Thanks.But i have some questions:
1. this time, can read the device/MCU ID by JTAG /SWD, so JTAG/SWD access is OK, so not in ISP MODE.
2.JTAG/SWD access this ISP mode should have a positive effect ----what's meaning?I think If can not go into ISP, JTAG/SWD access is natural .

Re: Boot from SPIFI

lpcware — Wed, 15 Jun 2016 18:16:00 GMT

Content originally posted in LPCWare by bavarian on Thu Jan 29 04:18:48 MST 2015
What I try to tell you is the following:
[list]
[*] If you have programmed a software into the flash which somehow disables the JTAG/SWD functionality, then you have no chance with the debugger.
[*] It helps to go into the ISP bootmode, because then your software does not start to run, but the device stays in the ROM bootloader and waits.
[*] A delay loop right at the beginning of the software helps as well, because the program counter stays there for a while and the debugger can catch the core before your software continues and does something dreadful with the MCU. The JTAG/SWD access depends on the MCU state, it is not a totally independent and separate access port.
[*] If you are now able to see the ID of the two cores then the debugger gort the chip/core under control and you can do something like flash programming or debugging etc etc
[/list]

Regards,
NXP Support Team