Stack error when bootloader jumps to image with flash driver

Question

Hi, 
 e2Studio/SSP 7.5.1/1.7.8, S7G2 
 I have a working Thread-X application. I'm struggling with adding the simple serial bootloader to it. I've placed the image at 0x010200. The bootloader jumps to it just fine. However, as soon as I include the flash driver to the image HAL, the bootload jump fails with a stack error. 
 I'm confused as to what stack in the Thread-X application is affected by the addition of the flash driver to HAL. If one opens the configuration.xml file and selects BSP, the properties tab shows: 
 Main stack size, Process stack size, and Heap size 
 Is "main stack size" what is used by HAL? 
 Steve

Jeremy · Accepted Answer

No, each thread has it's own stack memory allocated. On a context switch, the PSP (Process Stack Pointer) is updated to point to the current stack location for that Thread in it's own stack memory area (this is done in the PendSV handler in synergy/ssp/src/framework/el/tx/tx_src/synergy/tx_thread_schedule.c, you will need to have the ThreadX source code added to the project to have that file in your project). If you look at the map file for a project with multiple threads you can see the different thread stack memory areas :- .stack_dummy 0x200156d0 0x5000 load address 0x00050f98 0x200156d0 . = ALIGN (0x8) 0x200156d0 __StackLimit = . *(.stack*) .stack 0x200156d0 0x1000 ./synergy/ssp/src/bsp/cmsis/Device/RENESAS/S7G2/Source/startup_S7G2.o .stack.camera_thread 0x200166d0 0x400 ./src/synergy_gen/camera_thread.o .stack.colour_thread 0x20016ad0 0x400 ./src/synergy_gen/colour_thread.o .stack.g_ip0 0x20016ed0 0x800 ./src/synergy_gen/common_data.o .stack.dhcp_printf_thread 0x200176d0 0x800 ./src/synergy_gen/dhcp_printf_thread.o .stack.g_http_server0 0x20017ed0 0x2000 ./src/synergy_gen/http_setup_thread.o 0x20017ed0 g_http_server0_stack_memory .stack.http_setup_thread 0x20019ed0 0x400 ./src/synergy_gen/http_setup_thread.o .stack.jpeg_thread 0x2001a2d0 0x400 ./src/synergy_gen/jpeg_thread.o 0x2001a6d0 __StackTop = . [!provide] PROVIDE (__stack, __StackTop) 0x2001a6d0 __RAM_segment_used_end__ = ALIGN (__StackTop, 0x4) The memory areas for the different Thread stacks are all in the .stack section, but they could equally be scattered across the SRAM. and the size of each of these stack memory areas is defined in the configurator :- you can see the thread stack memory allocated in the generated code for this thread (src\synergy_gen\http_setup_thread.c) :- To trap the stack monitor NMI interrupt you can register a callback for the NMI MPU stack monitor interrupt :- void usr_nmi_hw_stack_callback(bsp_grp_irq_t irq)__attribute__((optimize("-O0"))); R_BSP_GroupIrqWrite(BSP_GRP_IRQ_MPU_STACK, usr_nmi_hw_stack_callback); Then you can identify if it was the MSP or PSP stack that caused the overflow :- uint32_t psp; uint32_t msp; TX_THREAD * current_thread; CHAR * thread_name; void usr_nmi_hw_stack_callback(bsp_grp_irq_t irq) { SSP_PARAMETER_NOT_USED(irq); msp = __get_MSP(); psp = __get_PSP(); if ((R_SPMON->MSPMPUSA > msp) || (R_SPMON->MSPMPUEA < msp)) { __BKPT(0); // MSP stack outside range. Interrupt/kernel stack overflow. } else if ((R_SPMON->PSPMPUSA > psp) || (R_SPMON->PSPMPUEA < psp)) { current_thread = tx_thread_identify(); thread_name = current_thread->tx_thread_name; //Identify the currently executing thread __BKPT(0); // PSP stack outside range. Thread stack overflow. } else { } } If it is the PSP stack that has caused the NMI MPU stack monitor to fire, then increase the size of the stack for that thread, e.g. :-

Stack error when bootloader jumps to image with flash driver

Top Replies