TMS570LC4357-EP: Error while programming the chip on custom board

Hi,

Johan Bertrand said:

We are able to load a program on the development board using the cJTAG 4 pin method, that we are also using on our custom board.

I'm not clear with some of your statements. You said cJTAG 4 pin method. First of all,  cJAG is a 2-pin method based on IEEE1149.7 as opposed to 4-pin JTAG (IEEE 1149.1). In cJTAG, the TMS, TDI and TDO are multiplexed. The TMS570LC4357 does not support cJTAG. It only supports the traditional JTAG including the nTRST. 

If I understand you correctly, you are able use XDS200 to properly load a program to the MCU's flash on the EVM board, but not your custom board. Is that correct?

Johan Bertrand said:

It seems like it we are able to connect to the target and run the current memory code by going in the debug mode (target -> Launch selected configuration -> connect to target), however the the PC is always going on the address 0x00000004.

I tried to change the memory by going into Tools->Memory fill, and I trying to change at the memory 0x00000000, but I got a memory writing error ("memory map preventing writing")

You cannot fill memory at addresses starting at 0x0 because this is a flash memory. You need a flash programmer to load code to flash which occupies memory addresses starting at 0x0. You can only do memory fill on a SRAM. The SRAM starts at 0x08000000, not 0x0. 

Johan Bertrand said:

We check all the resets, they are in High state (3.3V), and the power lines are well connected. The test pin is also connected to GND. The JTAG test routine in the target configuration is working fine, and is not producing any error.

Again, please confirm if you can successfully load a simple program to the EVM board, either the HDK or the LaunchPad board using XDS200. If you can successfully load a program to the EVM board then it means your target configuration should be correct. The only difference is the PCB.

I will suggest you:

- Change the TCLK speed to lower value. Will that make a difference?

- compare your custom board schematic and the EVM schematic and can you find any subtle differences?

Here is a link that provides guidance on JTAG troubleshooting. Search for the error code -1170 and -242 as reported in your console log. 

https://software-dl.ti.com/ccs/esd/documents/ccs_debugging_jtag_connectivity_issues.html

Hi,

Thank you very much for your quick answer, I really appreciate it.

Charles Tsai said:

I'm not clear with some of your statements. You said cJTAG 4 pin method. First of all,  cJAG is a 2-pin method based on IEEE1149.7 as opposed to 4-pin JTAG (IEEE 1149.1). In cJTAG, the TMS, TDI and TDO are multiplexed. The TMS570LC4357 does not support cJTAG. It only supports the traditional JTAG including the nTRST. 

I selected this method, called cJTAG 4-pin standard mode in CCS (Which I think is the JTAG interface without the nTRST), and I could program the HDK board with this method (I only connected the TDI/TDO/TMS/TCK/GND/VREF pins).

Charles Tsai said:

If I understand you correctly, you are able use XDS200 to properly load a program to the MCU's flash on the EVM board, but not your custom board. Is that correct?

Exactly. Even with the 4-pins JTAG mode. We don't have access to the nTRST in this current version, it is simply pulled up.

Charles Tsai said:

You cannot fill memory at addresses starting at 0x0 because this is a flash memory. You need a flash programmer to load code to flash which occupies memory addresses starting at 0x0. You can only do memory fill on a SRAM. The SRAM starts at 0x08000000, not 0x0. 

I thought I would have been able to do that directly from the debug mode, thank you for the explanation.

Charles Tsai said:

Again, please confirm if you can successfully load a simple program to the EVM board, either the HDK or the LaunchPad board using XDS200. If you can successfully load a program to the EVM board then it means your target configuration should be correct. The only difference is the PCB.

I confirm that I am able to program the HDK with the 4-pin mode.

Charles Tsai said:

- Change the TCLK speed to lower value. Will that make a difference?

We already tried, and it sadly does not make a difference. The same errors are appearing.

Charles Tsai said:

compare your custom board schematic and the EVM schematic and can you find any subtle differences?

We could not find any difference yet, but since we are able to go in debug mode and read the registers, but only the program loading part is not working, would you have some idea of which part might be wrong ?

