TM4C129ENCPDT SWD scan failed after invalid oscillator configuration in firmware

[SlyCedix]

I recently switched from the EK-TM4C1294XL, which worked wonderfully with the BMP, to a custom board with the same chip.

I was able to scan, attach, program and debug the device one time. I stepped through my code until I got to the oscillator configuration at which point the program hung and the debugger disconnected. I have since discovered that the external oscillator I provided was connected to the wrong oscillator inputs rather than the primary oscillator inputs. Without some very careful soldering I will not be able to connect my 25 MHz oscillator to the correct pins. Fortunately there is an internal oscillator which should be good enough for my purposes.

Since this event:

I get the following whenever I scan:

(gdb) target extended-remote COM3
Remote debugging using COM3
(gdb) monitor swd_scan
Target voltage: 3.3V
SWD scan failed!
Failed

There is a ~3 second pause between Target voltage reporting and SWD scan failed.

If I use BMDA to get a little more information, I get the same output whether the board is powered by the BMP or externally:

blackmagic-bmda -d COM3 -tpv 5
Black Magic Debug App v2.0.0
 for Black Magic Probe, ST-Link v2 and v3, CMSIS-DAP, J-Link and FTDI (MPSSE)
Running in Test Mode
Target voltage: 3.3V
Speed set to 1.951MHz for SWD
Switching from JTAG to dormant
Switching out of dormant state into SWD
DP DPIDR 0x2ba01477 (v1 rev2) designer 0x43b partno 0xba
adiv5: power-down failed
No target found

A couple of times when testing, however, I got the following. I'm unsure what conditions were different:

blackmagic-bmda -d COM3 -tpv 5
Black Magic Debug App v2.0.0
 for Black Magic Probe, ST-Link v2 and v3, CMSIS-DAP, J-Link and FTDI (MPSSE)
Running in Test Mode
Target voltage: 2.3V
Speed set to 1.951MHz for SWD
Switching from JTAG to dormant
Switching out of dormant state into SWD
Deprecated JTAG to SWD sequence
DP DPIDR 0x2ba01477 (v1 rev2) designer 0x43b partno 0xba
AP   0: IDR=24770011 CFG=00000000 BASE=e00ff000 CSW=e3000040 (AHB3-AP var1 rev2)
Halt via DHCSR(00030003): success after 9ms
ROM Table: BASE=0xe00ff000 SYSMEM=1, Manufacturer 43b Partno 4c4 (PIDR = 0x04000bb4c4)
0 0x0e000e000: Generic IP component - Cortex-M4 SCS (System Control Space) (PIDR = 0x04000bb00c DEVTYPE = 0x00 ARCHID = 0x0000)
-> cortexm_probe
CPUID 0x410fc241 (M4 var 0 rev 1)
cortexm_probe: Examining Part ID 0x04c4, AP Part ID: 0x04c4
Calling sam3x_probe
Calling lmi_probe
1 0x0e0001000: Generic IP component - Cortex-M3 DWT (Data Watchpoint and Trace) (PIDR = 0x04003bb002 DEVTYPE = 0x00 ARCHID = 0x0000)
2 0x0e0002000: Generic IP component - Cortex-M3 FBP (Flash Patch and Breakpoint) (PIDR = 0x04002bb003 DEVTYPE = 0x00 ARCHID = 0x0000)
3 0x0e0000000: Generic IP component - Cortex-M3 ITM (Instrumentation Trace Module) (PIDR = 0x04003bb001 DEVTYPE = 0x00 ARCHID = 0x0000)
4 0x0e0040000: Debug component - Cortex-M4 TPIU (Trace Port Interface Unit) (PIDR = 0x04000bb9a1 DEVTYPE = 0x11 ARCHID = 0x0000)
5 0x0e0041000: Debug component - Cortex-M4 ETM (Embedded Trace) (PIDR = 0x04000bb925 DEVTYPE = 0x13 ARCHID = 0x0000)
ROM Table: END
Resuming target
***  1   Tiva-C M4
Attaching to target..
Halting target
remote_v4_adiv5_mem_write_bytes error around 0xe000edf0
remote_v4_adiv5_mem_read_bytes error around 0xe000edf0
Attach failed
Can not attach to target 1

[dragonmux]

Unfortunately, unless you can manage to push the target into the ROM bootloader or otherwise prevent the code from attempting normal boot there's not very much BMD can do - these parts don't do connect-under-reset (trying sees them held trying to even access the AP, much less doing anything else), and TI provides very few other utilities such as a recovery mechanism.

An example of what we mean:

❯ ./blackmagic -s 8BB20695 -tCpv 5
Black Magic Debug App v2.0.0-273-g1c6bd7812-dirty
 for Black Magic Probe, ST-Link v2 and v3, CMSIS-DAP, J-Link, FTDI (MPSSE) and WCH-Link
