cancel
Showing results for 
Search instead for 
Did you mean: 

Booting from flash doesn't work properly on X-CUBE-AI project on NUCLEO-N657X0-Q

Konstantina
Associate

@Julian E.

I’m porting the X‑CUBE‑AI v10.0.0 “hello_world” application, originally for the STM32N6570‑DK (path: X‑CUBE‑AI\10.0.0\Projects\STM32N6570‑DK\Applications\hello_world), to the NUCLEO-N657X0-Q board with the use of lwIP to receive the images and send the results to my computer.

When I download and run the firmware from CubeIDE, everything works: the link comes up, and the neural‑network inference runs. When I boot from Flash, the code begins, prints the initial clock values and then halts. The same problem occurs without the use of lwIP, just by running the neural network.

For reference, the image below shows a complete successful log under CubeIDE:

image.png

 

While this image shows the output stopping before the new clock configuration values appear under flash boot:

image.png

 

I have also attached main.c, misc_toolbox.c, system_clock_config.c and provided the linker script.

Any guidance or suggestions would be greatly appreciated. Thank you for your time.

The linker script could not be attached, so it is displayed below:

ENTRY(Reset_Handler)

_Min_Heap_Size  = 0x400;
_Min_Stack_Size = 0x800;

MEMORY
{
  AXISRAM1_S (xrw) : ORIGIN = 0x34180400, LENGTH = 255K
  RAM        (xrw) : ORIGIN = 0x341C0000, LENGTH = 256K
}

_estack = ORIGIN(AXISRAM1_S) + LENGTH(AXISRAM1_S);
_sstack = _estack - _Min_Stack_Size;

SECTIONS
{
  .isr_vector :
  {
    . = ALIGN(4);
    KEEP(*(.isr_vector))
    . = ALIGN(4);
  } >AXISRAM1_S

  .text :
  {
    . = ALIGN(4);
    *(.text*)
    *(.glue_7)
    *(.glue_7t)
    *(.eh_frame)
    KEEP(*(.init))
    KEEP(*(.fini))
    . = ALIGN(4);
    _etext = .;
  } >AXISRAM1_S

  .rodata :
  {
    . = ALIGN(4);
    *(.rodata*)
    . = ALIGN(4);
  } >AXISRAM1_S

  _sidata = LOADADDR(.data);
  .data :
  {
    . = ALIGN(4);
    _sdata = .;
    *(.data*)
    . = ALIGN(4);
    _edata = .;
  } >AXISRAM1_S AT >AXISRAM1_S

  .gnu.sgstubs :
  {
    . = ALIGN(4);
    *(.gnu.sgstubs*)
    . = ALIGN(4);
  } >AXISRAM1_S

  .bss :
  {
    . = ALIGN(4);
    _sbss = .;
    *(.bss*)
    *(COMMON)
    . = ALIGN(4);
    _ebss = .;
  } >AXISRAM1_S

  ._user_heap_stack :
  {
    . = ALIGN(8);
    PROVIDE(end = .);
    PROVIDE(_end = .);
    . = . + _Min_Heap_Size;
    . = . + _Min_Stack_Size;
    . = ALIGN(8);
  } >AXISRAM1_S

  .RxDecripSection (NOLOAD) : ALIGN(32) {
    KEEP(*(.RxDecripSection))
  } >RAM

  .TxDecripSection (NOLOAD) : ALIGN(32) {
    KEEP(*(.TxDecripSection))
  } >RAM

  .Rx_PoolSection (NOLOAD) : ALIGN(32) {
    KEEP(*(.Rx_PoolSection))
  } >RAM

  .noncacheable (NOLOAD) : ALIGN(8) {
    __snoncacheable = .;
    KEEP(*(.noncacheable*))
    . = ALIGN(8);
    __enoncacheable = .;
  } >RAM

  /DISCARD/ :
  {
    *(.ARM.exidx*)
    *(.ARM.attributes)
    libc.a ( * )
    libm.a ( * )
    libgcc.a ( * )
  }
}

 

2 REPLIES 2
Julian E.
ST Employee

Hello @Konstantina,

 

I shared your issue with the dev team. 

They will look at it as soon as they can.

 

Have a good day,

Julian


In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.
SlothGrill
ST Employee

Hello,

(tentative answer, as there is not much detail about how you crafted your "boot from flash" app)

When you are booting from external flash, most likely, the FSBL you wrote is configuring the external flash before jumping to it so as to execute code from it (execute in place).

When the program then executes (from flash), if your code tries to RECONFIGURE THE EXTERNAL FLASH (which is what is done when you call init_external_memories, you will end up in instruction where you are reconfiguring the XSPI2 interface, while trying to fetch code from external flash (fetching uses XSPI2 memory-mapping done by the FSBL). There are then, for sure, a time where, by reconfiguring the XSPI2 interface, you "break" your ability to fetch code from there (i.e. if the code resets some registers). Which makes everything eventually fail.

 

If this is the issue you are experiencing, try not to reconfigure xspi2 in your app... the configuration has already been done by the FSBL, and doing a reconfiguration on-the-fly will prevent your CPU from fetching code to be executed.

(in init_external_memories, the part of the code that does that is 

  if(BSP_XSPI_NOR_Init(0, &Flash) != BSP_ERROR_NONE)
  {
        __BKPT(0);
  }
  BSP_XSPI_NOR_EnableMemoryMappedMode(0);

)

Let us know if this helps.