2025-07-24 6:13 AM
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:
While this image shows the output stopping before the new clock configuration values appear under flash boot:
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 ( * )
}
}
2025-07-29 6:48 AM
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
2025-08-01 3:00 AM - edited 2025-08-01 3:01 AM
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.