pengi / arm_gdb

Python module for an easier access to analyze ARM Cortex-M peripherals
MIT License
21 stars 3 forks source link

Register clusters not supported #5

Open pengi opened 1 year ago

pengi commented 1 year ago

Describe the bug Some platforms have what's called "Register clusters" which acts like structs, making a set of registers reusable.

One example usage is to cluster DMA related registers in nrf52840 SPIS peripheral, so RXD, TXD clusters have the same registers, configuring the data pointers.

To Reproduce Steps to reproduce the behavior:

  1. Load nrf52840 svd file (a version using clusters)
  2. Run arm list nrf52840 SPIS

Expected behavior I expect to see RXD and TXD registers

Screenshots / Logs Seems to be missing.

(gdb) arm list nrf52840 SPIS2 
Registers in SPIS2 @ 0x40023000:
 - TASKS_ACQUIRE @ +0x24
        ...............................# TASKS_ACQUIRE
 - TASKS_RELEASE @ +0x28
        ...............................# TASKS_RELEASE
 - EVENTS_END @ +0x104
        ...............................# EVENTS_END
 - EVENTS_ENDRX @ +0x110
        ...............................# EVENTS_ENDRX
 - EVENTS_ACQUIRED @ +0x128
        ...............................# EVENTS_ACQUIRED
 - SHORTS @ +0x200
        .............................#.. END_ACQUIRE
 - INTENSET @ +0x304
        ..............................#. END
        ...........................#.... ENDRX
        .....................#.......... ACQUIRED
 - INTENCLR @ +0x308
        ..............................#. END
        ...........................#.... ENDRX
        .....................#.......... ACQUIRED
 - SEMSTAT @ +0x400
        ..............................## SEMSTAT
 - STATUS @ +0x440
        ...............................# OVERREAD
        ..............................#. OVERFLOW
 - ENABLE @ +0x500
        ............................#### ENABLE
 - CONFIG @ +0x554
        ...............................# ORDER
        ..............................#. CPHA
        .............................#.. CPOL
 - DEF @ +0x55c
        ........................######## DEF
 - ORC @ +0x5c0
        ........................######## ORC

Desktop (please complete the following information):

pengi commented 1 year ago

This issue actually seems to be solved in master branch from cmsis-svd without integration. Keeping bug open until it's possible to do a decent solution.

The issue is that the solution is from 2018 (five years ago, current date), but last tagged version is from 2016, so need to install the git version of cmsis-svd

A temporary workaround until a new version of cmsis-svd is released, uninstall cmsis-svd and reinstall from git

pip uninstall cmsis_svd
pip install 'git+https://github.com/posborne/cmsis-svd@master#egg=cmsis-svd&subdirectory=python'

Haven't really checked yet though. The issue I have is that SPIS2 from their nrf52840.svd doesn't contain TXD and RXD clusters. But it might be more related to that those parameters doesn't follow the <peripheral derivedFrom="SPIS0"> tag, since TXD and RXD seems to work in SPIS0

pengi commented 1 year ago

There is a patch already apparently. However, not merged.

https://github.com/posborne/cmsis-svd/pull/100

pengi commented 1 year ago

Hum... better command to update is:

pip install -U 'git+https://github.com/posborne/cmsis-svd@master#egg=cmsis-svd&subdirectory=python'

This is a real problem, so should should add that also to the documentation. But probably need to fork posborne/cmsis-svd to not rely on the release cycle of that project

salkinium commented 1 year ago

Maybe just use the URL in the pyproject.toml?

pengi commented 1 year ago

Oh, didn't know that was possible. Just assumed that would be issues with dependencies for the user that installs a package. Thanks for the link. I might fix that soon

However, there are still issues that are not merged, which results in missing register clusters... Needs to think about it a bit

salkinium commented 1 year ago

Yeah, it's probably not wise to directly depend on the master branch of a repository you don't control, that can easily lead to very annoying bugs. So forking it and merging all issues you need is probably best, but then again you might as well just publish in on PyPi anyways… so. meh?