Using 1d50:6018 8BB20695 Black Magic Debug
 Black Magic Probe v2.0.0-rc2-82-gc77f806c
Connecting under reset
Running in Test Mode
Target voltage: 3.3V
Speed set to 1.951MHz for SWD
Switching from JTAG to dormant
Switching from dormant to SWD
Deprecated JTAG to SWD sequence
DP DPIDR 0x2ba01477 (v1 rev2) designer 0x43b partno 0xba
No target found

This is with a Tiva-C TM4C123GH6PM.

This is to do with the way the AP is integrated into the device and the hardware bugs present as a result.

[SlyCedix]

Well that's unfortunate. I'll see if I can get the oscillator hooked up properly.

Is this issue unique to SWD or would this have been an issue had I hooked up JTAG instead?

[dragonmux]

Issue is with the debug integrations of the AP itself, which doesn't matter about access protocol (the DP the protocols interface with works fine.. but the AP behind that is the bit that's screwed).

To explain diagrammatically as best as we can.. the structure of ADIv5 debug is essentially:

JTAG/SWD <=> DP <┬> AP0 <-> Cortex-M core0
                 ├> AP1 <-> Cortex-M core1
                 └> AP2 <-> Cortex-M core2

so if the AP is built wrong and reading registers from it or even controlling power supply to it is too dependant on core state, the result is what you see. Each of those blocks represents a control element with state and its own registers and the arrows indicate bridges between parts.

[SlyCedix]

That makes sense. Could this sequence from pg. 213 on the tm4c1294ncpdt datasheet yield any results? And if so, would it be in-scope for the BMP to perform it?

4.3.4.3 Recovering a "Locked" Microcontroller
Note: Performing the sequence below restores the non-volatile registers discussed in “Non-Volatile
Register Programming-- Flash Memory Resident Registers” on page 613 to their factory
default values. The mass erase of the Flash memory caused by the sequence below occurs
prior to the non-volatile registers being restored.
In addition, the EEPROM is erased and its wear-leveling counters are returned to factory
default values when performing the sequence below.
If software configures any of the JTAG/SWD pins as GPIO and loses the ability to communicate
with the debugger, there is a debug port unlock sequence that can be used to recover the
microcontroller. Performing a total of ten JTAG-to-SWD and SWD-to-JTAG switch sequences while
holding the microcontroller in reset mass erases the Flash memory. The debug port unlock sequence
is:
1. Assert and hold the RST signal.
2. Apply power to the device.
3. Perform steps 1 and 2 of the JTAG-to-SWD switch sequence on the section called “JTAG-to-SWD
Switching” on page 214.
4. Perform steps 1 and 2 of the SWD-to-JTAG switch sequence on the section called “SWD-to-JTAG
Switching” on page 215.
5. Perform steps 1 and 2 of the JTAG-to-SWD switch sequence.
6. Perform steps 1 and 2 of the SWD-to-JTAG switch sequence.
7. Perform steps 1 and 2 of the JTAG-to-SWD switch sequence.
8. Perform steps 1 and 2 of the SWD-to-JTAG switch sequence.
9. Perform steps 1 and 2 of the JTAG-to-SWD switch sequence.
10. Perform steps 1 and 2 of the SWD-to-JTAG switch sequence.
11. Perform steps 1 and 2 of the JTAG-to-SWD switch sequence.
12. Perform steps 1 and 2 of the SWD-to-JTAG switch sequence.
13. Release the RST signal.
14. Wait 400 ms.
15. Power-cycle the microcontroller.

[dragonmux]

Yes, that sequence could well be used as that triggers a self-wipe of the microcontroller, clearing Flash. You'll need to hack things up a little to do it, but you could add a command, say, "tm4c_erase" which then calls into a new routine in the Tiva-C code (lmi.c) which uses platform_nrst_set_val(), platform_target_set_power(), and the adiv5.h header to access ADIV5_SWD_TO_JTAG_SELECT_SEQUENCE and ADIV5_JTAG_TO_SWD_SELECT_SEQUENCE to send with the SWD interface in swd.h (swd_proc structure), calling swdptap_init() at the front of the routine to set that up.

Something along the lines of:

#include "swd.h"
#include "adiv5.h"

[...]

