Debug Port drops out

More specifically, this is the error I get during these times. It may be several minutes before it appears:
CORTEX_M4_0: Error: Debug Port error occurred.
CORTEX_M4_0: Trouble Halting Target CPU

Then I have to terminate the debug session. If I relaunch the debug session, everything works fine, until the cycle repeats.

I'm wondering if this is a physical hardware problem (e.g., voltage regulator browns out for a brief moment)... ?

Hi Mark,
What device are you running on? Is this a CC3200? Also, what version of TI-RTOS are you using?
Thanks,
Janet

TIVA! TM4C123GH6PM

TI RTOS version 2.16

I did more research on my board and I think it's fairly unlikely that my regulator is at fault. My regulator is rated for 250mA and my current draw is around 70mA.  When my radio is actively transmitting, it only pulls 18mA.

So, can a software bug cause the JTAG to drop out?

-Mark

Hi Mark,
Is this with the TI toolchain or GCC? Also how are the console and radio tasks communicating with the GUI and radio?
Thanks,
Janet

TI toolchain.

The "console" task was named that because when I started the project, I hadn't created a GUI yet. However, don't get it confused with the System_printf console...

The "console" task communicates via a UART.
The Radio task communicates to the RF chipset via SPI.

-Mark

Hi Mark,
Can you attach your board .c file (EK_TM4C123GXL.c)? I will see if I can reproduce the problem, somehow.
Thanks,
Janet

I don't think you would be able to reproduce the fault with my software because it runs on a custom board, not the evaluation kit. Also, the interaction with the radio IC includes SPI and a hardware GPIO interrupt.  These wouldn't be reproducible without the actual hardware. Also, the "console" task communicates at high speed with a desktop application, also not reproducible.

My question is generic: Can a software fault of any kind cause the JTAG to drop out (e.g., horrible RTOS kernel carnage), or is this something that can only happen as a result of a hardware fault (e.g., processor brown-out)?

I feel like this is a hardware fault, because JTAG should be a direct physical connection to the processor core itself, and not a service offered via software.  Thus, no software fault, no matter how catastrophic, should be able to cause the JTAG link to drop.  If this is indeed the case, I will need to modify the hardware design and spin a new board with more robust power supply isolation among the different components on the board.

-Mark

Hi Mark,

I haven't seen the JTAG connection lost due to a software bug.  I've seen it happen on the CC3200 when the device goes into low power mode.  You might post this on the Tiva device forum.  I'll see if I can get this post moved.

Best regards,

    Janet

I've moved your thread to the device forum. They might have some more insight into the issue.

Todd

Hello Mark,

As what Janet mentioned, are you using low power mode or changing system clock in system tasks?

Regards
Amit

I'm not using any low-power mode or changing the clocking while it's running.

I cut the power traces on my board yesterday and soldered wire directly from the primary regulator to the RF chipset to better isolate it from the TIVA part. Normally, the JTAG error occurs after a few minutes of running, but it was running happily after about an hour after making this change. I left the board to run overnight and I will update this feed with the results.

This is a good indicator (so far) that the root of the problem may have been electrical losses in the traces supplying power across my board. My board is small and relatively complex, so these traces were probably too thin given the "bursty" nature of the RF equipment.

-Mark