2025-12-10 10:39 PM - last edited on 2025-12-12 7:10 AM by Andrew Neil
I have set up a STM32U5 nucleo board with an additional 8M of memory using an APS6404, following the example in AN5050. Initial setup was straightforward, but trying to create a ThreadX thread that uses an array in that section of memory as its stack isn't working -- local variables within the thread are fine, but function calls like printf("foo") or tx_thread_sleep(10) cause a hard fault.
This is my first project using a STM32 microcontroller, and think I'm missing some fundamental understanding of how this is supposed to work -- any suggestions for what I've missed / what I should try?
------------------ Details about what I'm trying -----------------
After following the steps given in AN5050, I updated my .ld file to create a corresponding memory section:
MEMORY
{
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 2496K
SRAM4 (xrw) : ORIGIN = 0x28000000, LENGTH = 16K
FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 4096K
OCTOSPI1 (xrw) : ORIGIN = 0x90000000, LENGTH = 8M
}
SECTIONS
{
.octospi1 :
{
. = ALIGN(4);
KEEP(*(.octospi1))
. = ALIGN(4);
} > OCTOSPI1
// [...snip...]
}
Then, I tried to assign a thread's stack to that section:
(This is following the example at https://community.st.com/t5/stm32-mcus/how-to-create-a-thread-using-azurertos-and-stm32cubeide/ta-p/49418, with __attribute__ added)
uint8_t memory_stack[8192] __attribute__((section(".octospi1")));
TX_THREAD memory_thread;
UINT App_ThreadX_Init(VOID *memory_ptr) {
// [...snip...]
ret = tx_thread_create(&memory_thread, "memory demo thread",
memory_thread_entry, 0,
memory_stack, 8192, 4, 1,
TX_NO_TIME_SLICE, TX_AUTO_START);
// [...snip...]
}Inside memory_thread_entry, individual variables work fine (and I've used the Memory Browser to confirm that they are in the .octospi1 section), but calls to e.g. printf("foo") or tx_thread_sleep(10) cause a hard fault. If I leave out the __attribute__ call in the above code, all calls in the thread work as I expect.
2026-01-12 7:27 AM
Hello @laura_l and welcome to the community;
First of all, I apologize for my late reply. I recommend you to look at How to debug a HardFault on an Arm® Cortex®-M STM32 - STMicroelectronics Community article may help you to find the HardFault root cause.
Thank you.
Kaouthar
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.