ARM Cortex missing vPortSuppressTicksAndSleep() implementation

mbernd wrote on Wednesday, October 09, 2019:

Hello,

I’ve downloaded the FreeRTOS Version 10.2.1 and find out that the sleep mode
from FreeRTOS not started. After searching the configurations and source
code I’ve found that the function vPortSuppressTicksAndSleep() is not
implemented for all cores and for all compilers.

When I generate the code with the STM32CubeMX tool, than copy this tool a
other implementation of the port.c file.

Why exists for the Cortex M4F this implementation and not for the Cortex M0?

Why exists a different implementation for the ARM Cortex? The ARM CPU core
and their IRQ’s are designed for a RTOS OS and is in all variant the same.
So I think we need only one implementation of the port.c file. Only the
using of the MPU or not shall result in a different implementation.

The next point is the using of macros for rename of function names. That is
for safety, security implementation or implementation with MISRA coding
rules not good. It can implemented as an empty weak function in the OS
kernel and overwrite in the porting. Why did You use the very old mechanism
with macros?

Regards,

Bernd

rtel wrote on Wednesday, October 09, 2019:

I’ve downloaded the FreeRTOS Version 10.2.1 and find out that the sleep mode
from FreeRTOS not started. After searching the configurations and source
code I’ve found that the function vPortSuppressTicksAndSleep() is not
implemented for all cores and for all compilers.

When I generate the code with the STM32CubeMX tool, than copy this tool a
other implementation of the port.c file.

Why exists for the Cortex M4F this implementation and not for the Cortex M0?

It is implemented in the M3/4F/7 Cortex-M ports. There is currently a
pull request outstanding from a colleague that also adds it into the M0

  • but that is not tested or merged yet.

Why exists a different implementation for the ARM Cortex? The ARM CPU core
and their IRQ’s are designed for a RTOS OS and is in all variant the same.
So I think we need only one implementation of the port.c file. Only the
using of the MPU or not shall result in a different implementation.

This is historic - at first there was only M3. When the M4F launched we
didn’t want to have lots of pre-processor directives in the code to
switch the FPU in and out so had a separate port. Then when the first
M7 chips came out there was an errata that required that port to be
separate for r0p1 cores - although all other core revisions can use the
M4F port. Over the years we have ended up with a whole matrix of core
ports and compiler ports which is not great for maintenance - so when
the V8-M ports were released, which had yet another dimension (TrustZone
support) we did end up just releasing a single port then using the
pre-processer to enable and disable MPU, FPU and TrustZone support.

The next point is the using of macros for rename of function names. That is
for safety, security implementation or implementation with MISRA coding
rules not good. It can implemented as an empty weak function in the OS
kernel and overwrite in the porting. Why did You use the very old mechanism
with macros?

Which functions are you referring to? If the interrupt service routine
names then the names pre-date any CMSIS efforts to standardise the name
and you don’t need to re-name them - just install them directly in the
vector table. The suggestion to rename them with #defines in
FreeRTOSConfig.h is purely for convenience if you don’t want to edit the
vector table. Weak symbols cannot be used as the names are not the same.