Here is some logs of the "Test Connection" routine in debug mode, and the view from the debug session:

[Start: Texas Instruments XDS2xx USB Debug Probe]

Execute the command:

%ccs_base%/common/uscif/dbgjtag -f %boarddatafile% -rv -o -S integrity

[Result]


-----[Print the board config pathname(s)]------------------------------------

********************************

-----[Print the reset-command software log-file]-----------------------------

This utility has selected a 560/2xx-class product.
This utility will load the program 'xds2xxu.out'.
The library build date was 'Jan 31 2021'.
The library build time was '19:18:41'.
The library package version is '9.3.0.00042'.
The library component version is '35.35.0.0'.
The controller does not use a programmable FPGA.
The controller has a version number of '13' (0x0000000d).
The controller has an insertion length of '0' (0x00000000).
This utility will attempt to reset the controller.
This utility has successfully reset the controller.

-----[Print the reset-command hardware log-file]-----------------------------

This emulator does not create a reset log-file.

-----[Perform the Integrity scan-test on the JTAG IR]------------------------

This test will use blocks of 64 32-bit words.
This test will be applied just once.

Do a test using 0xFFFFFFFF.
Scan tests: 1, skipped: 0, failed: 0
Do a test using 0x00000000.
Scan tests: 2, skipped: 0, failed: 0
Do a test using 0xFE03E0E2.
Scan tests: 3, skipped: 0, failed: 0
Do a test using 0x01FC1F1D.
Scan tests: 4, skipped: 0, failed: 0
Do a test using 0x5533CCAA.
Scan tests: 5, skipped: 0, failed: 0
Do a test using 0xAACC3355.
Scan tests: 6, skipped: 0, failed: 0
All of the values were scanned correctly.

The JTAG IR Integrity scan-test has succeeded.

-----[Perform the Integrity scan-test on the JTAG DR]------------------------

This test will use blocks of 64 32-bit words.
This test will be applied just once.

Do a test using 0xFFFFFFFF.
Scan tests: 1, skipped: 0, failed: 0
Do a test using 0x00000000.
Scan tests: 2, skipped: 0, failed: 0
Do a test using 0xFE03E0E2.
Scan tests: 3, skipped: 0, failed: 0
Do a test using 0x01FC1F1D.
Scan tests: 4, skipped: 0, failed: 0
Do a test using 0x5533CCAA.
Scan tests: 5, skipped: 0, failed: 0
Do a test using 0xAACC3355.
Scan tests: 6, skipped: 0, failed: 0
All of the values were scanned correctly.

The JTAG DR Integrity scan-test has succeeded.

[End: Texas Instruments XDS2xx USB Debug Probe]

Charles Tsai said:

Here is a link that provides guidance on JTAG troubleshooting. Search for the error code -1170 and -242 as reported in your console log. 

https://software-dl.ti.com/ccs/esd/documents/ccs_debugging_jtag_connectivity_issues.html

I will try to boot on the internal clock and see if it make any difference, as specified in your link for the error -1170 (A procedure to try and unlock a Hercules device is described in this e2e forum thread.) .

Thank you very much for your support

Good news, I was able to flash the memory after creating a short circuit between OSCIN and OSCOUT and pressing nPORRST. However, as soon as the chip is resetting, it does not work anymore. We are using a 16MHz oscillator, and the recommended capacitors. The kelvin ground is connect as it is on the schematics of the HDK board.

Would you have any idea of where it could come from ?

Thank you very much

Hi,

  I don't have the XDS200 with me. I only have the on-board XDS110 on the LaunchPad but the idea is going to be the same. 

  1. After you launch the target configuration. Right click on the Texas Instrument XDS110 Debug Probe_0/.... In your case, it should show XDS200. Right click on it. 

  2. Select "Show all cores".

  3. Expand the "Non Debuggable Devices" and you should see something similar to below. 

  4. Right click on the first one that says "IcePick" and then select "Connect Target". This is to manually connect to the IcePick. I believe this step will work for you since you have verified with the "Test Connection" and there is no issue with the JTAG.

  5. If the above step works, manually right-click on the "Dap". Can you connect to the Dap. If you cannot connect to the Dap then there is an issue with the Dap controller. You will need to answer me one question.

  A. Have you successfully programmed any code to the custom board before but just failed recently. Or you were never able program any code at all?

 If you were able program at one point of time and failed just recently then do you remember what code were programmed before that might have prevented connection to the target. 

 If you were never able to program at all, then I will suggest you try another new chip. Will that work? Or do you have another custom that you can try?

