Fail to cold boot over SPIFI

[lpcware]

Content originally posted in LPCWare by midas on Wed Mar 02 10:52:51 MST 2016
I have a proprietary board based on LPC4330, which I have been working with without any problem for quite some time. It has a Spansion S25FL032P serial flash connected to the SPIFI. I can use LPCXpresso (version 8.0.0) to flash the serial flash and debug my programs, but lately I have tried to run a program that was in the flash from cold boot (which I seem to have been able to do in the past, but I am not sure anymore), but the flashed program wont run. I have generated a new minimalistic LED blinking program, that doesn't even program the clock, but I can't get that to run from cold boot either, although it runs ok from SWD debugger. The board is configured to boot from SPIFI. When I try to connect to target that fails to run on its own ("attach only"), connection fails with message "cannot access core regs when target running". With the debugger I can confirm that the program is properly located in serial flash at 0x14000000.

Any ideas?

Thanks,
Uri

[uribendelac]

Sorry for the late reply - I went on to other things lately, but now I am back investigating this boot failure issue.

I have found out that P1_1 will toggle at 1Hz - an indication by the boot loader that it failed to boot. I figured out that the problem was due to the voltage on P2_9 during reset being too high, in spite of a 10K Ohm pull-down I had on it to direct the boot loader to boot from SPIFI. That in turn was caused because the same signal was also connected to an FPGA that has a pull-up on it. I lowered the pull-down resistor to 1.47K Ohm and now the boot loader will try the SPIFI. However, now I encounter the 60 second timeout issue, mentioned in the errata, i.e. the boot loader (I have LPC4330FDB144 revision A, with boot rom version 11.1) will not agree to read from the Spansion/Cypress flash, S25FL032P0XMFI011 that I use until it resets itself after 60 seconds and then it will boot ok. The LPC4330 manual (UM10503) mentions the S25FL032P1F as being supported by the boot loader but such a part number doesn't seem to exist. Also, it mentions that it uses the 0xFF command to revert to normal read mode, but such a command is not supported by the S25FL032P0XMFI011 device I use. Is my flash chip supported by the boot loader only in revision 11.2? Is the S25FL032P0XMFI011 really supported by the boot loader without having to wait 60 seconds? My board will not boot immediately after cold reset, not just warm reset, unlike the description in the errata which seems to imply the problem occurs only on warm reset. I am not clear on if replacing the flash type I use to another type would solve my problem, or using a newer   LPC4330FDB144 revision C, or if there is no work around other than waiting 60 seconds?

Thanks,

Uri

[Carlos_Mendoza]

Hi Uri,

The S25FL032P1F QSPI is and old part no longer recommended for new designs. The LPC43xx devices support all S25FL032P and S25FL064P quad SPI flashes so your QSPI device is supported. Regarding the SPIFI errata, this affects only the revision A devices, you will not have this problem with the revision C devices.

Hope it helps!

Best Regards,

Carlos Mendoza

Technical Support Engineer

[lpcware]

bump

[lpcware]

Content originally posted in LPCWare by vtw.433e on Mon Mar 14 01:12:36 MST 2016

---

Quote: midas


I have tried your suggestion of connecting with the debugger when it is running, but the debugger fails to connect, unless it includes a reset AND download of image, in which case I cannot see where it was stuck.
Uri

---

https://www.lpcware.com/content/faq/lpcxpresso/debugging-running-system

[lpcware]

Content originally posted in LPCWare by mc on Sun Mar 13 17:52:18 MST 2016
Hi Uri,
Can you please use oscilloscope and probe SPIFI_CLK,SPIFI_CS  and SPIFI_MISO  pins during boot. Can you compare sIgnal on SPIFI_MISO with and without debugger?
If it is timing problem at boot, boot should work if you just reset LPC4330 only. Did you try this?

[lpcware]

Content originally posted in LPCWare by midas on Fri Mar 11 08:15:14 MST 2016
Thanks again for your support, Bavarian.

I have tried your suggestion of connecting with the debugger when it is running, but the debugger fails to connect, unless it includes a reset AND download of image, in which case I cannot see where it was stuck. But since the first thing the simple program does is initialize the led IO and toggle it, it is quite clear it doesn't reach that stage. Also, I don't have an interface to the UART, so I cannot easily test for the UART ISP (but even if the UART ISP works, that doesn't help me much).
Your theory about the M4 microcontroller starting too soon, at 2.3V, is indeed interesting. The QSPI flash I use (Spansion S25FL032P) is guaranteed to operate from 2.7V. To test this theory, I soldered a reset switch, downloaded the led toggling program to flash, ran it from the debugger, disconnected the debugger - set to let the program continue running, so that the led was still flashing, and then I issued a reset from the switch. The program did not recover, so the boot loader probably still failed to initialize the microcontroller to run from SPIFI. However, the 3.3V was already up and stable for both microcontroller and the flash, so this theory does not seem to pan out either.
Also, I should point out that the microcontroller doesn't run even after the one minute timeout of the boot loader.

Thanks,
Uri

[lpcware]

Content originally posted in LPCWare by bavarian on Fri Mar 11 02:54:47 MST 2016
Two further ideas:

It should be possible to find out at which stage you fail by using this strategy:

[list]
  [*]  Insert a  B  TO_HERE  assembler instruction as one of the first commands into your minimalist program. If the M4 successfully runs through the bootloader and boots from SPIFI then you hang up there and you should be able to catch it with the debugger, regardless if the debugger applies a reset or not.
  [*]  Same works in principle if you keep the ISP pin P2_7 on low all the time. Let the debugger apply a reset, you will always end up in UART ISP mode, where the bootloader waits for the '?' character. If this does not work, so if you can't get on the core with a debugger or if you don't get a response when sending a '?' into UART0, then there must be a hardware problem.
[/list]

One reason for a cold boot fail is of course the SPIFI problem mentioned in the error sheet, where it fails with the first reset but works with the second reset. At power-up it works in the first step. It also works with one reset and then wait for 60 seconds, then the bootloader runs into a timeout and initiates a core reset (= second reset).

Another reason for a cold boot fail is the power-up timing of the MCU and the qSPI. The LPC4300 starts running through the bootloader when the voltage level is at about 2.3V. If the voltage on the SPIFI at this point in time is also at 2.3V, then the access to the SPIFI might fail. There is a period between the start of the bootloader and the first attempt to communicate with the qSPI, in this time the voltage on the qSPI must be high enough to guarantee the communication. So a slow power ramp could be a problem.

Regards,
NXP Support Team

[lpcware]

Content originally posted in LPCWare by midas on Thu Mar 10 07:21:38 MST 2016
Hi Bavarian, thanks for your help.

I have the floating point initialization being called as part of SystemInit(). However, I must clarify, as I pointed out in my first post, that I wrote a very minimalist blinking led code that does work properly when loaded into external serial flash and run from the debugger (SWD). What doesn't work is getting the rom boot loader to properly initialize the CPU and start running the code from the serial flash from cold boot. Also, as I pointed out, I cannot attach to the running CPU to investigate where it is stuck, as it wont allow me to attach to it with the aforementioned message about not being able to connect to a running target. It seems that when I do a cold start, the boot loader decides it needs to boot from a different mode than the SPIFI interface, even though I have the ISP pin (P2_7) pulled up (so it should not boot from the serial port), the BOOT_SRC bits are all zero (so the boot source is determined by four external pins) and the boot source select pins (P1_2, P2_8, P2_9 and P1_1) are all pulled up except P1_1 which is grounded, i.e. it should boot from external SPIFI. Except it seems it doesn't.

Thanks,
Uri

[lpcware]

Content originally posted in LPCWare by bavarian on Wed Mar 09 04:37:58 MST 2016
Some ideas:

[list]
  [*]  You compiled for floating point but don't enable it in SystemInit
  [*]  You use a global variable in SystemInit, then it#s getting zero-initialized in the scatter loading process and afterwards it of course does not longer have the value you applied in SystemInit.
  [*]  You execute something which puts the chip into a weird state. That's of course a very common point, but can't you step to the point where it crashes or hangs up?
[/list]

regards,
NXP Support Team

[lpcware]

Content originally posted in LPCWare by midas on Tue Mar 08 19:07:00 MST 2016
Yes, the ISP pin is high. It has an external pull-up resistor of 10K (in parallel to the internal weak pull-up), as well as a switch to ground (which is not populated, and can optionally force entering ISP) in parallel to a 0.1uF capacitor for debouncing the switch, which was populated. I removed the capacitor (since it might have force a low level after reset, long enough for the boot loader to enter ISP mode), but the LPC4330 still doesn't boot properly. I have confirmed with a scope that the ISP pin is indeed high.
Any additional ideas or tests I can do?

Thanks,
Uri

[lpcware]

Content originally posted in LPCWare by mc on Tue Mar 08 07:28:44 MST 2016
Hi Uri,
Can you please check if ISP pin is high? It should be high during boot. Do you have pull up on it? What is connected to this pin?