Cortex M55/adiv6 support #1970

dragonmux · 2024-10-18T15:04:58Z

Discussed in #1969

^{Originally posted by florg-32 October 18, 2024}
Hey guys,

I have a Cortex M55 chip I'd like to debug with my BMP. Should this be supported already (on nightly builds)?

My gdb monitor jtag_scan does not find the device, voltage is detected correctly though and resetting works. The debug app outputs the following, which I don't really understand; shouldn't it be ADIv6?

❯ blackmagic -tjv8
Black Magic Debug App d896778
 for Black Magic Probe, ST-Link v2 and v3, CMSIS-DAP, J-Link and FTDI (MPSSE)
Using 1d50:6018 81D749A3 Black Magic Debug
 Black Magic Probe d896778
Running in Test Mode
Target voltage: 1.8V
Speed set to 1.951MHz for JTAG
Resetting TAP
Change state to Shift-DR
Scanning out ID codes
Return to Run-Test/Idle
Change state to Shift-IR
Scanning out IRs
Return to Run-Test/Idle
Change state to Shift-DR
Return to Run-Test/Idle
ID code 0x4ba06477: ADIv5 JTAG-DP port.
Abort: 00000004
Failed to read DPIDR
Given target number 1 not available max 0

Thanks,
Florian

The text was updated successfully, but these errors were encountered:

dragonmux · 2024-10-18T15:08:23Z

Following on from the discussion, could we please have you re-run your JTAG scan with a higher verbosity level - 8 only turns on PROTO diagnostics which isn't especially useful here unfortunately. For this we're going to need INFO + TARGET + PROBE, which is (1 + 4 + 16) or in other words, 21 for blackmagic -tjv 21. Hopefully that provides some more information on what actually came back from trying to do that DPIDR read and gives much needed additional information for interpreting the spec and part behaviour.

florg-32 · 2024-10-21T07:28:31Z

There you go

❯ blackmagic -tjv21
Black Magic Debug App d896778
 for Black Magic Probe, ST-Link v2 and v3, CMSIS-DAP, J-Link and FTDI (MPSSE)
Using 1d50:6018 81D749A3 Black Magic Debug
 Black Magic Probe d896778
Remote is Black Magic Probe d896778
Running in Test Mode
Target voltage: 1.8V
Speed set to 1.951MHz for JTAG
Resetting TAP
remote_jtag_init
Change state to Shift-DR
Scanning out ID codes
Return to Run-Test/Idle
Change state to Shift-IR
Scanning out IRs
Return to Run-Test/Idle
Change state to Shift-DR
Return to Run-Test/Idle
ID code 0x4ba06477: ADIv5 JTAG-DP port.
Enumerated 1 devices
0: IR length = 4, ID 4ba06477
-> IR prescan: 0, postscan: 0
-> DR prescan: 0, postscan: 0
Failed to read DPIDR
Given target number 1 not available max 0

The SWD scan fails as well unfortunately

❯ blackmagic -tv21
Black Magic Debug App d896778
 for Black Magic Probe, ST-Link v2 and v3, CMSIS-DAP, J-Link and FTDI (MPSSE)
Using 1d50:6018 81D749A3 Black Magic Debug
 Black Magic Probe d896778
Remote is Black Magic Probe d896778
Running in Test Mode
Target voltage: 1.8V
Speed set to 1.951MHz for SWD
remote_swd_init
Switching out of dormant state into SWD
remote_v0_swd_seq_out 32 clock_cycles: ffffffff
remote_v0_swd_seq_out 28 clock_cycles: 0fffffff
remote_v0_swd_seq_out 32 clock_cycles: 6209f392
remote_v0_swd_seq_out 32 clock_cycles: 86852d95
remote_v0_swd_seq_out 32 clock_cycles: e3ddafe9
remote_v0_swd_seq_out 32 clock_cycles: 19bc0ea2
remote_v0_swd_seq_out 12 clock_cycles: 000001a0
remote_v0_swd_seq_out 32 clock_cycles: ffffffff
remote_v0_swd_seq_out 32 clock_cycles: 0fffffff
remote_v0_swd_seq_out 8 clock_cycles: 000000a5
remote_v0_swd_seq_in 3 clock_cycles: 00000007
remote_v0_swd_seq_in_parity 32 clock_cycles: ffffffff ERR
remote_v0_swd_seq_out 8 clock_cycles: 00000000
Deprecated JTAG to SWD sequence
remote_v0_swd_seq_out 32 clock_cycles: ffffffff
remote_v0_swd_seq_out 28 clock_cycles: 0fffffff
remote_v0_swd_seq_out 16 clock_cycles: 0000e79e
remote_v0_swd_seq_out 32 clock_cycles: ffffffff
remote_v0_swd_seq_out 32 clock_cycles: 0fffffff
remote_v0_swd_seq_out 8 clock_cycles: 000000a5
remote_v0_swd_seq_in 3 clock_cycles: 00000007
remote_v0_swd_seq_in_parity 32 clock_cycles: ffffffff ERR
remote_v0_swd_seq_out 8 clock_cycles: 00000000
No usable DP found
No target found

