Tiva TM4C129

[froloffw7]

I found some issues with TI MSP432P401R, while attempting to reflash TM4C1294NCPDT firmware implementing builtin XDS 110 JTAG programmer, which was broken during the update and doesn't enter DFU mode.
TI suggest to use JTAG (seems this is the only possible way). As I don't have any TI XDS JTAG programmer, I'm trying to do the same with some other JTAG hardware.
I didn't achieve any success with Altera Byte Blaster neither with DirtyJtag+openocd(patched). It can detect the CPU, but then failed during initialization.
I managed to do so after making some changes of the blackmagic sources.

• Tiva C123 and C129 have different DID0 codes, file src/target/lmi.c:

defines:

  #define DID0_CLASS_STELLARIS_FURY 0x00010000U
  #define DID0_CLASS_STELLARIS_DUST 0x00030000U
> #define DID0_CLASS_TIVA           0x00050000U
< #define DID0_CLASS_TIVA_C123      0x00050000U
< #define DID0_CLASS_TIVA_C129      0x000a0000U

  #define DID1_LM3S3748      0x1049U
  #define DID1_LM3S5732      0x1096U

lmi_probe() function:

	        return lm3s_probe(t, did1);
>	case DID0_CLASS_TIVA:
<	case DID0_CLASS_TIVA_C123:
<	case DID0_CLASS_TIVA_C129:
		return tm4c_probe(t, did1);b

• function adiv5_dp_init(), file src/target/adiv5.c can't detect APs on DP correctly.

It call many times, until the memory exhausted, adiv5_new_ap(), which every time return the same AP despite of different apsel. I'm not familiar with this JTAG internals but if I remove the APs probe loop, calling adiv5_new_ap() only once, everything start working and I can connect to the target with GDB.

[dragonmux]

Many thanks for the fixes for lmi.c - if you could open a PR with those two changes, we will happily merge the result.

Regarding ADIv5 and AP detection, that is extremely unfortunate as that's the only way we can detect and handle multi-AP DPs (surprisingly common!). If that still happens even on #1389 or fix/cortexm-halt-resume-correctness then what will probably have to happen is a special-case check for the MSP432? TM4C129? (we're not certain which one exhibits the problem) after adiv5_component_probe() returns that fast-exits out of the loop for those parts.

[froloffw7]

I'm running blackmagic on STM32F103 (bluepill) and the target is TM4C1294NCPDT chip.

what will probably have to happen is a special-case check for the MSP432? TM4C129? (we're not certain which one exhibits the problem) after adiv5_component_probe() returns that fast-exits out of the loop for those parts.

I thought about this also, but didn't see easy way to do so without using some global variable.

Attaching here debug output with APs probe loop, after last line BMP hangs.
blackmagic.log

PS Does Black Magic support JTAG chain?

[dragonmux]

Very much so - monitor auto_scan and monitor jtag_scan, the former does JTAG-then-SWD scanning, the latter only does JTAG

Regarding how to work with that loop - the answer that comes to our mind is to extract if a target has been created, if there is only one target, and then check cortexm_ap(target)->part_id or similar (+ other factors) against a known profile for that part which then allows us to break out the loop early

[froloffw7]

It seems I have to fork the whole project to create PR.
Is it OK, if I attach the lmi.c patch file here?
blackmagic_tiva_patch.txt

[dragonmux]

The GitHub process is indeed to fork, make your changes following our contribution guidelines, then open a PR. We can make the changes just as easily, but then your fix will be stuck in the merge queue waiting on Esden being able to get to it (it's quite a large queue at this point) while if you make the change, we can review and merge it today.

We understand if you don't want to go through that though and are happy to apply the 2 fixes to the TM4C support.

[froloffw7]

OK, thank you.

PPS Any plans to support cJTAG (IEEE 1149.7)?

[dragonmux]

We need to review IEEE 1149.7 and see how difficult it would be to do, talk with Esden, and see where it would fit on the project roadmap and if we want to go to the effort (ie, what the cost-benefit analysis looks like).

If enough people would find it useful or it becomes absolutely necessary for, eg, RISC-V support, then that would certainly bump it up to, say, firmware v2.1 or v2.2.

That all said, it does not presently feature on the project roadmap (but that roadmap also needs reviewing to shape what will happen after v2.0, which is the release we will be working on once development of v1.10 wraps up).