Issue after modifying linker script to use larger RAM region on STM32N6570-DK

[saib]

Hello ST Community,

I'm working on an STM32N6570-DK project where I've merged two example codes from the STM32CubeN6 repository:

1 . DCMIPP_ContinuousMode

https://github.com/STMicroelectronics/STM32CubeN6/tree/main/Projects/STM32N6570-DK/Applications/DCMIPP/DCMIPP_ContinuousMode 

•   Used for capturing data from the IMX335 camera and displaying it on LTDC.

2 . Nx_WebServer

https://github.com/STMicroelectronics/STM32CubeN6/tree/main/Projects/STM32N6570-DK/Applications/NetXDuo/Nx_WebServer

• Modified to set a static IP and transmit packets over Ethernet and not using the SD card part and FileX.

The merged code compiles successfully in STM32CubeIDE. I've attached a ZIP file containing the full merged project for reference.

Initially, I used the linker script (STM32N6XX_AXISRAM2_fsbl.ld) , which allocates 512KB of RAM (255K + 256K) and manages Ethernet buffers, I attached .txt file named WORKING.

• Camera image is visible on the LCD.

• Ethernet packets (with static data) are sent at ~900 Mbps.

Problem:

I need more RAM for my application. So, I modified the .ld file  , i attached the txt file named NOT_WORKING 

The code still compiles successfully. However, after flashing the via STM32CubeIDE:

• The program flashes correctly but starts executing automatically (without manual reset or intervention).
• No image is displayed on the LCD (camera data not appearing).
• No Ethernet packets are transmitted or received.
• The board does not respond to pings, and networking seems completely non-functional.

The main problem is that , whenever i tried to modify to increase the RAM  size the program starts automatically and struck in Reset Handle.

Questions :

• Why does the program start executing automatically after flashing? In the original setup, it doesn't auto-run like this?

• Are there specific adjustments needed for Ethernet buffers (like .tcp_sec or .nx_data) when scaling up RAM? I removed the absolute addresses, but perhaps they need remapping.

Any help or insights would be greatly appreciated!

Thanks in advance,

[Saket_Om · Accepted solution]

Hello @saib 

To resolve these issues, you should keep the code and vector table in ROM/Flash and only expand the RAM region for data, buffers, and stack as needed. Make sure to retain the absolute addresses for the Ethernet and NetXDuo buffers and use the AT>ROM directive for the .data section to ensure proper initialization. If you need more RAM for large buffers, consider defining a dedicated section for them within the expanded RAM region, but avoid moving executable code or the vector table out of ROM/Flash.

[saib]

hello mr @Saket_Om 

  Yes, I have tried what you suggested. I did not move the vector table and only expanded the RAM region, as shown below:

MEMORY

{

ROM (xrw) : ORIGIN = 0x34180400, LENGTH = 255K

RAM (xrw) : ORIGIN = 0x341C0000, LENGTH = 1024K /*to 1024K to fit large buffer */

}

• Then I created a dedicated section for the large buffer:

.large_buffer (NOLOAD) :
{
. = ABSOLUTE(0x34200000);
*(.large_buffer)
}

• And in the code I declared the buffer like this:

__attribute__((section(".large_buffer"), aligned(8)))
uint8_t large_buffer[614400];

1. But I am still encountering the same issue: when I flash the code, execution starts automatically and gets stuck in the Reset_Handler.
2. Could you please check my LD file (attached below) and suggest how it should be modified to work properly?
   Also, could you explain why this behavior occurs even though I gave the correct addresses?

Thanks in advance for your help!

[STackPointer64]

Hello @saib, and welcome to ST Community!

After analyzing your project and discussing it with @Saket_Om, we found that the typical suggestion applies to other MCUs but not to STM32N6 FSBL projects. The maximum code size must not exceed 511 KB due to the bootROM size restriction, which includes a 1 KB header and authentication padding. You can refer to the articles below for more details.

To resolve your issue, you should recreate your project so that the FSBL only initializes the system and loads the main application from a separate project. This approach allows you to bypass the bootROM size limitation and thus utilize more RAM in your application.

• STM32N6 FSBL explained 
• STM32N6 boot ROM explained 

Best regards,