Unable to connect to demoted device with openocd via Tamarin cable

[MatthewPierson]

Hi, I am running into the following issue when attempting to connect to the device via openocd after pwning/demoting the device and configuring Tamarin to JTAG mode (Similar to #4, however they seem to have made it past this issue from what I can see).

matty@Matthews-MacBook-Pro-4 openocd % openocd -f ./tcl/interface/tamarin.cfg -f ../bonobo-configs/t8015.cfg
Open On-Chip Debugger 0.10.0+dev-gc6d4abbe (2023-01-20-13:31)
Licensed under GNU GPL v2
For bug reports, read
    http://openocd.org/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'swd'
Warn : Transport "swd" was already selected
adapter speed: 5000 kHz

Warn : Interface already configured, ignoring
Warn : Transport "swd" was already selected
Info : clock speed 10000 kHz
Info : SWD DPIDR 0x10006aad


Assertion failed: (false), function tamarin_swd_switch_seq, file tamarin.c, line 325.
zsh: abort      openocd -f ./tcl/interface/tamarin.cfg -f ../bonobo-configs/t8015.cfg

I have tested "Reset device" and "Reset and enter DFU mode", both work fine but I cannot seem to get anything else to work. I have tested my wiring with a multimeter and it all seems to be in the correct order, although the device does not show in macOS at all when connected in DFU mode with the Tamarin cable so maybe my wiring is wrong? I have tried swapping the wires around but had no luck there either.

I know that something is happening, since after enabling JTAG mode and attempting to run openocd I get the following output (snippet) from the Tamarin cable:

[connected, use CTRL+] to disconnect]
Good morning!

1: JTAG mode
2: DCSD mode
3: Reset device
4: Reset and enter DFU mode
R: Reset Tamarin cable
> 
Enabling JTAG mode.
Tristar request received...
JTAG mode active, ID pin in Hi-Z.
Setting SWD frequency to 1000 kHz
You can now connect with an SWD debugger.
Processing packet: ID: 0 Command: 4 Request: 0x00 Data: 0x00002710 Idle: 0
Executing set frequency
Setting SWD frequency to 10000 kHz
Processing packet: ID: 0 Command: 3 Request: 0x00 Data: 0x00000000 Idle: 0
Executing line reset
>> FFFFFFFF (32)
>> FFFFFFFF (32)
>> E79E (16)
>> FFFFFFFF (32)
>> FFFFFFFF (32)
Read loop>> 0 (32)
>> 0 (32)
>> 0 (32)
>> 0 (32)
>> A5 (8)
>> 1 (1)
<< 7 (3)
Processing packet: ID: 0 Command: 1 Request: 0xA5 Data: 0x00000000 Idle: 0
Executing read
Read loop>> 0 (32)
>> 0 (32)
>> 0 (32)
>> 0 (32)
>> A5 (8)
>> 1 (1)
<< 7 (3)
Read: 7 0x10006AADProcessing packet: ID: 0 Command: 2 Request: 0x81 Data: 0x0000001E Idle: 0
Executing write
Write loop>> 0 (32)
>> 0 (32)
>> 0 (32)
>> 0 (32)
>> 81 (8)
>> 1 (1)
<< 7 (3)

Any ideas? If you need more information from me then I'm happy to provide it :)

[nezza]

Heya, the DPIDR is definitely not correct, so it might be an eletrical issue. Does reset work? There also appear to be some issues with the pin-states sometimes that I will debug next week. Will update you then!

Cheers

[MatthewPierson]

Reset does work, just double checked it now. I'll go over all the wiring today and check it again incase thats the problem, else I'll wait for your update next week. Thank you!

[MatthewPierson]

Upon closer inspection I realized that I had L0n/L0p and L1n/L1p round the wrong way🤦, however swapping them didn't change anything regarding DCSD or JTAG working. However I saw Linus Henze's fork of this project on his twitter (also in the #9 pull request) and gave that a go which got me further than main did. With his fork I'm able to use DCSD mode and all the reset/reset to DFU features, however I am now running into the same issue that blackndoor in #4 ended up hitting, where openocd complains about missing UTT configurations then eventually errors out. Can close this issue if you'd like, since it's now essentially a duplicate of #4. Thanks! :)