dragonmux · 2024-10-21T15:40:37Z

Ack, the SWD side might well need #1959 to work then if this part implements dormant state. We'll try and get that PR reviewed today to check it's inserting a fully correct JTAG -> DS sequence and that it runs through the JTAG-or-SWD state machine correctly.

With regards to the JTAG side of this, that didn't produce as much output as we were expecting, so could you please crank the debug output further to -v 45 (ie blackmagic -tjv 45)? This should detail the exact DPIDR traffic that got generated. Unfortunately it will also make the JTAG chain scan very verbose.

florg-32 · 2024-10-21T16:12:32Z

Next try ;)

blackmagic -tjv 45

Black Magic Debug App d896778
 for Black Magic Probe, ST-Link v2 and v3, CMSIS-DAP, J-Link and FTDI (MPSSE)
Using 1d50:6018 81D749A3 Black Magic Debug
 Black Magic Probe d896778
+#!GA#
       KBlack Magic Probe d896778
!HC#
       K4
!HA#
       K9
!GP0#
       K0
!GZ0#
       K0
Running in Test Mode
 !GV#
       K1.8V
Target voltage: 1.8V
!GF003d0900#
       K0
!Gf#
       KD9C81D00
Speed set to 1.951MHz for JTAG
Resetting TAP
+#!JS#
       K0
+#!JR#
       K0
Change state to Shift-DR
!JT031#
       K0
Scanning out ID codes
!Jd20ffffffff#
       K4BA06477
!Jd20ffffffff#
       KFFFFFFFF
Return to Run-Test/Idle
!JN11#
       K1
!JT021#
       K0
Change state to Shift-IR
!JT043#
       K0
Scanning out IRs
!JN01#
       K1
!JN01#
       K0
!JN01#
       K0
!JN01#
       K0
!JN01#
       K1
!JN01#
       K1
Return to Run-Test/Idle
!JN11#
       K1
!JT021#
       K0
Change state to Shift-DR
!JT031#
       K0
!JN01#
       K0
!JN01#
       K1
Return to Run-Test/Idle
!JN11#
       K1
!JT021#
       K0
!HJ000000040000ffffffff#
       K0
ID code 0x4ba06477: ADIv5 JTAG-DP port.
Abort: 00000004
!JT043#
       K0
!JD048#
       K1
!JT021#
       K0
!JT031#
       K0
!Jd2020#
       K4
!JD030#
       K0
!JT021#
       K0
!AR0001000000000000#
       E104
Failed to read DPIDR
Given target number 1 not available max 0

I'll give #1959 a try tomorrow as well.

Thanks, I really appreciate the effort!

dragonmux · 2024-10-21T16:17:02Z

Thank you very much! We'll dig into the logs in a bit and go decoding E104 (in before this turns out we need to do dormant-to-JTAG sequences or something) and use this information to really dig into the ADIv6 spec sections on JTAG DP's. We'll update this issue to let you know how we're getting on and you'll probably see a new branch created aimed at fixing this.

dragonmux · 2024-10-21T17:15:38Z

Okay, so - it turns out that we were correct to think there would need to be some low-level changes for ADIv6 JTAG - they split out the OK/FAULT codes for the ACK and BMD is interpreting the OK ACK code as an invalid ACK here. Hence E104 which is indicating the firmware threw an exception in response. A fix for that is now available on feature/adiv6-jtag-support though we are certain that branch will not work correctly yet as we didn't yet get past the low-level aspects. Hopefully it get significantly further though. You will need to upgrade your probe's firmware for this to work.

