Loading...
 

SW4STM32 and SW4Linux fully supports the STM32MP1 asymmetric multicore Cortex/A7+M4 MPUs

   With System Workbench for Linux, Embedded Linux on the STM32MP1 family of MPUs from ST was never as simple to build and maintain, even for newcomers in the Linux world.
And, if you install System Workbench for Linux in System Workbench for STM32 you can seamlessly develop and debug asymmetric applications running partly on Linux, partly on the Cortex-M4.
You can get more information from the ac6-tools website and download two short videos (registration required) highlighting:

System Workbench for STM32


STM32F072 CRC peripheral register definitions wrong

The I/O register definitions for the CRC peripheral present in the STM32F07x and STM32F09x devices is missing some items.

1. The CRC_POLY register is not defined.
2. The CRC_CR register is missing some bits, in particular, bits 5 and 6 which define the polynomial bit width.
3. The CRC_DR (data register) should be write-accessible as either a 8, 16, or 32 bit entity.

Odds are the reason for the omissions in (1) and (2) are due to the fact that only the F07x and F09x devices support a user-programmable polynomial. On lower-end F0 devices, the polynomial is fixed to the 32-bit Ethernet standard value.

The CRC data register (CRC_DR) can be write-accessed as either a 8, 16, or 32-bit entity. The results generated will vary depending on the data width written; i.e. if one were to write 0x000000AA (32-bit write) to this register, you will get a different result than if you were to write 0xAA (8-bit write) under the same starting conditions. The 32-bit write is actually treated as a command to generate a CRC on 4 8-bit values: 0xAA, 0x00, 0x00, 0x00.

Not a major issue, but thought the developers might like to know so they can fix it in a future release.

Thanks for this useful bug-report, I think you should report it at ST’s official forumsQuestion so they can fix it in the next version.

I should clarify - the issue is with the I/O register definitions used within the Debug Perspective. All of the CRC peripheral register definitions are present in the ST-provided CMSIS / HAL header files.

What I refer to in my original post are the register values one can examine via Window -> Show View -> I/O Registers when the Debug Perspective is active.

Is this something controlled by files/data provided by ST? If so, I’ll report the issue on the ST forum. My understanding is that this would be something controlled by the AC6-provided Eclipse plug-ins.


Hello MSchultz,

Thank you for your feedback. Indeed there seems to be an issue with the CMSIS register description file (STM32F072x.svd). The 2 first items should be easy to fix, the 3rd one might be more difficult, we will try to fix this as soon as possible.

Kind regards,

Pascale