CubeMX workflow for NUCLEO-N657X0-Q FSBL XIP application with ThreadX and NetX Duo

[FORVIA]

Hello,

I am trying to create an FSBL XIP project for the NUCLEO-N657X0-Q with the following structure:

• FSBL running from internal SRAM

• Application executing in place from the external XSPI flash

• ThreadX and NetX Duo running in the Application context

• Ethernet using the onboard LAN8742 PHY

• External Memory Loader project

The STM32CubeN6 firmware package contains two relevant examples:

• Projects/NUCLEO-N657X0-Q/Templates/Template_FSBL_XIP

• Projects/NUCLEO-N657X0-Q/Applications/NetXDuo/Nx_UDP_Echo_Client

However, the two examples use different project structures.

Template_FSBL_XIP provides the required FSBL, XIP Application, and External Memory Loader structure, but it does not contain the ThreadX, NetX Duo, and Ethernet application configuration.

Nx_UDP_Echo_Client, on the other hand, contains the required ThreadX, NetX Duo, Ethernet, LAN8742, and UDP configuration, but the complete application is assigned to the FSBL context instead of being built as a separate XIP Application.

Copying the complete Template_FSBL_XIP project and regenerating it with STM32CubeMX does not appear to provide all the required NUCLEO board headers, BSP files, middleware files, source files, and include paths needed for a complete project.

For example, some BSP and middleware files appear to be referenced through project-specific paths or additional project settings rather than being fully generated from the .ioc file.

What is the officially recommended workflow for creating this type of project?

 

Can the existing Template_FSBL_XIP.ioc be changed from:

board=custom

to the NUCLEO-N657X0-Q board configuration, or is the board information only applied when the project is initially created through the Board Selector?

Is there an official example, application note, or recommended procedure showing how to convert Nx_UDP_Echo_Client into an FSBL-XIP application?

I would prefer a fully STM32CubeMX-managed project that can be regenerated safely, instead of manually copying source files, middleware folders, BSP files, include paths, build settings, and linker sections between Template_FSBL_XIP and Nx_UDP_Echo_Client.

Could you please clarify the officially supported STM32CubeMX workflow for this use case?

Thank you.

[Khaled_DHIF]

Hello ​@FORVIA ,

Thanks for the detailed question.
For this use case, the recommended workflow is the same one described here:

• How to execute code from the external serial NOR using the STM32N6
  https://community.st.com/stm32-mcus-60/how-to-execute-code-from-the-external-serial-nor-using-the-stm32n6-146779

That article is not a ThreadX/NetX Duo end-to-end app note, but it serves as a starting point for the correct CubeMX workflow for building a fully configurable FSBL + XiP project and regenerating it safely.

For NUCLEO-N657X0-Q + ThreadX/NetX Duo, the practical approach is:

1. Create the FSBL/XiP architecture in CubeMX first (FSBL context, XSPI/XSPIM, EXTMEM_MANAGER, XiP offset/header, external loader flow), as shown in the article.
2. Keep FSBL minimal (clock, memory init, XSPI memory-mapped setup, jump to XiP app).
3. Put ThreadX/NetX Duo/Ethernet (LAN8742, IP stack, sockets/UDP/HTTP, etc.) in the XiP Application project context, not in FSBL.
4. Generate/build FSBL and Application as separate binaries, add headers/signing as required, then program at the proper external flash offsets with external loader enabled.
5. Regenerate from CubeMX and keep custom user code in user sections to preserve maintainability.

About your specific question:

• Changing an existing template from board=custom to a board profile is generally not the supported migration path for complete board setup.

Kind regards, 

DHIF Khaled

 

[FORVIA]

Hi @Khaled_DHIF,

Thank you for your response.

My question is: Why do you provide the “Template_FSBL_XIP” template for NUCLEO-N657X0-Q when it is ultimately misleading and cannot be used with STM32CubeMX and STM32CubeIDE?