void lmi_recover(void)
{
	/* Initialise SWD communication, and do power-up sequence from TRM §4.3.4.3, pg213 */
	swdptap_init();
	platform_nrst_set_val(true);
	platform_target_set_power(true);
	platform_target_clk_output_enable(true);
	/* Wait 1ms for everything to stabilise after applying power */
	platform_delay(1);

	/* Ensure SWD DP in reset before starting sequences */
	swd_proc.seq_out(0xffffffffU, 32U);
	swd_proc.seq_out(0x0fffffffU, 32U);

	/* JTAG->SWD sequence */
	swd_proc.seq_out(ADIV5_JTAG_TO_SWD_SELECT_SEQUENCE, 16U);
	/* SWD->JTAG sequence */
	swd_proc.seq_out(ADIV5_SWD_TO_JTAG_SELECT_SEQUENCE, 16U);
	[...]

	platform_target_clk_output_enable(false);
	/* Release reset then wait 400ms */
	platform_nrst_set_val(false);
	platform_delay(400);
	/* Power down target */
	platform_target_set_power(false);
}

[SlyCedix]

Thank you for the assistance, I'm attempting to implement it now.

Would you like me to create a PR with this addition?

[dragonmux]

That's a great question and we're unsure - on one hand, it would be very handy to have BMD know how to do recovery, but on two others what this routine does depends heavily on being able to control target power or at least have the user aware they need to carefully so the chip's bought up under reset; and second that because a scan cannot have taken place before hand, there isn't really a natural place for such a command to exist within the code structure..

That said, even if it's #ifdef gated off by default, having the code present for a user to enable if they need it may also make a ton of sense.

[SlyCedix]

I'm a little busy right now with the project this is attached to, so if there isn't a natural place to slot in the recovery function I'll hold off on a PR. Hopefully I get a chance to work on it soon.

Also, when I try to compile with the additional code, I'm getting a a linking error with swdptap_init:

C:/Users/cthayer.OSI/scoop/apps/msys2/2024-12-08/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: blackmagic.exe.p/src_target_lmi.c.obj: in function `lmi_recover':
C:\Users\cthayer.OSI\osi\misc-projects\blackmagic\build/../src/target/lmi.c:187:(.text+0x2d7): undefined reference to `swdptap_init'
collect2.exe: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.

It builds just fine with swdptap_init() omitted. Am I misunderstanding something? Does swdptap_init require this to be a firmware build instead of BMDA?

[dragonmux]

Ah, yes, our apologies.. we only partially lifted the SWD scan code for that:

blackmagic/src/target/adiv5_swd.c

Lines 181 to 188 in 9428176

	#if CONFIG_BMDA == 0
	swdptap_init();
	#else
	if (!bmda_swd_dp_init(dp)) {
	free(dp);
	return false;
	}
	#endif

It needs at least one of those two done so the SWD structures are actually set up, but indeed it depends on whether building firwmare or BMDA

[SlyCedix]

Created a fork with the recovery sequence implemented temporarily as a global monitor command. https://github.com/SlyCedix/blackmagic/tree/lmi/recovery

Unfortunately, the sequence itself either doesn't work as the datasheet says, or I've made some error/misunderstanding.

$ build/blackmagic -pv 29
Black Magic Debug App 393585ad
 for Black Magic Probe, ST-Link v2 and v3, CMSIS-DAP, J-Link, FTDI (MPSSE) and WCH-Link
Using 1d50:6018 72AE0FF4 Black Magic Debug
 Black Magic Probe v2.0.0
