LPC54628 sometimes fails to boot

[anders_erlandss]

Hi. I'm using the very nice LPC54628 dev board (OM13098) for development of an LVGL application.
I see problems with warm reset (ie. either pressing "Target reset" or calling NVIC_SystemReset())
After a reset, execution sometimes gets stuck in ROM boot code at address 0x30012C2 (forever loop).

How to repeat:
1.Import the lvgl demo example using MCUXpresso (I use version 11.4.0 with SDK version 2.10.0).
2.Replace the source line containg "lv_demo_widgets()" with the following code:

#if 0
/* LVGL example */
lv_demo_widgets();
#else
/* LVGL simple test */
lv_obj_t *screen = lv_obj_create(NULL, NULL);
lv_obj_set_style_local_bg_color(screen, LV_OBJ_PART_MAIN, LV_STATE_DEFAULT, LV_COLOR_BLACK);
lv_obj_t *label = lv_label_create(screen, NULL);
lv_label_set_text(label, "hello, world");
lv_obj_align(label, NULL, LV_ALIGN_CENTER, 0, 0);
lv_scr_load(screen);
#endif

3.Build, load and detach the debug connection (to let it run whithout the debugger)
4.The LCD panel should become dark and show the message "hello, world"
5.Now press "Target Reset" button until reset fails (indicated with a white screen)
6.Reattach the debugger, press stop and the break address will be "0x30012c2".

Single stepping shows that the execution is stuck in a forever loop inside the Boot ROM.
Further reset attemts will fail. A power cycle is the only way to recover.

The problem seems similar to another issue reported in the NXP Community forum.
See "LPC54628 sometimes hangs in ROM boot loader after software reset".

-Is this a known issue?
-I have board rev "E", does the ISP pins on my board need pullup resistors?

Please advice.

Kind Regards,
Anders Erlandsson

[Alice_Yang]

Hello Anders,

I test your code, it can work well after Target Reset.

See my attachment.

BR

Alice

[anders_erlandss]

Hello Alice,

We have now verified that the boot failure exists on two different OM13098 boards.
One of them is patched with 10k pull-up resistors on the ISP pins as suggested.
I have also refined my code that provokes the problem.

Simplified instructions to repeat the problem:
1) Install the emc_sdram driver example from the SDK.
2) Insert the code below just before the while loop at the end of main():

/* Boot failure code */
{
/* Indicate successful boot by switching backlight off */
GPIO_PinInit(GPIO, 3, 31, &(gpio_pin_config_t){kGPIO_DigitalOutput, (0)});
GPIO_PortClear(GPIO, 3, 1U << 31);

memset(sdram, 0, SDRAM_EXAMPLE_DATALEN * 4);

/* Read from SDRAM while waiting for "Target Reset" */
while (1) {
for (int tmp = 0, index = 0; index < SDRAM_EXAMPLE_DATALEN; index++) {
tmp += *(uint32_t *)(sdram + index);
}
}
}

3) Detatch the debugger
4) Press "Target Reset" after the screen backlight is switched off.

Failure rate (on both our boards) is about 1:6, ie there is a 16% chance of failure every time we press "Target Reset".

If you change the memset line so that bit D2, D3 and D4 in the SDRAM is 111 the problem will dissapear.
It seems that the problem is related to the shared pins for the external SDRAM and ISP boot function.

-Do you see the same behaviour?
-Any suggestions for a workaround?

Kind Regards,
Anders

[Alice_Yang]

Hello Anders,

I have reproduce the issue on my side, lpcxpresso54628 board without  pull-up, it is hard to modify on my side.

Could you please take a picture about how do you "patched with 10k pull-up resistors on the ISP pins",

and also use Oscilloscope monitor those ISP pins when reset , are they high at the whole time?

BR

Alice

[anders_erlandss]

Hi Alice,

I have attached a picture of the patch.

We think we understand the problem now and that the oscilloscope measurement is not needed.
-An ongoing read operation from the SDRAM is not disabled fast enough when pressing "Target Reset".
-The MCU boot procedure sometimes fails since the ISP boot pins are shared with D2, D3 and D4 from the SDRAM.

In our own board design we will simply add some components to disable the signal paths for D2, D3 and D4 during boot.
We think it's a fast and easy solution (also, we are in a bit of a hurry).

If you have a better ideas, please let me know.

Kind Regards,
Anders

[giusloq]

In our own board design we will simply add some components to disable the signal paths for D2, D3 and D4 during boot.
We think it's a fast and easy solution (also, we are in a bit of a hurry).

I encountered exactly the same problem. I'm using SDRAM too and it sometimes happens the boot process hangs erroneously in the Boot ROM.

Event to me it seems the problem is caused by sharing ISP pins with SDRAM, so pull-up can't help. When the reset happens exactly when SDRAM has configured one of D2/D3/D4 pins as low-level output, pufff... MCU hangs in the Boot ROM.

So what is the best solution to this problem? Could you share your schematics? Thank you.

[Alice_Yang]

Hello Anders,

I think your solution is good, and also you can disable  enter ISP mode using the ISP pin through config

CRP_ISP_DISABLE_PIN in OTP,

while be careful: OPT is a non-volatile and write-once register. OTP is not FLASH and it can be ONLY written by IAP function. Once disable, we never can enter isp though ISP pins.

Just one suggestion, your solution is more safe than OTP. 

BR

Alice

[anders_erlandss · Accepted solution]

Alice,

Thanks for your support.
I will close this issue now.

Regards,
Anders

[Alice_Yang]

Hello Anders,

Add, OTP is dangerous to test, you can just config the flash ECRP, please see P1051 of UM10912:

directly config the data in startup_lpc54628.c file:

this configuration won't limited your chip.

BR

Alice

[anders_erlandss]

Alice,

Thanks for performing the test!
The boot failure occurs randomly, with a 13% failure rate.
Sometimes it happens directly, but sometimes I need to press "Target Reset" many times before the failure occurs.

-Could you please try again and press "Target Reset" at least 50 times?

Sorry for the trouble.

Kind Regards,
Anders

[Alice_Yang]

Hello anders_erlandss,

1) How about  run simple SDK demo? 

2) Recommend pull up ISP pins to bypass ISP mode, check whether the problem persists.

BR

Alice

[anders_erlandss]

Hi Alice,

We have patched the ISP pins with pull-up resistors as you recommended.
We used 10k resistors for this. The problem is still there.
Perhaps a reset of the MCU in the middle of a SDRAM read/write operation could cause this issue.
In that case pull-up resistors will not help. But I'm just guessing.

You should be able to repeat the problem at your side. Can you confirm this?

Please advice.

Regards,
Anders

[anders_erlandss]

Hi Alice,

Thanks for your response.

Answer 1:
The SDK LVGL demo needs to be modified with a black background, or the boot issue will not occur.
I guess the sharing of pins for the EMC and ISP boot function is causing this issue.
I see the same problem when I execute an application from the external SDRAM.
The randomness of this issue makes it difficult to track down.

Anwer 2:
Ok, we will patch in pull-up resistors to the OM13098 tomorrow. Will let you know of the result.
We will also add pull-up resistors to our own board design (which is under construction).

BR,
Anders