Skip to content

Conversation

@bugadani
Copy link
Contributor

No description provided.

@korken89
Copy link
Collaborator

Looking forward to this! 🚀 You go!

@bugadani bugadani force-pushed the jtag branch 2 times, most recently from 9e1376d to afd4b7b Compare April 13, 2025 07:55
@bugadani
Copy link
Contributor Author

I think in places it's really obvious that I'm working with a bitbanging implementation on the other end, so I can pretty easily affort 1-bit sequences in the API - for my case. Not sure if that is acceptable for more sophisticated implementations, but regardless of that, this PR needs some debugging work before I can start thinking about that :)

This PR is largely based on the CMSIS-DAP library that the RPi debugprobe sources pull in (which then don't end up using JTAG...), and they have largely been mechanically transcribed. As that wasn't particularly easy, I expect the code to have issues, although right now my setup seems broken and I can't even make sense of the logic analyzer trace I captured yesterday.

My next step is to get an ESP32-based implementation working, so that I can attach a debugger without fear of tearing off test points from the RPi debugprobe, hopefully that will make it easier to find out what goes wrong and where.

@bugadani
Copy link
Contributor Author

bugadani commented Apr 14, 2025

Fixed a few things, probe-rs can now output at least something:

 INFO attach: probe_rs::probe::cmsisdap: Using protocol JTAG
 INFO probe_rs::probe::cmsisdap: JTAG DR scan chain detected as 64 bits long
 INFO probe_rs::probe::cmsisdap: JTAG IR scan chain detected as 9 bits long
 INFO probe_rs::probe::common: Found IDCODE: 0x4BA00477 (ARM Ltd)
 INFO probe_rs::probe::common: Found IDCODE: 0x16468041 (STMicroelectronics)
 INFO probe_rs::probe::common: IR lengths are unambiguous: [4, 5]
 INFO probe_rs::probe::cmsisdap: Configuring JTAG with ir lengths: [4, 5]
 INFO probe_rs::architecture::arm::sequences: Debug port Default is powered down, powering up
 INFO probe_rs::architecture::arm::communication_interface: Debug Port version: DPv0 MinDP: NotImplemented
 WARN probe_rs::architecture::arm::memory::romtable: Component at 0xe0001000: CIDR0 has invalid preamble (expected 0xd, got 0x0)
 WARN probe_rs::architecture::arm::memory::romtable: Component at 0xe0001000: CIDR2 has invalid preamble (expected 0x5, got 0x0)
 WARN probe_rs::architecture::arm::memory::romtable: Component at 0xe0001000: CIDR3 has invalid preamble (expected 0xb1, got 0x0)
 WARN probe_rs::architecture::arm::memory::romtable: Component at 0xe0000000: CIDR0 has invalid preamble (expected 0xd, got 0x1)
 WARN probe_rs::architecture::arm::memory::romtable: Component at 0xe0000000: CIDR1 has invalid preamble (expected 0x0, got 0x1)
 WARN probe_rs::architecture::arm::memory::romtable: Component at 0xe0000000: CIDR2 has invalid preamble (expected 0x5, got 0x1)
 WARN probe_rs::architecture::arm::memory::romtable: Component at 0xe0000000: CIDR3 has invalid preamble (expected 0xb1, got 0x1)
 WARN probe_rs::architecture::arm::memory::romtable: Component at 0xe0040000: CIDR0 has invalid preamble (expected 0xd, got 0x0)
 WARN probe_rs::architecture::arm::memory::romtable: Component at 0xe0040000: CIDR2 has invalid preamble (expected 0x5, got 0x0)
 WARN probe_rs::architecture::arm::memory::romtable: Component at 0xe0040000: CIDR3 has invalid preamble (expected 0xb1, got 0x0)
 INFO probe_rs::architecture::arm::sequences: Powering down debug port Default
ARM Chip with debug port Default:

Debug Port: DPv0, Designer: <unknown>
└── V1(0) MemoryAP
    └── 0 MemoryAP (AmbaAhb3)
        ├── 0xe00ff000 ROM Table (Class 1), Designer: STMicroelectronics
        ├── 0xe0001000 Generic
        ├── 0xe0000000 Generic
        ├── 0xe0040000 Generic
        └── 0xe0041000 Cortex-M4 ETM   (Coresight Component)

Designer: <unknown> indicates something is still not quite right, though - SWD prints Debug Port: DPv1, Designer: ARM Ltd.

@bugadani
Copy link
Contributor Author

Hmm I think I got this right, just DPIDR comes back as 0 over JTAG for whatever reason. This chip is iffy (SWD seems to be sampled incorrectly) so maybe I should expect anomalies like this.

I was able to run an embedded-test test suite, so I guess it's time to start cleaning this up :)

@bugadani
Copy link
Contributor Author

Let's see what we can do with this :)

 cargo probe-rs run --chip stm32g431kb --protocol jtag "C:\_Hobby\rpi-smoke-tester-setup\embedded-test\tests\stm32g431kb"
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.57s
     Running `target\debug\probe-rs.exe run --chip stm32g431kb --protocol jtag C:\_Hobby\rpi-smoke-tester-setup\embedded-test\tests\stm32g431kb`
      Erasing ✔ 100% [####################]  18.00 KiB @  42.22 KiB/s (took 0s)
  Programming ✔ 100% [####################]  18.00 KiB @  24.01 KiB/s (took 1s)                                                                                                                                                                
     Finished in 1.18s

running 1 test
test test::test ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.06s

 cargo probe-rs run --chip stm32g431kb --protocol swd "C:\_Hobby\rpi-smoke-tester-setup\embedded-test\tests\stm32g431kb" 
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.61s
     Running `target\debug\probe-rs.exe run --chip stm32g431kb --protocol swd C:\_Hobby\rpi-smoke-tester-setup\embedded-test\tests\stm32g431kb`
      Erasing ✔ 100% [####################]  18.00 KiB @  45.91 KiB/s (took 0s)
  Programming ✔ 100% [####################]  18.00 KiB @  28.35 KiB/s (took 1s)                                                                                                                                                                
     Finished in 1.03s

running 1 test
test test::test ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.15s

@bugadani bugadani marked this pull request as ready for review April 16, 2025 19:07
@korken89
Copy link
Collaborator

Very nice! Is there also a reference implementation in e.g. the Rusty Probe's firmware? I'm thinking about how I'll test the PR.

@korken89
Copy link
Collaborator

Do you have a reference implementation I can port to the Rusty Probe? I think that should be enough to validate this as working. :)

@bugadani
Copy link
Contributor Author

https://github.com/bugadani/fruitfly

@korken89
Copy link
Collaborator

I've started the implementation here: probe-rs/rusty-probe-firmware#31

@bugadani
Copy link
Contributor Author

Sorry Emil, I don't really want to merge PRs without you, but I don't want to force you into writing code for this, either. I also trust the PR enough to think it's useful in the state it is - I've used this to interface with multiple devices using multiple debug probe implementations and I'd like to move on to other work. I don't expect this code to be perfect, but I think I've reasonably matched ARM's implementation. I believe we can improve everything iteratively as we need to.

@bugadani bugadani merged commit 8e29465 into probe-rs:master May 18, 2025
@bugadani bugadani deleted the jtag branch May 18, 2025 20:32
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

Successfully merging this pull request may close these issues.

2 participants