florg-32 · 2024-10-22T09:45:04Z

Here are the logs from feature/adiv6-jtag-support, looks quite the same unfortunately.

build/blackmagic -tjv45

Black Magic Debug App v1.10.0-1366-g9c69fbd8
 for Black Magic Probe, ST-Link v2 and v3, CMSIS-DAP, J-Link and FTDI (MPSSE)
Using 1d50:6018 81D749A3 Black Magic Debug
 Black Magic Probe v1.10.0-1366-g9c69fbd8
+#!GA#
       KBlack Magic Probe v1.10.0-1366-g9c69fbd8
!HC#
       K4
!HA#
       K9
!GP0#
       K0
!GZ0#
       K0
Running in Test Mode
 !GV#
       K1.8V
Target voltage: 1.8V
!GF003d0900#
       K0
!Gf#
       KD9C81D00
Speed set to 1.951MHz for JTAG
Resetting TAP
+#!JS#
       K0
+#!JR#
       K0
Change state to Shift-DR
!JT031#
       K0
Scanning out ID codes
!Jd20ffffffff#
       K4BA06477
!Jd20ffffffff#
       KFFFFFFFF
Return to Run-Test/Idle
!JN11#
       K1
!JT021#
       K0
Change state to Shift-IR
!JT043#
       K0
Scanning out IRs
!JN01#
       K1
!JN01#
       K0
!JN01#
       K0
!JN01#
       K0
!JN01#
       K1
!JN01#
       K1
Return to Run-Test/Idle
!JN11#
       K1
!JT021#
       K0
Change state to Shift-DR
!JT031#
       K0
!JN01#
       K0
!JN01#
       K1
Return to Run-Test/Idle
!JN11#
       K1
!JT021#
       K0
!HJ000000040000ffffffff#
       K0
ID code 0x4ba06477: ADIv5 JTAG-DP port.
Abort: 00000004
!JT043#
       K0
!JD048#
       K1
!JT021#
       K0
!JT031#
       K0
!Jd2020#
       K4
!JD030#
       K0
!JT021#
       K0
!AR0001000000000000#
       E104
Failed to read DPIDR
Given target number 1 not available max 0

dragonmux · 2024-10-22T16:46:26Z

Interesting.. given that's still using the high-level API to drive what it's doing, could we please ask you to pass -H to BMDA as well as in blackmagic -Htjv 45 please? This will use only the JTAG remote protocol directly and not the ADI acceleration protocol, which might well show why DPIDR is reading badly.

Edit: Turns out that in trying to correct the missing ACK handling, we broke a core part of adiv5_jtag_raw_access() - we have just pushed a fix for this to the branch along with the SWD->DS->JTAG sequence logic to make things work if the device implements Dormant State.

florg-32 · 2024-10-23T07:55:12Z

Next try

./build/blackmagic -Htjv 45

Black Magic Debug App v1.10.0-1370-g51ddc057
 for Black Magic Probe, ST-Link v2 and v3, CMSIS-DAP, J-Link and FTDI (MPSSE)
Using 1d50:6018 81D749A3 Black Magic Debug
 Black Magic Probe v1.10.0-1370-g51ddc057
+#!GA#
       KBlack Magic Probe v1.10.0-1370-g51ddc057
!HC#
       K4
!HA#
       K9
!GP0#
       K0
!GZ0#
       K0
Running in Test Mode
 !GV#
       K1.8V
Target voltage: 1.8V
!GF003d0900#
       K0
!Gf#
       KD9C81D00
Speed set to 1.951MHz for JTAG
Resetting TAP
+#!JS#
       K0
+#!JR#
       K0
Change state to Shift-DR
!JT031#
       K0
Scanning out ID codes
!Jd20ffffffff#
       K4BA06477
!Jd20ffffffff#
       KFFFFFFFF
Return to Run-Test/Idle
!JN11#
       K1
!JT021#
       K0
Change state to Shift-IR
!JT043#
       K0
Scanning out IRs
!JN01#
       K1
!JN01#
       K0
!JN01#
       K0
!JN01#
       K0
!JN01#
       K1
!JN01#
       K1
Return to Run-Test/Idle
!JN11#
       K1
!JT021#
       K0
Change state to Shift-DR
!JT031#
       K0
!JN01#
       K0
!JN01#
       K1
Return to Run-Test/Idle
!JN11#
       K1