Found AUX Serial at COM4
prefix: 7&33ac1c46&0
Using BMP at COM3
Remote is Black Magic Probe v2.0.0
Setting V6ONLY to off for dual stack listening.
Listening on TCP port: 2000
Got connection
Running LMI Recovery sequence.
remote_swd_init
remote_v0_swd_seq_out 32 clock_cycles: ffffffff
remote_v0_swd_seq_out 32 clock_cycles: ffffffff
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: ffffffff
remote_v0_swd_seq_out 16 clock_cycles: 0000e73c
remote_v0_swd_seq_out 32 clock_cycles: ffffffff
remote_v0_swd_seq_out 32 clock_cycles: ffffffff
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: ffffffff
remote_v0_swd_seq_out 16 clock_cycles: 0000e73c
remote_v0_swd_seq_out 32 clock_cycles: ffffffff
remote_v0_swd_seq_out 32 clock_cycles: ffffffff
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: ffffffff
remote_v0_swd_seq_out 16 clock_cycles: 0000e73c
remote_v0_swd_seq_out 32 clock_cycles: ffffffff
remote_v0_swd_seq_out 32 clock_cycles: ffffffff
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: ffffffff
remote_v0_swd_seq_out 16 clock_cycles: 0000e73c
remote_v0_swd_seq_out 32 clock_cycles: ffffffff
remote_v0_swd_seq_out 32 clock_cycles: ffffffff
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: ffffffff
remote_v0_swd_seq_out 16 clock_cycles: 0000e73c
platform_target_set_power failed, error 0
Speed set to 1.951MHz for SWD
remote_swd_init
remote_v0_swd_seq_out 32 clock_cycles: ffffffff
remote_v0_swd_seq_out 28 clock_cycles: 0fffffff
Switching from JTAG to dormant
remote_v0_swd_seq_out 5 clock_cycles: 0000001f
remote_v0_swd_seq_out 31 clock_cycles: 33bbbbba
remote_v0_swd_seq_out 8 clock_cycles: 000000ff
Switching from dormant to SWD
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
Read DPIDR: 0x00000000
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: 00000001
remote_v0_swd_seq_in_parity 32 clock_cycles: 2ba01477 OK
remote_v0_swd_seq_out 8 clock_cycles: 00000000
Read DPIDR: 0x2ba01477
Abort: 00000004
Write ABORT: 0x00000004
remote_v0_swd_seq_out 8 clock_cycles: 00000081
remote_v0_swd_seq_in 3 clock_cycles: 00000001
remote_v0_swd_seq_out_parity 32 clock_cycles: 00000004
remote_v0_swd_seq_out 8 clock_cycles: 00000000
Write SELECT: 0x00000000
remote_v3_adiv5_raw_access: addr 0008 <- 00000000 -> 00000000
remote_v0_swd_seq_out 8 clock_cycles: 000000a5
remote_v0_swd_seq_in 3 clock_cycles: 00000001
remote_v0_swd_seq_in_parity 32 clock_cycles: 2ba01477 OK
remote_v0_swd_seq_out 8 clock_cycles: 00000000
Read DPIDR: 0x2ba01477
DP DPIDR 0x2ba01477 (v1 rev2) designer 0x43b partno 0xba
Abort: 00000004
Write ABORT: 0x00000004
remote_v3_adiv5_raw_access: addr 0000 <- 00000004 -> 00000000
Write CTRL: 0x00000000
remote_v3_adiv5_raw_access: addr 0004 <- 00000000 -> 00000000
remote_v3_adiv5_dp_read: addr 0004 -> 00000000
Read STATUS: 0x00000000
Write CTRL: 0x50000000
remote_v3_adiv5_raw_access: addr 0004 <- 50000000 -> 00000000
remote_v3_adiv5_dp_read: addr 0004 -> f0000000
Read STATUS: 0xf0000000
Read AP 0 IDR: 0x00000000
Abort: 00000004
Write ABORT: 0x00000004
remote_v3_adiv5_raw_access: addr 0000 <- 00000004 -> 00000000
Read AP 1 IDR: 0x00000000
Abort: 00000004
Write ABORT: 0x00000004
remote_v3_adiv5_raw_access: addr 0000 <- 00000004 -> 00000000
Read AP 2 IDR: 0x00000000
Abort: 00000004
Write ABORT: 0x00000004
remote_v3_adiv5_raw_access: addr 0000 <- 00000004 -> 00000000
Read AP 3 IDR: 0x00000000
Abort: 00000004
Write ABORT: 0x00000004
remote_v3_adiv5_raw_access: addr 0000 <- 00000004 -> 00000000
Read AP 4 IDR: 0x00000000
Abort: 00000004
Write ABORT: 0x00000004
remote_v3_adiv5_raw_access: addr 0000 <- 00000004 -> 00000000
Read AP 5 IDR: 0x00000000
Abort: 00000004
Write ABORT: 0x00000004
remote_v3_adiv5_raw_access: addr 0000 <- 00000004 -> 00000000
Read AP 6 IDR: 0x00000000
Abort: 00000004
Write ABORT: 0x00000004
remote_v3_adiv5_raw_access: addr 0000 <- 00000004 -> 00000000
Read AP 7 IDR: 0x00000000
Abort: 00000004
Write ABORT: 0x00000004
remote_v3_adiv5_raw_access: addr 0000 <- 00000004 -> 00000000

(gdb) tar ext :2000
(gdb) mon recover
(gdb) mon tpwr enable
Enabling target power
(gdb) mon swd_scan
Target voltage: 3.3V
SWD scan failed!
Failed

[dragonmux]

Ah, well one small issue that might not be helping things is that the last nibble in the line reset writes needs to be a 0 to complete the line reset and enough cycles happen in idle state for the mode transitions to work:

remote_v0_swd_seq_out 32 clock_cycles: ffffffff
remote_v0_swd_seq_out 32 clock_cycles: ffffffff # This should be 0fffffff
remote_v0_swd_seq_out 16 clock_cycles: 0000e79e

[SlyCedix]

Ah, I missed that. Unfortunately doesn't seem to have made a difference, though.

[SlyCedix]

Ended up hacking the hardware to hook up the oscillator, got my chip up and running.

Looks like the erase sequence is still not working, which is unsurprising. I'm gonna close this issue but I may come back to see if I can get the recovery sequence working once I'm a bit less busy.

[dragonmux]

Glad you've been able to recover your device at least. We'll be interested to see what you manage to achieve with the recovery sequence when you come back to it as that is an interesting addition to us.