LPC4330 OTP, boot source

lpcware · ‎06-15-2016

Content originally posted in LPCWare by inspire on Mon Apr 13 15:23:17 MST 2015
Hi,

I've got a problem with the LPC4330 NGX Xplorer board. It is mounted on top of another PCB which adds pull down resistors on the boot selection pins of the LPC. Of course, this makes the boot selection fix to a value I don't want. Thus, I wanted to use the OTP to set the boot source to the SPIFI without influence of the boot pins. In the datasheet it says

"If the OTP memory is not programmed or the BOOT_SRC bits are all zero, the boot mode is determined by the states of the boot pins P2_9, P2_8, P1_2, and P1_1."

The LPCOpen library offers a OTP interface which I try to use:

volatile uint32_t status;

SystemCoreClockUpdate();
Board_Init();

/* Initialize the OTP Controller */
status = Chip_OTP_Init();

/* Fix as per Errata, required for some LPC43xx parts */
OTP_fix(0, 0, 0, 0);

status = Chip_OTP_ProgBootSrc(CHIP_OTP_BOOTSRC_SPIFI);

uint32_t* test = (uint32_t*) (0x40045000 + 0x030);

// *(volatile char *) (0x40045000 + 0x030) |= 1 << 26; // HARD FAULT

If I got it right, the Chip_OTP_ProgBootSrc call should set the boot source to the SPIFI. At the next restart of the LPC it should boot from the SPIFI without considering the boot pins, right?

Unfortunately, this procedure doesn't show effect for me. At the next restart the LPC doesn't automatically boot from the SPIFI. Instead, it somehow hangs and shows no response until I manually press the reset button on the NGX board. So I think the boot source has not been changed with the above code.

What I noticed is that the *test doesn't show modified boot source bits. And when I use the last line of the code the LPC instantly goes to the hard fault handler.

How can I change the boot source now?

Thanks!
inspire

lpcware · ‎06-15-2016

Content originally posted in LPCWare by TheFallGuy on Wed Apr 15 14:43:58 MST 2015
Afaik, there is no IAP on flashless parts such as 4320 etc. this includes get partid.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by R2D2 on Wed Apr 15 12:24:26 MST 2015

Quote: inspire
...but on both calls, the LPC goes directly to a HardFaultHandler when executing the line iap_entry(command, result);

Did you reserve top 32 B of on-chip RAM :quest:

lpcware · ‎06-15-2016

Content originally posted in LPCWare by inspire on Wed Apr 15 11:16:16 MST 2015
Hi,

to read the device number, I tried these commands
part_id = Chip_IAP_ReadPID();
unique_id = Chip_IAP_ReadUID();

but on both calls, the LPC goes directly to a HardFaultHandler when executing the line
iap_entry(command, result);

:quest:

Where can I find the device number instead?

The LPC has no problems with booting after the first manual reset. After this reset, I have no problems when flashing a new software with the LPCLink2 or when I hit the "restart" button while debugging. But before this first manual reset, the LPC doesn't boot and even the LPCLink2 is unable to communicate with it.

The QSPI flash IC is exactly like it was when I unpacked the board.

I think your hint with P2_7 is the solution. In fact I didn't pay attention at this point: it is at low level after reset. I will remove the pull down resistor here tomorrow and try it. Thanks a lot!

lpcware · ‎06-15-2016

Content originally posted in LPCWare by mc on Tue Apr 14 11:02:00 MST 2015
Hi inspire,
Could you please let us know full device number?
Does it boot at each and every manual reset?
Did you change QSPI flash on this board?
Can you ensure that P2_7 is high at power on reset?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by inspire on Tue Apr 14 01:57:34 MST 2015
ehm...how do I know?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by bavarian on Tue Apr 14 00:36:48 MST 2015
Do you execute this code from SRAM or from SPIFI flash?
A software reset of the MCU should not be done from the non volatile memory but from internal SRAM.

Regards,
NXP Support Team

lpcware · ‎06-15-2016

Content originally posted in LPCWare by inspire on Mon Apr 13 23:46:33 MST 2015
Hi mc,

yes correct. The LPC shows no reaction until I manually reset it. The LPCLink2 can't even communicate with the LPC before reset. The LPCLink2 always shows "cannot halt processor". After reset, it behaves normally.

So I think it's a boot source issue, right? Redlib (nohost) is used.

It's a LPC4330FET100.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by mc on Mon Apr 13 15:53:00 MST 2015
Hi inspire,

Quote:
Unfortunately, this procedure doesn't show effect for me. At the next restart the LPC doesn't automatically boot from the SPIFI. Instead, it somehow hangs and shows no response until I manually press the reset button on the NGX board. So I think the boot source has not been changed with the above code.

Do you mean device boots correctly from SPIFI after manual reset?

Which version of chip are you using?