LPC 1857 with SPIFI MX25L25635F

[mathiasmonse]

For our product we would like to use the SPIFI flash memory Macronix MX25L25635F in our design as second source.

The manual UM10430 reads on page 49 "A reset delay is needed on the LPC18xx to allow this memory time to come up before booting."

How can I maintain such a reset delay by software?

The implemented bootloader and application are using NXP's SPIFI rom api which sufficiently works with SPANSION type flash S25FL2566S.

During my investigations I experienced the following behaviour:

- loading bootloader and application binaries into flash with LPCScrypt v2.0 does work

- starting the application afterwards fails with spifi_init()

- resetting the target with the debugger will start the application

- after such a debugger reset every successive reboot starts the application again without delay or spifi_init failure even after power down

Does somebody have experiences with a similar setup and behaviour?

[mathiasmonse]

After some more investigation a solution/workaround had been found:

• at first start after storing the application using LPCScypt v.2.0 the call to spifi_rom_api::spifi_init() fails
  • connect SPIFI base clock (CGU_BASE_SPIFI) to CGU_CLKSRC_IRC
  • re-run spifi_rom_api::spifi_init()
  • connect SPIFI base clock to normal CGU_CLKSRC_XXX (eg. CGU_CLKSRC_IDIVA)
• all starts from then on will succeed (also without changing  source of SPIFI base clock)

Unclear is:

• what non-volatile setting does change LPCScrypt to require a slower SPIFI clock
• does adjust (repair) spifi_rom_api::spifi_init() that setting when called with a slower SPIFI clock or what else causes this behaviour

[jeremyzhou]

Hi Mathias Monse,

Thanks for your reply.

Firstly, the LPC18XX doesn't contain the ROM SPIFI API, the LPCScrypt receive a boot image via the USB and store it to RAM, then execute from there.
The boot image is able to do the flash operations via the inputting command in CMD window.
1) what non-volatile setting does change LPCScrypt to require a slower SPIFI clock？
-- As I mentioned above, the boot image is in charge of the flash operations, however, itis invisible to us.
2) Does adjust (repair) spifi_rom_api::spifi_init() that setting when called with a slower SPIFI clock or what else causes this behavior?
-- It's available to configure a slow BASE_SPIFI_CLK during initializing the SPIFI module prior to calling spifi_init().

Have a great day,
TIC

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[mathiasmonse]

Hi jeremyzhou,

many thanks for your reply.

After your remarks I cross-checked with our implementation and have to agree with your statement the LPC18XX does not contain the ROM SPIFI API. We link 'CMSIS\drivers\lib\spifi_drv_M3.lib' to our project and use the spifi_rom_api.o for handling the SPIFI devices. There I found also a draft version of 'SPIFI_report v0.1.pdf' (Rev. 0.01 — 27 April 2012) which explains a lot of my questions.

The need to call spifi_init() with a SPIFI base clock set to 12 MHz could be a special property of the MACRONIX flash device -- at least I take it that way.

Kind regards

Mathias

[jeremyzhou]

Hi Mathias Monse,

Thank you for your interest in NXP Semiconductor products and for the opportunity to serve you.
1) How can I maintain such a reset delay by software?
--These devices take a longer time to be ready after power on. You may need to delay the startup of LPC18xx. One way to achieve this sequence is to delay
RESETN signal of LPC18xx. It needs to adjust the RC circuit of reset pin.

RESETN signal of LPC18xx.
2) Does somebody have experiences with a similar setup and behavior?
-- I'd like to know the more information about this phenomenon, so whether you like to share the code.

Have a great day,
TIC

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[mathiasmonse]

Hi jeremyzhou<https://community.nxp.com/people/jeremyzhou?et=notification.mention>,

thank you for your support.

1) For the idea of delaying RESETN we plan to test with a reset controller with adjustable delay. In the recent layout we do use a MCP130 with fix delay of about 350ms. I will tell about the results when available.

2) Another and preferred approach is to find a software solution. My hope is based on the observation that after a successful call to spifi_init() the start succeeds always in the following reboots (both cold and warm reset).

For a successful reboot the used sequence is:

