LPC4350 nRESET boot fail in deep-sleep mode (BOOT_SRC read value incorrect)

[kbarker]

I'm using the LPC4350, booting from SPIFI.

Normal boot-up works fine, and reset also works fine when in normal mode.

However, I'm finding that if a reset occurs via nRESET pin when the LPC4350 is in deep-sleep mode, it fails to boot up.  It is supposed to boot from SPIFI (OTP is untouched and VPP pin is not connected, so BOOT_SRC should be 0 (ie, boot source determined by pins P2_9, P2_8, P1_2, P1_1 - these pins are set for SPIFI boot)), but instead it goes straight to outputting a 60s 1Hz pulse coming out of P1_1, and then seems to just stop after that.

If I input a second LO pulse into the nRESET pin, it boots up OK.

Referring to "Fig 16. Boot process for parts without flash" (UM10503), I've attempted to identify where the problem is.  I found I could pause the reboot at the "enter ISP mode" state by holding P2_7 LO, and that enabled me to connect the debugger by JTAG and check the value of the BOOT_SRC pins in OTP.

The OTP values read out by the debugger showed that the OTP values were reading incorrect values.  Specifically, OTP bank 0 Word 0 (First 32 bit word of the unique part ID) and OTP bank 3 Word 0 (Customer control data) (addresses 0x40045000 and 0x40045030 respectively) were reading as 0xFFFFFFFF.  This means that the four BOOT_SRC bits (bits 28:25 of Customer control data) were read as the (invalid) value 1111 which, as per Fig 16, would immediately cause the boot process to go to the 60s timeout toggle pin P1_1.

So something seems to be causing incorrect values to be read when reading the OTP registers.

It seems to be a similar problem to the RESET.3 problem described in the errata sheet:

"When the part is in deep-sleep or power-down mode and if an external reset occurs via nRESET pin being activated, as the part comes out of reset, the reset state of some functional blocks may be incorrect.  This may result in loss of functionality of the device."

The "possible affected blocks" are listed, but the list does not include OTP.

However, it is clear from the errata sheet information for RESET.3 that external reset via nRESET pin during deep-sleep mode should be possible (otherwise, work-around 1 would not work).  So I'm thinking that there must be something with my hardware and/or software setup that is causing this problem to occur.

I'm trying to identify what that difference might be, and hence what I could try doing as a work-around.

For my next step, I'm planning to see if I can reproduce this problem using the misc\pmc_states example project in LPCOpen, but in the meantime:

Has anyone else seen this problem?

Any ideas for what to try, to find a work-around?

[bernhardfink]

Hi Keith,

what are you doing to prepare the chip for deep sleep mode?

There are a few settings in the CREG domain which remain valid, so if you do something wrong there it could affect the restart.

Regards,

Bernhard.

[kbarker]

Thank you Bernhard for your suggestion.

I've carefully compared the CREG values before and after.  I'm still getting the problem, even if the CREG values when trying to reboot by nRESET are identical to the values when doing a normal power-on boot.

I've reproduced the problem by using the misc_pmc_states example from LPCOpen 3.02 on the Hitex LPC1850EVA-A4 Evaluation Board (populated with LPC4350).  With the boot pins set for SPIFI boot, and the pmc_states example loaded into serial flash, the demonstration program boots up, I select "2" from the menu, then "w" and "c" to enter Deep-sleep mode.  I then push the RESET button.  It fails to boot up.  In fact, it takes three presses of the RESET button before it will boot up again properly.

Referring again to Fig 16,

After the first RESET push, the CPU seems to hang somewhere before "enable JTAG" (I can't even get to "enter ISP mode" by holding down the ISP key).

After the second RESET push, the CPU goes through to 60s timeout toggle pin P1_1, and then after 60s appears to end up somehow at UART0 boot.

After the third RESET push, it boots up properly from SPIFI.

It's a mystery to me what could be causing this.  Please see if you can reproduce this problem on the Hitex LPC4350 board or the LPC43S67 board.

Are there any specific CREG settings that could be causing this problem?

Thank you for your assistance.

[bernhardfink]

Hi Keith,

now we're going back in history :smileyhappy:

The Hitex boards with the LPC1850 and the LPC4350 have been assembled in an early stage of the product lifetime, this means we have the first production silicon on there.

There was a problem in the boot ROM when working with QSPI devices. The board only started with every second reset, except for power-on. The boot code wasn't able to bring the QSPI into the right mode with the implemented command sequence. Running the sequence a second time brought the QSPI back into operation --> done with the second reset.

This isn't a problem in the flash devices, this is another silicon with another boot code. And if I remember correctly, we have also corrected it in the later flashless devices.

However, this doesn't solve your problem, you just ran with your test into a different issue.

I have a KEIL MCB4300 board here with me in the home office, where we mounted a socket. Most likely I have a box somewhere with LPC1800 samples, then I could do a test with my own low power software.

I will keep you informed about the results.

Regards,

Bernhard.

[kbarker]

Thanks for your reply, Bernhard.

I still haven't solved this issue.  I'm also seeing it when boot is set to USB0 (ie, when not using SPIFI at all).

I'm thinking it might be related to the RTC registers.  Perhaps the 32 kHZ oscillator is not running, and so (as explained in the UM), "repeated writes to the RTC registers without the 32 kHZ clock can stall the CPU".

It also says to wait 2sec before writing to the RTC registers.

Does that include writing to the 64 general purpose registers REGFILE? (Addresses 0x4004.1000 ...)