!JT021#
       K0
!HJ000000040000ffffffff#
       K0
ID code 0x4ba06477: ADIv5 JTAG-DP port.
Abort: 00000004
!JT043#
       K0
!JD048#
       K1
!JT021#
       K0
!JT031#
       K0
!Jd2020#
       K4
!JD030#
       K0
!JT021#
       K0
Not using ADIv5 acceleration commands
!JT043#
       K0
!JD04a#
       K1
!JT021#
       K0
!JT031#
       K0
!Jd201#
       K4
!JD030#
       K0
!JT021#
       K0
!Jc0000000008#
       K0
Read DPIDR: 0x00000000
Failed to read DPIDR
Given target number 1 not available max 0

dragonmux · 2024-10-23T19:02:19Z

Thank you for the update and re-try - there's something really odd going on here which looks like it's going to take some additional debugging to figure out. If we decode the DPIDR request-response cycle, we get this as the result:

!JT043# ; 4 cycles, TMS sequence, 0x3 -> Idle -> Select-DR -> Select-IR -> Capture-IR -> Shift-IR
       K0
!JD04a# ; 4 cycles, TDI-TDO w/ final TMS high, 0xa (DPACC), Shift-IR -> Exit1-IR
       K1
!JT021# ; 2 cycles, TMS sequence, 0x1 -> Exit1-IR -> Update-IR -> Idle
       K0
!JT031# ; 3 cycles, TMS sequence, 0x1 -> Idle -> Select-DR -> Capture-DR -> Shift-DR
       K0
!Jd201# ; 32 cycles, TDI-TDO w/ final TMS low, 0x00000001, Shift-DR
       K4 ; Result: 0x00000004
!JD030# ; 3 cycles, TDI-TDO w/ final TMS high, 0x0, Shift-DR -> Exit1-DR
       K0 ; Result: 0x0
!JT021# ; 2 cycles, TMS sequence, 0x1 -> Exit1-DR -> Update-DR -> Idle
       K0
!Jc0000000008# ; 8 cycles, TDI low, TMS low -> Idle * 8
       K0

DPIDR should be reading something more like 0x4ba03477 for this part, not 0x00000004. That ack value of 0 is also very off
We're going to make an adjustment that causes the firmware to write SELECT before the DPIDR request in case there's some whacky state in the DP, noting that line reset / JTAG reset does not reset the DP state.

Edit: Ah, part of the PDIDR read routine assumes SWD right now, which means the RDBUFF read to actually get the response to the request is never done.. fixing that too.

dragonmux · 2024-10-23T19:46:23Z

We have just pushed a couple of changes to the branch that follow up on SELECT's value being questionable before the read, and the DPIDR read assuming SWD. We've tested it as best we can on the parts we have here, and it appears like it is working better (LPC4370 has a couple of JTAG-DP's that have IDCode 0x0ba01477 and when we remove the errata workaround for those, their DPIDR's read out a semi-sensical value of 0x0bb11477 now which is considerably better behaviour than before).

florg-32 · 2024-10-24T07:57:34Z

blackmagic -Htjv45

blackmagic -Htv45

blackmagic -Hjtv16

Now we're getting somewhere, output is to large to paste as text ;)

dragonmux · 2024-10-24T08:03:27Z

Given that got us so much further, you'd be welcome to drop the -H command line argument now as that's only serving to slow communications down and make the logs way more verbose than necessary. That's great news though - we'll give the logs a look and see what's next.

Please could we get blackmagic -tjv 5 or blackmagic -tjv 13 rather than -v 16? 16 turns on only PROBE-level diagnostics, but the more useful bits at this stage are INFO+TARGET(+PROTO) - 5 and 13 respectively.

Edit: As a side note, we're pleased to see that the ADIv6 environment once DPIDR has been read looks the same under JTAG as under SWD, that is a huge relief with how complicated things would have been otherwise. The next real hurdle is component identification and figuring out what, eg, a component PIDR of 0x04000bb9f0 actually is in terms of debug components. It appears to be an ARM-made component of some kind, but it's seemingly not in the CoreSight SoC-600 TRM. If you've got any clues from the part's TRM as to what we should be expecting on the DP's debug resource bus, that would be very helpful.

florg-32 · 2024-10-24T13:34:36Z

