Access STM32MP153 Peripherals

I made a short post about this a couple of days ago, but want to revisit it. The STM32MP153 has lots of peripherals and I don’t understand how these can be fully exploited unless we either access the peripheral memory directly or utilize a rich set of abstractions that fully abstract each peripheral.

It would make sense I think to optionally allow managed code to access peripheral memory unsafely or expose a set of value type structs that map to the many peripheral registers.

It seems (to me) that an abstraction of the STM32 itself would be a sensible thing to have here.

Someone mentioned that there’s a variant of Linux running on the board that hosts the CLR, so it wil be the OS that regulates access to physical memory, and if the OS denies access to the peripheral region then there’s nothing .Net can do about that.


I did some digging/hacking and found that the abstractions rely on a native API accessed through interop - “libgpiod”. The Microsoft GPIO classes use that library and that library is able to access the device memory.

The library is what does the “real” work and I see no reason why people developing managed code need to be restricted to that library, .Net doesn’t care what such code does.

In principle anyone could write a native library and write managed code that uses that, what I mean is, managed code is managed code and the provided MS IOT class libraries are just an option.

I wonder how the transition is handled that lets the native library access peripheral memory…

The world is now your oyster : Calling native code on the Endpoint

You can link to any .so file that is compiled for arm-none-linux-gnueabihf. If you have a static library, you will have to create a .so (shared library) wrapper for it.

1 Like

Plus, Endpoint have Register class you can use it to acess peripheral registers from C#

1 Like

Thanks to each of you, this is very helpful. I just looked at the “Register” class and I can now see there are interop calls that map/unmap memory pages and set the page protection. So that explains why the memory is ordinarily inaccessible.

I’ve worked extensively with memory mapping but only on Windows, how its done on Linux/Unix is unfamiliar to me (I see a “device” named “/dev/mem”).

What is the meaning of the register number that’s passed into Register.Read?

Ah found it !!

1 Like