Using the Cortex-M0+ as a load core, free GPIOs and the cycle counter on the Cortex-M33, and a common FreeRTOS/Zephyr workflow

[Iker14]

Hello,

I am a Master's student comparing FreeRTOS and Zephyr on the Cortex-M33 of the STM32MP257F-DK, with Linux running on the Cortex-A35. I measure task timing on the M33 with the DWT cycle counter and an oscilloscope, and I want a second core running a fixed bare-metal load in parallel to see how it affects the M33. A few things I could not find in the documentation:

1. Cortex-M0+ as load generator. Can the M0+ run its own firmware at the same time as the M33 (and Linux on the A35)? Can it exchange data with the M33 (shared memory, mailbox, other), and which memories can it access? Who starts it?

2. GPIOs for the M33. I need 2 or 3 pins that the M33 can toggle freely to measure with the oscilloscope. Which pins of the DK can be given to the M33, and what has to be changed (RIF, device tree)?

3. Firmware already on the M33. Does the DK ship with any firmware running on the M33 (for example USB-PD, as I saw reported for the EV1)? Can I load my own firmware without breaking the board?

4. Cycle counter. Is DWT_CYCCNT available to non-secure firmware on the M33?

5. FreeRTOS and Zephyr with the same workflow. I would like to build, load and debug both the same way. Zephyr uses west and OpenOCD, the CubeMP2 examples use STM32CubeIDE. Is there a recommended way to use one toolchain for both?

Thank you very much.

[jiangfan]

Short answer

• M0+ as parallel load generator: potentially yes, if supported by the platform boot/software setup
• Memory sharing with M33: yes, via shared assigned memory and messaging, if configured
• GPIOs for M33: yes, but only on pins free in the DK schematic and assigned to M33 through RIF/device tree configuration

NOTE: reviewed answer with help of AI

[Iker14]

Thank you for your answer. I still have one open point.

I need to run a small program on the Cortex-M0+ at the same time as my firmware on the Cortex-M33, to create a constant load while I measure the M33.

1. Is this officially supported? Is there an example or document that shows both cores running their own firmware at the same time? A yes or no is enough.
2. If yes, how is the M0+ started and loaded?

Also: does the DK come with any firmware already running on the M33?

Thank you.

[jiangfan]

You can find the projects for STM32MP257F-DK from:

STM32CubeMP2/Projects/STM32MP257F-DK at main · STMicroelectronics/STM32CubeMP2 · GitHub

CM0PLUS Demo seems to be a good start point.

[Iker14]

Thank you, the demo is very helpful. One last question: can the M0+ be started without Linux (for example from U-Boot or from the M33)?

[jiangfan]

Q: can the M0+ be started without Linux (for example from U-Boot or from the M33)?

 

The STM32CubeMP2 CM0PLUS_DEMO supports starting the Cortex-M0+ through the Linux remoteproc framework (remoteproc1). The supplied script loads an ELF from /lib/firmware and writes start to the remoteproc sysfs node. When firmware format is TEE, it uses a signed binary managed by OP-TEE.

We did not find an ST-provided or documented equivalent startup flow from U-Boot or from the Cortex-M33 for STM32MP257F-DK. Therefore, this should not be presented as an officially supported alternative to Linux remoteproc.

The M0+ can be loaded and run without Linux during development through ST/OpenOCD debug (reset, halt, download), as documented by the demo. That is a debug workflow, however, not an autonomous production boot flow.

A U-Boot- or M33-based launcher may be technically feasible only as a custom port, subject to the device’s RCC/reset, memory, RIF, and TrustZone/OP-TEE ownership configuration. 

NOTE: reviewed answer with help of AI

[Iker14]

Thank you very much for your detailed reply. It clarifies the supported way to start the Cortex-M0+ (Linux with remoteproc, or OpenOCD during development) and that starting it from the M33 or from U-Boot is not a documented or supported flow.

With this information we have several options to consider, and we will decide how to proceed with our tests.

Thanks again for your time and help.

Best regards,
Iker Castiella