❯ ./build/blackmagic -tjv 13
Black Magic Debug App v1.10.0-1377-g37a24c83
 for Black Magic Probe, ST-Link v2 and v3, CMSIS-DAP, J-Link and FTDI (MPSSE)
Using 1d50:6018 81D749A3 Black Magic Debug
 Black Magic Probe v1.10.0-1377-g37a24c83
Running in Test Mode
Target voltage: 1.8V
Speed set to 1.951MHz for JTAG
Resetting TAP
Change state to Shift-DR
Scanning out ID codes
Return to Run-Test/Idle
Change state to Shift-IR
Scanning out IRs
Return to Run-Test/Idle
Change state to Shift-DR
Return to Run-Test/Idle
ID code 0x4ba06477: ADIv5 JTAG-DP port.
Abort: 00000004
Write SELECT: 0x00000000
Unhandled exception: Remote protocol exception
Aborted (core dumped)

🙃

with -H it produces more output
./build/blackmagic -Htjv 13

Edit: From what I can tell from the datasheets it should be "compliant with the Arm® Debug Interface Architecture Specification ADIv6.0" and there is talk about "CoreSight (CS) ROM". Sorry for being cryptic, I'll try to (get permission to) share more information ;)

dragonmux · 2024-10-24T19:41:21Z

Oh, interesting that the remote protocol flumps like that - having the output of -tjv 45 for that might well help as that indicates a bug in either the set-up for the request (eg, not copying the DP version information through to the probe) or some other problem that needs addressing with the ADI accelerations.

Yes, this device is complaint with ADIv6, that's why we've been having to do what we have to make it work, however that doesn't explain the base DP debug resource bus ROM table contents - specifically the PIDRs for the resources it defines seemingly not being anything we can find in the TRMs. That said, if that first resource is a ROM and noting that the SoC-600 TRM leaves the PIDR value for a ROM intentionally undefined, that could explain that:

Edit: However, the lack of DEVARCH non-zero value is a problem for that theory as that's the way you're supposed to tell it's one of those ROM tables. As mentioned, that PIDR doesn't appear anywhere in the CoreSight SoC-600 TRM, so any information you are able to get permission to share about the DP's ROM table specifically, would be greatly helpful. Once we can locate the Cortex-M55 core itself, we can use the Cortex-M55 TRM to help identify components that are not already identified.

dragonmux · 2024-10-24T20:41:03Z

We have updated the branch to include as many of the previously unknown CoreSight components as we were able to identify from the ROM tables and the CoreSight SoC-600 TRM + Cortex-M55 TRM. We have added the Cortex-M55 CPUID to the known CPUIDs and translated it. This should get things much further, but will still leave large gaps of "Debug component - Unknown" in the ROM tables display.

florg-32 · 2024-10-28T09:07:52Z

blackmagic -tjv 45

❯ ./blackmagic -tjv 45
Black Magic Debug App v1.10.0-1377-g37a24c83
 for Black Magic Probe, ST-Link v2 and v3, CMSIS-DAP, J-Link and FTDI (MPSSE)
Using 1d50:6018 81D749A3 Black Magic Debug
 Black Magic Probe v1.10.0-1377-g37a24c83
+#!GA#
       KBlack Magic Probe v1.10.0-1377-g37a24c83
!HC#
       K4
!HA#
       K9
!GP0#
       K0
!GZ0#
       K0
Running in Test Mode
 !GV#
       K1.8V
Target voltage: 1.8V
!GF003d0900#
       K0
!Gf#
       KD9C81D00
Speed set to 1.951MHz for JTAG
Resetting TAP
+#!JS#
       K0
+#!JR#
       K0
Change state to Shift-DR
!JT031#
       K0
Scanning out ID codes
!Jd20ffffffff#
       K4BA06477
!Jd20ffffffff#
       KFFFFFFFF
Return to Run-Test/Idle
!JN11#
       K1
!JT021#
       K0
Change state to Shift-IR
!JT043#
       K0
Scanning out IRs
!JN01#
       K1
!JN01#
       K0
!JN01#
       K0
!JN01#
       K0
!JN01#
       K1
!JN01#
       K1
Return to Run-Test/Idle
!JN11#
       K1
!JT021#
       K0
Change state to Shift-DR
!JT031#
       K0
!JN01#
       K0
!JN01#
       K1
Return to Run-Test/Idle
!JN11#
       K1
!JT021#
       K0
