Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixing bad MEM-AP BASE #1640

Open
cetuscetus opened this issue Oct 29, 2023 · 0 comments
Open

Fixing bad MEM-AP BASE #1640

cetuscetus opened this issue Oct 29, 2023 · 0 comments

Comments

@cetuscetus
Copy link

Hi,

I've come across a device family which does not work with pyocd because in its AHB-AP#0 BASE register, the P bit is erroneously set to 0. Just like the YTM32B1ME0 discussed in PR #1255, albeit from a different manufacturer.

Both devices implement CoreSight SoC-400 (ARM doc. ddi0480) with
DP IDR = 0x6ba02477 (v2 rev6)
AHB-AP#0 IDR = 0x84770001 (AHB-AP var0 rev8)

While YTMicro have opted to add their chips to pyocd as built-in targets and included the fix-up code for the BASE register from @flit in there, this other family is not built in but have a <datapatch> in their CMSIS-packs to sort this out.

My first thought was, wouldn't this just give the right motivation to add datapatch support to pyocd? But then I had another idea.

This mistake appears to be somewhat common. (Is the SoC-400 integration manual perhaps not very clear on how bit P should be tied up?) Wouldn't then "be lenient in what you accept" be a better approach here? After all, bit P seems to be just an optimisation hint: if there are no debug components on this bus, the debugger will find it out fairly quickly anyway, after scanning the ROM table hierarchy.

The benefit I see here is that it doesn't preclude target auto-detection (when/if implemented in pyocd) even on chips that get their rom base wrong. Once the cores are found, the debug target can in theory be automatically identified, packs loaded and built-in fix-ups applied. Requiring a priori knowledge of the target type just to be able to find its cores isn't ideal – it always irks me when my debug tools insist on knowing the exact part number when they should be perfectly capable of finding it out on their own.

Just thought I'd invite opinions on what would be the best way to add support for the TI MSPM0 series:

  1. Ignore bit [0] if bit [1] is set to 1 and the value is not otherwise invalid.
  2. Add built-in target definitions just to fix up rom base (but delegate the rest, such as the flash algo, to the CMSIS-pack).
  3. Implement data patching (I can slowly look into this in long winter evenings...).

I don't like option 2, as I find built-in targets non-scalable, and anything that can be done through packs should be – that's the beauty of pyocd.

Any thoughts?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant