Support STM32G4 about renode

[PiotrZierhoffer]

Hi @qhdwight

Indeed, the autogenerated platforms don't have CAN - we don't really need them for the Zephyr samples used in the Zephyr Dashboard.

We do, however, have some CAN support for STM - please scan https://github.com/renode/renode/tree/master/platforms for "STMCAN" to see example usage.

[qhdwight]

Datasheet can be found here: https://www.st.com/resource/en/reference_manual/rm0440-stm32g4-series-advanced-armbased-32bit-mcus-stmicroelectronics.pdf

[PiotrZierhoffer]

Hi @qhdwight,

Thanks for reporting the issue.

While the Renode package does not contain the STM32G4 repl file, we do run this target in our Zephyr Dashboard - https://zephyr-dashboard.renode.io/

If you search for “g4” you will find three targets running plenty of Zephyr samples passing our tests. Clicking the board name will get you here: https://renodepedia.renode.io/boards/nucleo_g431rb/?view=software&demo=hello_world - all the build artifacts, including the REPL platform file, are there to be downloaded.

Please note that the platform description is autogenerated from the device tree file, so it might not cover the whole SoC. It is, however, sufficient to run the demos in the Dashboard.

We’d be happy to learn more about your project - feel free to reach out to [email protected] if you can share some details!

[qhdwight]

Hi @PiotrZierhoffer,

Thank you for the reply! I will check this out.

The application is for a student project team: https://github.com/umrover. We build mock rovers for a global competition that is held over the summer. Part of this is designing a custom brushed motor controller board that uses STM MCU's. We want to start doing hardware-in-the-loop testing and Renode seemed like a great place to start.

[qhdwight]

However I noticed that the .repl file does not have any can devices on it (which we make heavy use of).

I see CAN mentioned in the .dts file but I'm not sure how that plays into everything.

[qhdwight]

Currently trying out the .repl file from the page G431RB you linked. I added several lines for FDCAN based on the datasheet:

fdcan1: CAN.STMCAN @ sysbus <0x40006400, +0x400>

fdcan2: CAN.STMCAN @ sysbus <0x40006800, +0x400>

fdcan3: CAN.STMCAN @ sysbus <0x40006C00, +0x400>

My .resc script is:

using sysbus

mach create
machine LoadPlatformDescription @stm32g431.repl
machine StartGdbServer 3333

macro reset
"""
    sysbus LoadELF @Build/bdcmc.elf

"""

runMacro $reset

Everything seems to work until HAL_RCC_ClockConfig when I receive this error that I can see in the debugger:

The code can be found here: https://github.com/umrover/mrover-ros/blob/eb560e4c17ffde14cd5f0540b9712e7e723029a5/src/esw/fw/bdcmc/Core/Src/main.c#L90

I will keep debugging. Seems like this is a problem with the emulated RCC:

rcc: Python.PythonPeripheral @ sysbus 0x40021000
    size: 0x400
    initable: true
    filename: "scripts/pydev/flipflop.py"