ETH_MACCSRSWCR missing in CMSIS / STM32H7 header files

[LCE]

Heyho,

not really a bug, but the register 

ETH_MACCSRSWCR

is missing in the struct ETH_TypeDef, in the CMSIS / STM32H7 header files, at least for H723 .. H735.

Also checked the github repos.

Any specific reason for that?

[STackPointer64]

Hello @LCE,

I have escalated the issue to the relevant team for resolution. It is being tracked internally under ticket number 213690.

Best regards

[bbakram]

Hello @LCE,

Thank you for your feedback and for highlighting this point.

The ETH_MACCSRSWCR is not managed by the ETH HAL driver. Its purpose is to allow the MAC to respond with a Slave Error for accesses to reserved registers in CSR space. This is useful for Safety.

By default, the MAC responds with an Okay response to any register accessed from CSR space.

 

This feature, SEEN (Slave Error Response Enable), is intended for debugging purposes. It can be enabled by the user to detect any accesses to reserved registers in the CSR space; however, such accesses are already prevented by the ETH HAL driver implementation.

 

It is acceptable to add this register to the list of defined ETH peripheral registers in the CMSIS device file; however, it will not be handled or used by the ETH HAL driver in any way.

 

Meanwhile, please let us know, @LCE , if you have a concrete need to use this feature (Slave Error Response Enable) in your current application or in future developments.

 

Best regards,
Akram

[thismarkjohnson]

This register exists in the reference manual but isn’t exposed in CMSIS because it’s not implemented or supported on all H7 variants. ST usually omits such registers from ETH_TypeDef to keep the struct consistent across devices.

 

Thanks for the detailed explanation. This really clears up why the ETH_MACCSRSWCR register is intentionally not exposed in the CMSIS device headers and how the ETH HAL layer is designed to manage that internally.

Discussions like this are extremely helpful for developers who deal with low level configuration and performance critical systems. I also work with different technical tools and digital utilities where accuracy and proper implementation details matter a lot, especially for calculations and configuration workflows.

I have personally been collecting and organizing various useful utilities and tools for everyday technical needs, and having platforms that focus on simplicity and precision makes a big difference in productivity. For anyone interested in practical online tools and digital utilities, you can explore this site as well:
https://castleapkapps.com/

Really appreciate the insight shared here. This kind of clarification saves a lot of debugging time.

.

[LCE]

I don't really need it, and if I would simply edit the struct...

I think I came across that when working with the PTP offload feature.

 

I don't care about HAL, but I think it would be "cleaner" to have all device's registers in a struct definitions for a particular device.