App crashes after changing main-stack-size in mbed_app.json

Mbed OS
1

Hi,

I am having some really weird problem with mbed + nucleo_f207zg. Can someone offer some pointers?

On a customized PCB built around STM32F207ZGT6, if I leave main stack size as default 8192, then the app works largely fine.

"config": {
    "main-stack-size": {
        "value": 8192   // changing this line causing trouble
    }
},

Once I change main stack size to something bigger, such 8196 or 8190, app will crash upon boot.

++ MbedOS Error Info ++
Error Status: 0x80010132 Code: 306 Module: 1
Error Message: Thread: 0x0, Unknown
Location: 0x80039F7
File: mbed_rtx_handlers.c+115
Error Value: 0x0
Current Thread: <unnamed> Id: 0x0 Entry: 0x8003BCB StackSize: 0x0 StackMem: 0x8005E0D SP: 0x2001FF0C 
For more info, visit: https://mbed.com/s/error?error=0x80010132&tgt=NUCLEO_F207ZG
-- MbedOS Error Info --

Changing main stack size to smaller number 4096 doesn’t lead to crash of app.

Information might be relevant:

  1. VCAP_1 and VCAP_2 pins are floating. The board was designed with STM32F303ZE in mind but STM32F207ZG was populated by accident. I feel this might be the main cause. In theory, missing capacitors on those pins will make MCU unstable.

  2. STDIO_UART_TX/RX pins are changed to PB_6 and PB_7, and reused in code.

RawSerial cmdPort(PB_6, PB_7, 115200);

I have done this in previous project and it worked just fine.

  1. I tried Mbed-os-5.14 and 5.15. Both had the same problem though.

  2. When I compile with GCC_ARM V9 I get the following warning, but this warning message doesn’t show up if I compile with GCC_ARM V6. Not sure if this relevant though.

[Warning] rtx_kernel.c@93,3: 'memset' offset [17, 164] from the object at 'osRtxInfo' is out of the bounds of referenced subobject 'kernel' with type 'struct <anonymous>' at offset 8 [-Warray-bounds]

  1. If I wrap the following code into a separate function, then call it instead of inline code, I got weird problems as well.

     sendCmdResponse(response, responseLen);
 /* the commented out lines won't work if wrapped up in a function
 for (size_t i = 0; i < responseLen; i++)
 {
     while (!cmdPort.writeable()) ;
     cmdPort.putc(response[i]);
 }
 */

It is probably safer to just order another batch of PCB but I would like to make sure there is no potential design problems other than VCAP pins.

Thanks.

2

Doesn’t it have to be multiple of 8 bytes because of the alignment?

3

I think this should be one of the problems. I actually tried to double 8192 but did math wrong in my head.

The problem listed as #5 seems to be related to GCC_ARM V9.

Thanks.