Initial debug connection to TMS570LC43xx

Hello,
On your board, which TMS570 pin is being driven by nSRST? The MCU does not have an nSRST input, only nRST (warm reset) and nPORRST (power-on reset). If nRST was driven on the older board and nPORRST is driven on the current board, it could explain some behavior you are seeing.

Regards,
Karl

Hi,

Well I don't have the schematics. But the board UG says it's nRST. Also IcePick is alive. I tried with pressed nPORRST key on the board and I got nothing from IcePick. From that I'd conclude that nPORRST isn't pulled low.

WBR
Primoz

Hello,
In general, for ARM CoreSight based debug the nPORRST should reset all logic, including debug related logic. The nRST should reset all logic except debug (and a few other system peripherals). The nTRST is only a reset for the JTAG state machine and should not be impacting other logic.

What older TMS570 product are you using in comparison to the TMS570LC?

Regards,
Karl

Hi,

Additional symptoms are that CoreSight debug port (DP) is responsive with nRST line low (I can read and write CTRL/STAT register) but accessing ROM table to detect Cortex debug components fails. Same procedure works with TMS570LS2136, TMS570LS2125, TMS570LS1227, TMX570PSFC66, TMS570LS20216, TMS570LS30336...

WBR
Primoz

Hello Primoz,
I am going to forward your info to the design team to check the hookup. It might be that the design has the CS debug ROM connected to the wrong internal reset domain (nRST instead of nPORRST). Unfortunately I need help to confirm the internal hookup.

Regards,
Karl

Hi Karl,

Did you get any new information regarding this?

WBR,
Primoz

Hello Primoz,

The design team is running simulations to try to replicate the issue.  So far they have not replicated your issue but they have seen an abnormality which is under further investigation.  This may be a simulation setup issue, a silicon issue, or something else - it is not resolved at this moment.  As further information is available we will share it with you.

Best Regards,

Karl

Hi,

Once again I query about this.

Additionally I'd like to know how to reset widest range of silicon without killing the debug connection if devices runs for short amount of time after reset is released and before it is stopped by debugger. In that short run peripherals, PLL, etc. can be initialized which might disrupt initial flash programming.

I have tried to utilize the WIR functionality in ICEPick without success. Can you confirm that WIR works?

WBR,

Primoz

Hello,

I apologize, but I have no further updates from the design team.

Regarding the ICEPICK WIR, it is not supported on the TMSx70 family.  Your best option is to use the vector catch feature built into the CPU.  To do so, you must first establish a debug connection, then program the debug unit of the CPU to halt on the reset vector.  Next issue a system reset (not power-on reset) and you should see the device halted at the vector entry.

Regards,

Karl

Hello,

System reset via external pin?

Primoz

Via nRST pin, via software programming of system module reset request, or via ICEPICK "advanced reset" in CCS. Just do not use the nPORRST pin as it will also reset the CPU's debug unit and clear the programmed vector catch.

Regards,
Karl

Hello Primoz,
I have an update from the device team. They have confirmed an issue with the emulation hookup and it will be addressed in a future silicon update. I do not have details I can share on when updated silicon will be available.

Best Regards,
Karl Greb