CMSIS v2 stack size limited to 2^18 bytes (2^16 DWORDs): constraint or defect?

[DOsbo]

Hi, I'm not sure if this is the right spot for this question, but here goes. I've just migrated from CMSIS v1 to v2. One of the changes to the API was thread creation. The stack size is now specified in bytes instead of DWORDs.  The size is simply divided by 4 before it passes to FreeRTOS. That's ok, but for some reason it also casts the stack size to uint16_t. I think that is wrong. It should cast to configSTACK_DEPTH_TYPE

Unfortunately I have some legacy code that requires a stack far greater than 2^18 bytes (a highly recursive algorithm). In CMSIS v1 I could specify a 32bit stack size, but now v2 is limited to 16 bits.

Is my only option to make a modified cmsis_os2.c a local file so STM32CubeMx doesn't keep re-inserting the defect?

Change from:

else {
      if (mem == 0) {
        if (xTaskCreate ((TaskFunction_t)func, name, (uint16_t)stack, argument, prio, &hTask) != pdPASS) {
          hTask = NULL;
        }
      }
    }

to:

else {
      if (mem == 0) {
        if (xTaskCreate ((TaskFunction_t)func, name, (configSTACK_DEPTH_TYPE)stack, argument, prio, &hTask) != pdPASS) {
          hTask = NULL;
        }
      }
    }

[Pavel A. · Accepted solution]

What is your underlying RTOS and does it allow stack size this big? Call it directly, without the CMSIS crutches.

-- pa

[DOsbo]

Thanks for your reply Pavel. I quite like the CMSIS crutches; it beats calling FreeRTOS directly.

Yes, FreeRTOS does allow creating a stack that large. The stack size parameter type is controlled by configSTACK_DEPTH_TYPE which is defined as uint32_t in my case. I think you're right, I'll have to call FreeRTOS directly for the thread with the large stack.

It's still a defect, so I will log it in their github and hopefully they will pick it up for the next release.

Cheers

David