Johan Bertrand said:

Good news, I was able to flash the memory after creating a short circuit between OSCIN and OSCOUT and pressing nPORRST. However, as soon as the chip is resetting, it does not work anymore. We are using a 16MHz oscillator, and the recommended capacitors. The kelvin ground is connect as it is on the schematics of the HDK board.

Looks like our posts crossed each other. Please read my prior replies.

Hi,

Charles Tsai said:

5. If the above step works, manually right-click on the "Dap". Can you connect to the Dap. If you cannot connect to the Dap then there is an issue with the Dap controller. You will need to answer me one question.

It is indeed failing at this stage if I am not doing the "short circuit oscillator" approach. We I am doing this approach, I can then connect on the DAP.

Charles Tsai said:

 If you were able program at one point of time and failed just recently then do you remember what code were programmed before that might have prevented connection to the target. 

 If you were never able to program at all, then I will suggest you try another new chip. Will that work? Or do you have another custom that you can try?

I never successfully programmed the board before the previous message, and I also tried on some other boards that we have, and there is exactly the same issue. (I would then strongly think that it is a hardware problem).

Thank you

Hi,

  - Can you probe the OSCIN/OSCOUT between the HDK and your board? What difference do you see between the two? 

  - In your target configuration, can you try the JTAG instead of cJTAG mode? 

  - I guess the difference between your custom board and the HDK is the nTRST. I don't know if this difference is enough to cause the problem. Can you probe the nTRST pin input and compare the difference between the HDK and your board? Can you let the debug probe drive the nTRST? Does it make a difference?

Hi,

Charles Tsai said:

Can you probe the OSCIN/OSCOUT between the HDK and your board? What difference do you see between the two? 

Both oscillator, HDK and custom board, are oscillating at 16MHz, with a 2V amplitude, so I don't see any difference here.

Charles Tsai said:

In your target configuration, can you try the JTAG instead of cJTAG mode? 

It does not change anything, the error is still the same

Charles Tsai said:

I guess the difference between your custom board and the HDK is the nTRST. I don't know if this difference is enough to cause the problem. Can you probe the nTRST pin input and compare the difference between the HDK and your board? Can you let the debug probe drive the nTRST? Does it make a difference?

I disconnected the nTRST pin from the HDK board, and I can connect, load a program, and debug it correctly, so I would expect that the configuration is the same on both boards now concerning the nTRST pin. I even forced it to high state on theHDK, and I don't have any problem.

Hi,

  I really don't know what is wrong now.

  - Earlier you said you tried to lower the TCK frequency? How low did you try? Can you try like 500kHz?

  - Can you double check all the supply pins? There is this post that shows the VCCP pin is incorrectly connect to 1.2V instead of 3.3V resulting in failure to connect. https://e2e.ti.com/support/microcontrollers/hercules-safety-microcontrollers-group/hercules/f/hercules-safety-microcontrollers-forum/582211/ccs-rm48l540-error-241---jtag---device-locked. Please double check all power supply pins, not just the VCCP. 

  - Is it possible to swap the MCU on the HDK with your custom board. I understand this step may be more difficult to do. 

Hi,

Charles Tsai said:

Earlier you said you tried to lower the TCK frequency? How low did you try? Can you try like 500kHz?

I tried to lower the frequency, I tried 10MHz, 1MHz, 50kHz, and none of them worked.

Charles Tsai said:

Can you double check all the supply pins? There is this post that shows the VCCP pin is incorrectly connect to 1.2V instead of 3.3V resulting in failure to connect. https://e2e.ti.com/support/microcontrollers/hercules-safety-microcontrollers-group/hercules/f/hercules-safety-microcontrollers-forum/582211/ccs-rm48l540-error-241---jtag---device-locked. Please double check all power supply pins, not just the VCCP. 