!HJ000000040000ffffffff#
       K0
ID code 0x4ba06477: ADIv5 JTAG-DP port.
Abort: 00000004
!JT043#
       K0
!JD048#
       K1
!JT021#
       K0
!JT031#
       K0
!Jd2020#
       K4
!JD030#
       K0
!JT021#
       K0
Write SELECT: 0x00000000
!AR0000000800000000#
       E104
Unhandled exception: Remote protocol exception
Aborted (core dumped)

The details are behind NDAs unfortunately 🤐 The chip has 2 M55 cores if that helps.

dragonmux · 2024-10-28T09:36:48Z

Thank you for the debug log from the remote protocol - very curious that writing SELECT explodes like that, but this gives us plenty of detail to work from to figure out why and how. Thank you.

We're extremely surprised that the ARM-made debug components on the DP are being held under NDA too - we understand if the Vendor doesn't want to share details of their components at this time, but the components that have us eyebrow raised have PIDRs 0x04000bb9f0 and 0x04000bb9ef - when decoded, the 0x04 and 0xbb parts of that decodes to ARM's JEP-106 (0x43b), meaning those are ARM components in the ROM Table of some kind.

florg-32 · 2024-10-28T09:43:55Z

Thanks for all the help!

It's not necessarily the debug components themselves, but the architecture of the chip, i.e. I'd have to cite a document that is under an NDA.

dragonmux · 2024-10-28T10:05:16Z

Ahh, we see - and we're guessing you don't necessarily know which ARM document defines the debug components in question to cite instead.. what a pickle. Still, we got most of the debug components figured out as they're defined in either the CoreSight SoC-600 TRM or the Cortex-M55 TRM, so you should see good decodes of most of the ROM tables now and BMD should see the Cortex-M55 cores and make them available as targets now.

We'll update this issue if we figure out what's going on with the remote protocol there and potentially a bugfix for it.

dragonmux · 2024-10-28T11:15:47Z

Okidokie, so - the remote protocol issue comes around because the protocol does not currently convey the DP version with the request packets, resulting in the firmware thinking the DP is a DPv0 while BMDA thinks it's a DPv3 and necessarily resulting in the ACK codes being mishandled in adiv5_jtag.c and an exception being thrown due to bad ACK (E104 -> Error, exception thrown, exception kind 1 aka EXCEPTION_ERROR).

We will go away and think on how on earth to make the infrastructure for JTAG work properly to avoid this problem and will update the issue again when we have something for you to test.

dragonmux · 2024-10-28T16:19:59Z

Please give the latest version of the branch a try, which implements a DP version command in the ADIv5 acceleration remote protocol. This should solve the remote protocol crash.

florg-32 · 2024-10-29T08:12:50Z

Sweet, blackmagic -tj is working without issue now and also correctly identifies the M55 debug components :) Debugging with gdb also works

dragonmux · 2024-10-29T08:18:09Z

That is a huge relief to hear! We'll get that branch converted to a PR then so it can be merged to main

florg-32 · 2024-10-29T08:57:37Z

I don't know if it is related (I'm more assuming some issue with how I setup the chip), but while load, interrupt and continue work fine, any pending breakpoint, n, s, si triggers a UsageFault because of an undefined instruction, but the stacked $pc looks fine.

Do you know if this could be somehow related to the debugger?

dragonmux · 2024-10-29T10:09:57Z

There is a chance, especially as we did not yet look at the Cortex-M55's DWT or FPB, that the control of those units for those debug functions is not quite right for the M55 and so causing that to occur - from memory, cortexm.c presumes one of two FPB unit versions, and if the new cores use a new version, adjustments likely need to be made.

dragonmux · 2024-11-02T20:45:41Z

As a note about the closure on this issue: We'll address the core-specific issues separately with a follow-up PR diving into what could be going wrong with the debugging the core. That keeps the PRs from getting out of hand and having too broad a scope.

We hope you'll be willing to test whatever changes wind up being required to make debug on the core work, seeing we don't have any Cortex-M55 targets here right now to be able to test changes against. We'll work from the TRMs and write changes based on the theory of what we're seeing, but this obviously doesn't always match up with reality.

florg-32 · 2024-11-04T08:05:31Z

Of course! I'm happy to help (and benefit from having a nice debugger ;)). Please just tag me on related PRs

