Bug STM32H7x5_M4.svd with the HSEM registers has the interrupt and status addresses wrong

[GHolc.1]

I'm developing a project using the STM32H745 HSEM and found a couple problems with the svd file that make debugging more difficult. My contact with IAR suggested I share my finding with ST to see if a working version can be supplied.

1) The svd file for the M4 core, STM32H7x5_M4.svd has the wrong addresses for the M4 core for its HSEM_ICR, HSEM_IER, HSEM_ISR, and HSEM_MISR register (the M4 core svd file has the addresses for the M7 core for these 4 registers) as they are identical in the M4 and M7 svd file and they should not be identical. Accessing those four registers from the debugger for the M4 is accessing the registers that belong to the M7 core.

2) The svd file for the M4 core and for the M7 core have definitions to read all 32 of the HSEM_RLRx registers. The act of the debugger reading those registers through the compiler registers view window results in all of the semaphores that were unused to be locked to which ever core debugger read them first. Given that the debugger causes all the semaphores to lock, the definitions to read those RLRx registers should be removed from the svd file.

3) Less important, but when debugging the HSEM interrupt handling, I found it helpful for the debugger window for a core to be able to display the ICR, IER, ISR, and MISR for its own core and for the other core. Its useful to be able to see the opposite core ISR bit set when a semaphore is released for example, and that ISR bit set is in the opposite core's ISR register. This can be accomplished if using a separate debugger for each core but isn't as convenient.

[Imen.D]

Hello @Community member​ ,

I have raised this issue internally to be reviewed and treated accordingly to the priority.

(Internal Ticket ID 111357: This is an internal tracking number and is not accessible or usable by customers)

Thanks for your contribution.

Imen

[Imen.D]

Hi @GHolc.1 (Community Member)​ ,

I recommend that you use the SVD file (STM32H745_CM4.svd) dedicated to the STM32H745 device that you are using, as the STM32H7x5_M4.svd is considered obsolete now.

1. Looking at the latest release for SVD files, I can see that HSEM_ICR, HSEM_IER, HSEM_ISR, and HSEM_MISR registers are fixed (missing definition added for CPU2)
2. SVD file definition is based on RM definition, so removing HSEM_RLRx registers will raise questions by users. If there is the need to provide a customized SVD file without these registers than I can request this internally.
3. now there is definition for HSEM_CnIER, HSEM_CnICR, HSEM_CnISR, HSEM_CnMISR (n=1 to 2). n=1 is indicated CPU1(CM7) and n=2 is indicated CPU2(CM4).

These registers have different addresses, so now it is possible to debug for each core.

Please find the attached svd file for stm32H745(M7 and M4).

Do not hesitate to share your feedbacks.

When your question is answered, please close this topic by choosing Select as Best. This will help other users find that answer faster.

Imen

[GHolc.1]

Thank you Imen.

The obsolete SVD file was shared between the 32H745 and 32H755, the new file naming suggests maybe there is a separate SVD for the 32H755 micro, if that is the case could you share the one for the 755 too?

The ddf files distributed with the IAR compiler still reference that now obsolete svd file, I edited my ddf file to use the new SVD you supplied. Visibility of both IER ICR ISR and MISR is welcome. It would be nice if the note included in your message CPU1(CM7) or CPU2(CM4) could be included in those registers <description> field in the SVD file so we don't need to remember which CPU is which number.

I had to edit the SVD you supplied to remove the HSEM_RLRx registers before I could use it with the debugger to avoid having all the semaphores locked. I customized my SVD file so I don't need a customized SVD from ST.

[Imen.D]

Hi @Community member​ ,

There is a separate file for STM32H755 that is updated with in the recent package on ST website.

- The ddf files make part of the Ewarm patch delivered by ST for IAR. New IAR version should update those files in upcoming releases. Meanwhile it is possible to update them in the IDE manually as you did to point onto new SVD files when naming changes.

- Thank you for those feedbacks regarding CPU1 and CPU2. I raised this internally to enhance the quality of our SVD files and to take that into consideration.

Note that the new package for STM32H7 (v1.7) has been recently posted on ST website with all updated SVD files.

Thanks

Imen