I just double checked, and VCCP is connected to 3.3V, VCC_IO to 3.3V, VCCPLL to 1.2V and VCC_CORE to 1.2V (I think it is right, correct me if I'm wrong).

Charles Tsai said:

Is it possible to swap the MCU on the HDK with your custom board. I understand this step may be more difficult to do. 

Since the error is happening on several chips (on our custom boards), I would think that the problem is coming from our side, but we don't see where the error is coming from yet. We would love to avoid swapping the chips from our custom board to the HDK if possible.

We'll keep going with debugging, and let you know if we find the issue.

Thank you for the support !

Update from our side:

We are able to program the board as soon as we create a short-circuit between the OSCIN and OSCOUT pins. We now have a "blinking LED" program on the board, and we clearly see that it is going from 16MHz (oscillator clock) to the 10MHz (internal clock). Also, it seems like we are not able to setup the PLL. When setting up a clock multiplier, it does not seems to be taking into account (we don't see an increase in the LED blinking frequency).

Also, even if everything is setup on the oscillator (without the PLL) in the GCM menu on HALCoGen, I still can't load a program without doing the short-circuit on the clock. I found this thread, we'll try to change the capacitors and see how it goes. e2e.ti.com/.../tms570lc4357-pll-jtag-flash-programming-stability

I have a strong feeling that the problem is coming from the clock/PLL on the hardware side, however I can not find any rational explanation yet.

Hi Johan,

Johan Bertrand said:

I found this thread, we'll try to change the capacitors and see how it goes. e2e.ti.com/.../tms570lc4357-pll-jtag-flash-programming-stability

Thank you for finding this post. I didn't even find this post by myself. Please let me know if the capacitor is indeed the cause of the issue. In the meantime, do you mind to share the external load capacitance on OSC0 and OSC1 and how do they compare to HDK?

Hi,

We just have capacitors of 10pF in our initial design, and we just tried with 20pF, it does not change anything, we still have the same issues.

We just saw on the schematics of the HDK that there was two VCCPLL pins, including J14, which is not referenced inside the datasheet to be a VCCPLL pin. Does it need to be connected through the same capacitor like P11?

HI,

  I don't think it needs to connect like P11 but should connect to the VCC 1.2V supply like other VCC pins. 

Hi,
In order to investigate about our custom board, we created a very small board with just the essential parts, but we can not connect on the JTAG at all now:

-----[Print the reset-command software log-file]-----------------------------

This utility has selected a 560/2xx-class product.
This utility will load the program 'xds2xxu.out'.
The library build date was 'Jan 31 2021'.
The library build time was '19:18:41'.
The library package version is '9.3.0.00042'.
The library component version is '35.35.0.0'.
The controller does not use a programmable FPGA.
The controller has a version number of '13' (0x0000000d).
The controller has an insertion length of '0' (0x00000000).
This utility will attempt to reset the controller.
This utility has successfully reset the controller.

-----[Print the reset-command hardware log-file]-----------------------------

This emulator does not create a reset log-file.

-----[An error has occurred and this utility has aborted]--------------------

This error is generated by TI's USCIF driver or utilities.

The value is '-233' (0xffffff17).
The title is 'SC_ERR_PATH_BROKEN'.

The explanation is:
The JTAG IR and DR scan-paths cannot circulate bits, they may be broken.
An attempt to scan the JTAG scan-path has failed.
The target's JTAG scan-path appears to be broken
with a stuck-at-ones or stuck-at-zero fault.

[End: Texas Instruments XDS2xx USB Debug Probe]

Here are the schematics:


The jumper on nPORRST_H is set, the J14 jumper is connected. We have a current consumption of 10mA on the 1.2V and 48mA on the 3.3V.

The oscillator is oscillating at 16MHz, and the nERROR pin is a high state. It seems like the TDO pin is not giving any output.

Would you have any idea ?

Thank you for the support !

Hi Johan,

  Per your scan-chain test, it seems like the scan chain is somehow broken. Looking at your JTAG header, it doesn't seem to be a header that I have seen before. What is this? Please refer to the jtag connectors at this link for detail http://software-dl.ti.com/ccs/esd/documents/xdsdebugprobes/emu_jtag_connectors.html. Also please look at JTAG troubleshooting at this link. https://software-dl.ti.com/ccs/esd/documents/ccs_debugging_jtag_connectivity_issues.html

  Please make sure it is not a connector issue. Also probe the TCK, TMS, TDI and make sure you are indeed driving these signals to the MCU and probe the TDO pin to see of any signal activities. 

Hi,

It is the extended version of the 10 pin ARM connector (used by STM also).


As you can see, the middle part of the connector is the same as the 10 pin adaptor that is provided with the XDS200 programmer.

We checked TDO/TMS/TCK, the signals are looking good.

Would you have some other ideas ?

Thank you

HI,

  Ok. Personally, I have not seen a connector like this. But I suppose it worked on your earlier board albeit partially working with OSCIN/OSCOUT shorted per your early response. 

  - What is the state of nTRST? Can you pullup to high?

  - What is the state of TEST? Is it low?

  - What do you see on TDO? Is it flat line or some signals?

  - Do you have the MCU soldered properly? Please check if any loose connections. 

  - Do you have another spare MCU(will be good to pick a known good part) that you can swap in to the board and does it show the same issue? I want to make sure it is not an isolated MCU issue. 

Hi,

Yes indeed, it is exactly the same connector on both board, so it should not be the problem.

- nTRST is high, and pulled up to high (3.28V).

- The TEST pin is low (0.047mV)
- The line on TDO is going to 1 and 0 at different stages, so it's definitely not flat (same for TMS). Only TDI is completely flat
- How can we check loose connections under the BGA uC ?
- We manufactured two boards, and both have the same issue, so it is unlikely that two processors have the same issue, I hope.

Thanks for the support, I hope we can find the issue soon

TDI is driven by the debug probe is an input to the JTAG interface. If the debug probe is not driving TDI correctly to MCU then it may explain the problem. What debug probe do you have? Do you have another debug probe to try?

Hi,

We doubled check everything, and we figured out that we had an issue with the routing of the nTRST pin, and that our voltage and current limit in the power supply was too low on the 1.2V line, because of losses in the wires.

We are now able to program properly the small test boards that we manufactured, so we hope that we can make our custom board work properly, since we have the same schematics for both.

So far, we are stuck at a point were the PLL is not working on the custom board, and we have no idea of the issue. The quartz is connected the same way as it is on the test board, but there is no increase in current consumption, and the board is running on the oscillator instead of the PLL (16MHz instead of 300MHz). Again the same program on the test board and on the development board works fine.

If you have any idea, please feel free to share :)

I will keep you updated on the results

Hi,

After doing some more measurements, we figured out that the TMS570LC4357 on our custom board is pulling the nRST to 1.128V, where it does not happen on the test board.

Would you have any idea of the reason of that ? Could it explain the fact that the PLL is not working ?

We'll keep going on the investigation, and keep you updated.

Thank you.

Johan Bertrand said:

We are now able to program properly the small test boards that we manufactured, so we hope that we can make our custom board work properly, since we have the same schematics for both.

Glad that your resolve the test board issue. 

Johan Bertrand said:

After doing some more measurements, we figured out that the TMS570LC4357 on our custom board is pulling the nRST to 1.128V, where it does not happen on the test board.

Would you have any idea of the reason of that ? Could it explain the fact that the PLL is not working ?

Do you have pullup to 3.3V on the nRST? Your nRST looks like floating to me. Can you show the schematic for the nRST? nRST is a bidirectional signal. if there is any reset events within the MCU, the nRST will be driven low. But it can also be driven externally. If you don't have a pullup to 3.3V then it can be floating although there is an internal weak pullup on the pin. If you can still connect to the target, can you read out the SYSESR register?

Hi Johan,

  Hope you make some progress. Just wanted to give you a heads up that I will be on vacation until next week and will not be able to respond forum questions.