dragonmux · 2024-12-06T12:14:49Z

We have just opened #2010 which between it and #2008 addresses what we could reproduce of the Cortex-M55 debug issue. Please let us know how you get on with these two PRs and what remains of the problems you were seeing. mean00's PR should fully address the DWT issues as ARMv8-M defines a new DWT which is why BMD was miss-driving it.

dragonmux added this to the v2.0 release milestone Oct 18, 2024

dragonmux added Bug Confirmed bug New Target New debug target labels Oct 18, 2024

dragonmux mentioned this issue Oct 29, 2024

Feature: ADIv6 JTAG support #1981

Merged

6 tasks

esden closed this as completed in #1981 Nov 2, 2024

dragonmux mentioned this issue Dec 6, 2024

Fix: ADI structural cleanup and ARMv8-M debug improvements #2010

Merged

6 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Cortex M55/adiv6 support #1970

Cortex M55/adiv6 support #1970

dragonmux commented Oct 18, 2024

dragonmux commented Oct 18, 2024 •

edited

Loading

florg-32 commented Oct 21, 2024

dragonmux commented Oct 21, 2024

florg-32 commented Oct 21, 2024 •

edited

Loading

dragonmux commented Oct 21, 2024

dragonmux commented Oct 21, 2024

florg-32 commented Oct 22, 2024

dragonmux commented Oct 22, 2024 •

edited

Loading

florg-32 commented Oct 23, 2024

dragonmux commented Oct 23, 2024 •

edited

Loading

dragonmux commented Oct 23, 2024

florg-32 commented Oct 24, 2024

dragonmux commented Oct 24, 2024 •

edited

Loading

florg-32 commented Oct 24, 2024 •

edited

Loading

dragonmux commented Oct 24, 2024 •

edited

Loading

dragonmux commented Oct 24, 2024

florg-32 commented Oct 28, 2024

dragonmux commented Oct 28, 2024

florg-32 commented Oct 28, 2024

dragonmux commented Oct 28, 2024

dragonmux commented Oct 28, 2024

dragonmux commented Oct 28, 2024

florg-32 commented Oct 29, 2024

dragonmux commented Oct 29, 2024

florg-32 commented Oct 29, 2024

dragonmux commented Oct 29, 2024

dragonmux commented Nov 2, 2024

florg-32 commented Nov 4, 2024

dragonmux commented Dec 6, 2024

Cortex M55/adiv6 support #1970

Cortex M55/adiv6 support #1970

Comments

dragonmux commented Oct 18, 2024

Discussed in #1969

dragonmux commented Oct 18, 2024 • edited Loading

florg-32 commented Oct 21, 2024

dragonmux commented Oct 21, 2024

florg-32 commented Oct 21, 2024 • edited Loading

dragonmux commented Oct 21, 2024

dragonmux commented Oct 21, 2024

florg-32 commented Oct 22, 2024

dragonmux commented Oct 22, 2024 • edited Loading

florg-32 commented Oct 23, 2024

dragonmux commented Oct 23, 2024 • edited Loading

dragonmux commented Oct 23, 2024

florg-32 commented Oct 24, 2024

dragonmux commented Oct 24, 2024 • edited Loading

florg-32 commented Oct 24, 2024 • edited Loading

dragonmux commented Oct 24, 2024 • edited Loading

dragonmux commented Oct 24, 2024

florg-32 commented Oct 28, 2024

dragonmux commented Oct 28, 2024

florg-32 commented Oct 28, 2024

dragonmux commented Oct 28, 2024

dragonmux commented Oct 28, 2024

dragonmux commented Oct 28, 2024

florg-32 commented Oct 29, 2024

dragonmux commented Oct 29, 2024

florg-32 commented Oct 29, 2024

dragonmux commented Oct 29, 2024

dragonmux commented Nov 2, 2024

florg-32 commented Nov 4, 2024

dragonmux commented Dec 6, 2024

dragonmux commented Oct 18, 2024 •

edited

Loading

florg-32 commented Oct 21, 2024 •

edited

Loading

dragonmux commented Oct 22, 2024 •

edited

Loading

dragonmux commented Oct 23, 2024 •

edited

Loading

dragonmux commented Oct 24, 2024 •

edited

Loading

florg-32 commented Oct 24, 2024 •

edited

Loading

dragonmux commented Oct 24, 2024 •

edited

Loading