Task Overflowed Stack on Certain Optimization

Kernel
1

anmc1112 wrote on Tuesday, July 23, 2019:

I’m working with the Zynq Ultrascale+ with FreeRTOS 10.2.1 using Xilinx SDK 2018.3.

I’m currently having an issue where my main() function will somehow be called a second time, and shortly after I will get the “task ## overrflowed its stack” when I have configCHECK_FOR_STACK_OVERFLOW set to 2. If I have configCHECK_FOR_STACK_OVERFLOW set to 1 I get “Assert failed in file tasks.c, line 2896”. I discovered that this is only a problem if i have the -O2 optimization set in the top-level Makefile. When set to -O1 the software works as expected (main only being called once), and when set to -O0 I don’t see anything run at all.

Does anyone have recommendations for how to debug this issue, it’s good I got my code running at least, but it seems concerning that it breaks for other optimization levels.

Thanks,
Andy

2

rtel wrote on Tuesday, July 23, 2019:

Can you elaborate on what the top level makefile is - what is it
building? Application code, BSP, or something else?

3

anmc1112 wrote on Tuesday, July 23, 2019:

Oops sorry, it’s the makefile for the FreeRTOS10/Xilinx Ultrascale+ r5 BSP.

4

rtel wrote on Tuesday, July 23, 2019:

If I understand correctly then then the optimisation level used in the
BSP project, which is the project that builds drivers, impacts whether
or not the application code (which is a separate project that depends on
the BSP project) executes reliably or not.

Is FreeRTOS being built as part of the BSP, or as part of the
application code? I only really have experience building it as part of
the application.

5

anmc1112 wrote on Tuesday, July 23, 2019:

Yes that is correct.

FreeRTOS is being built as part of the BSP. When you create a BSP in Xilinx SDK it brings in all the FreeRTOS files, and then I add TCP + FAT + IO files into the source folder.