V4

I too stumbled over the boundary conditions of the stdlib. A small comment on the net helped me to find the cause of a HardFault on a Cortex-M0 with very little RAM.
If you want to use functions from the stdlib, you should, as a precaution - allow the heap memory in the startup code - even if it is not required anywhere else in your own source code.
I wanted to use "rand()" and always ended up in the HardFault handler. The analysis has shown that "rand()" wants to allocate memory the first time it is called and in the event of an error it simply 'continues' and the write access then triggers a trap...

The pC/OS Kernel was ported to the Cortex-M0 Synwit Tech SWM181.

Additional ...32F103 MCU‘s who tolerate the orginal STM32F103 project of the pC/OS Kernel - connected via J-Link and flashed... no problems & works!

The pC/OS Kernel was ported to the RISC-V WCH CH32V103 & CH32V307.

The pC/OS Kernel was ported to the Cortex-M0 STM STM32G0xx.

The pC/OS Kernel was ported to the Cortex-M4 Artery AT32F403A.

Now that I was in contact with several GigaDevices MCUs when porting the pC/OS Kernel and the “similarities“ to STM MCUs were already noticeable, this time I intentionally ordered various ...32F103 MCUs, to take a look at this. Unfortunately there was no CKS32F103 - “only“ an STM32F103 - or a clone including the labeling...?

So I opened the original STM32F103 project of the pC/OS Kernel and connect the various boards via J-Link and flash them... except for the MM32F103 no problems & works!

I just can‘t get the MM32F103 to run with my own project too (incl. “MindMotion.MM32F103x8xB_DFP.1.4.8.pack“) under ARM-Keil MDK... Maybe I crashed it with this first flash attempt, even if I can still grab it, delete & flash it with the J-Link Commander ...

Only if I have the time and leisure to look further and deeper for differences.. probably not, sorry!

The pC/OS Kernel was ported to the Cortex-M4 GigaDevice GD32F303 and GD32F407.