1. Set device into LPC boot mode
2. Load binaries (boot loader and application) using LPCScrypt (v2.0) into FLASH (internal and SPIFI)
3. Connect Debugger (w/o device reset)
4. Start device (booting from FLASH)
5. STOP application using debugger --> while(1) loop after spifi_init() failed [[-- without further actions every other reboot ends here]]
   
6. RESTART application and use debugger to break just before call to spifi_init()
7. Step into spifi_init() and through the whole function
8. After spifi_init() run free [[--> application start succeeds]]

The init sequence is as follows:

; startup_LPC18xx.s::Reset Handler
Reset_Handler PROC
EXPORT Reset_Handler
IMPORT SystemInit
IMPORT __main
LDR R0, =SystemInit
BLX R0
LDR R0, =__main
BX R0
ENDP‍‍‍‍‍‍‍‍‍‍

/*------------------------------------------------------------------------
  Initialize the system
*----------------------------------------------------------------------*/
void SystemInit (void) {
       uint32_t *MAM,t;
 
       /* Set up flash controller for both banks */
       /* Bank A */
       MAM = (uint32_t *)(LPC_CREG_BASE + 0x120);
       t=*MAM;
       t &= ~(0xF<<12);
       *MAM = t | (FLASH_ACCELERATOR_SPEED<<12);
       /* Bank B */
       MAM = (uint32_t *)(LPC_CREG_BASE + 0x124);
       t=*MAM;
       t &= ~(0xF<<12);
       *MAM = t | (FLASH_ACCELERATOR_SPEED<<12);
       
       __disable_irq();
       
       SystemInit_PortPins();     /* Port Pins Init */
       SystemInit_Core();         /* Init CPU Core */
       SystemInit_Clock();        /* Init CPU CLK */  
       SystemInit_ExtMemCtl ();   /* Configure External Memory Controller */
       SystemInit_SPIFI();        /* Configure SPI Flash Interface */
       SystemInit_LCD();          /* Configure LCD Controller */
       SCT_Init();                /* Configure State Configurable Timer */
}‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

void SystemInit_SPIFI(void) {
       EMCClk = CGU_GetPCLKFrequency(CGU_PERIPHERAL_M3CORE)/2;
       // call spifi rom lib function to configure SPIFI
       if (spifi_init(&sobj, 9, S_RCVCLK | S_FULLCLK, EMCClk/1000000)) {
             if (spifi_init(&sobj, 9, S_RCVCLK | S_FULLCLK, EMCClk/1000000)) {
                    while(1);
             }
       }
}‍‍‍‍‍‍‍‍‍

My attempts to delay the spifi_init() sequence by using loops or timer delays haven’t been successfully yet.

The source code of spifi_init() is not available for me.

I ‘d like any ideas how to proceed. Thank you.

Kind regards

Mathias Monse

[jeremyzhou]

Hi Mathias Monse

According to the introduction of the issue, I get that the SPIFI initialization usually fails when first execute the  spifi_init() after entering the debugging, however, it will succeed after recall the spifi_init(), is it?
If yes, I think it's not a software issue, it obviously relates the hardware circuit, as I pointed out that the device takes a bit longer time to be ready after power on.
Have a great day,
TIC

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[mathiasmonse]

Hi jeremyzhou,

the behaviour as a bit tricky:

• calling spifi_init() twice in a row --> fail
• delaying 1st and 2nd call several seconds (2..30s) by code --> fail
• breakpoint before either call to spifi_init() and stepping over functions calls --> fail
• breakpoint before 1st call to spifi_init() and stepping into function (until spifi_init()::return) --> success
  -- and from then on every reboot (cold/hot) succeeds

I agree that a delay of an initialisation routine of spifi_init() is the key but which?

I would like to check what part of spifi_init() fails and why.

Where can I find the source code of spifi_init()?

Regards

Mathias

[jeremyzhou]

Hi Mathias Monse，

Thanks for your reply.
You can learn more information about the SPIFI library via the following link, for instance, library project and library application project.

LPC SPIFI Peripheral|NXP
Have a great day,
TIC

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------