LPC54S018J - Unable to boot on internal SPIFI with XIP activated on custom board

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

LPC54S018J - Unable to boot on internal SPIFI with XIP activated on custom board

1,527 Views
Oliv
Contributor I

Hi,

 

I am trying to use XIP feature on a custom board without success. The SDK demo "hello_world_qspi_xip" works fine on NXP LCP54S018M-EVK but the same binary is not booting on my board.

My board is working when copying flash to SRAMX then executing code from SRAMX.

Q1: The datasheet mentions that ISP1/2/3 pins (PIO0_4/PIO0_5/PIO0_6) are floating, but on NXP EVK they seems to be pulled-up, even if I can not see any pull-up in the schematic. Why ?

Unfortunately on my board those pins are not connected, so I guess that the boot mode is undetermined and I tried to set BOOT_SRC fuses to SPIFI until we respin the board: it did not work neither.

 

Q2: OTP writing was an issue on my side, fixed

 

Q3: Datasheet states that pins N7 and C4 should be connected to enable flash and reset state is "Pulled up" (table 4), but there is a 100 k pull-up in NXP EVK. Why ?

 

Thank you for your help

Labels (1)
0 Kudos
7 Replies

373 Views
ronwal
Contributor III

Hi Oliv

Seems, that I have the same problem why I raised the following ticket:

XIP, program not starting on LPC54018J4M custom bo... - NXP Community

 

Can you tell me the solution for your problem because i may help me?

Thanks

regards

Ron

0 Kudos

1,508 Views
xiangjun_rong
NXP TechSupport
NXP TechSupport

Hi, Oliv,

Regarding your question, you said your board was working when copying flash to SRAMX then executing code from SRAMX, do you mean that your board can run after Reset even power off/on? I assume that you have downloaded application code to SPIFI flash. If it is the case, I think the boot process is okay.

The only difference between the XIP and SRAM executing is the XIP bit setting for image type(__imghdr_imagetype variable in *.ld file).

xiangjun_rong_0-1600335862263.png

 

Hope it can help you

BR

XiangJun Rong

0 Kudos

1,503 Views
Oliv
Contributor I

Thank you for your answer @xiangjun_rong

Yes, when executing from SRAMX the board can run even after a power off/on, so storing data in flash is working

 

I already checked that bit in the header and it is correctly configured:

Address 0x160 contains (little endian) a5a5 edfe 0300 0000 0000 0010 0439 0000 =>
Header_marker: 0xFEED A5A5
image_type: 0x0000 0003 (No CRC computation, XIP image)
load_adress: 0x1000 0000 (SPIFI XIP)
Image_length: 0x0000 3904

 

So, if that bit is correctly set and the boot process is correct when booting from SRAM: why NXP SDK board is booting in XIP mode but not mine ? Could we have any race condition between peripherals, like clock startup time ?

0 Kudos

1,478 Views
Oliv
Contributor I

Hello @xiangjun_rong ,

It seems that all my boards are not having the same behavior: most of them are unable to boot when I use XIP with "BootClockFROHF96M" clock but using "BootClockPLL180M" works with "led_blinky" example. Then I tried to use "QSPI_DELAY" fuse set to 220 ms (0x7). Some of them are able to boot "led_blinky with the FROHF96M clock but I usually get this pattern:

  • Boot OK from PLL and FRO clocks everytime with "led_blinky" compiled to use XIP
  • Boot OK from PLL with "hello_world_qspi_xip" but not BootClockFROHF96M
  • Boot KO with "utick_wakeup_xip" for both clock sources

As the exact same binary is booting on the NXP EVK I guess that I have an hardware issue, any hint on usual suspects?

 

Thank you

 

0 Kudos

1,469 Views
xiangjun_rong
NXP TechSupport
NXP TechSupport

Hi, Oliv,

Regarding your issue that boot fails with BootClockFROHF96M for some examples, frankly speaking, I have not ideas, probably it is a signal integrity issue for the PCB.

For the "QSPI_DELAY" fuse option, can you tell us where you set it?

BR

XiangJun Rong

0 Kudos

1,462 Views
Oliv
Contributor I

Hi,

QSPI_DELAY is from the UM11155 chapter "45.12.4.3 OTP memory bank 3, word 0 - Boot ROM control data", table 1107. Bits 19:17

Regarding free running oscillator it is inside the chip so I am not sure to understand how PCB signal integrity will impact it. I checked the power-supplies with an oscilloscope and they seems to be correct

 

Thank you

Olivier

0 Kudos

1,453 Views
xiangjun_rong
NXP TechSupport
NXP TechSupport

Hi, Oliv,

I mean the SPI_CLK_FREQ variable, which is integrated in the image, it determines the SPIFI clock frequency.

Pls refer to an12122.pdf, located at:

https://www.nxp.com.cn/docs/en/application-note/AN12122.pdf

 

Hope it can help you

BR

XiangJun Rong

0 Kudos