TMS570LS1224: Clock not Starting (intermittently) RM4x , XL2-TMS57012 Launchpad, Runs at LPO HF

Hello FJ,

Do you see any additional indication of a problem such as the nERROR pin being asserted/LED ON? Have you put a scope on the crystal to see if it is, in fact, not working?

If you can confirm that the crystal is not working, can you work with your distributor or with direct TI customer service to arrange for a return and replacement? The other choice would be for your to replace the component yourself.

The problem is an intermittent one, occurring at power-up.  Multiple launchpads exhibit the issue, even in different locations.  Once it starts (based on limited observation) the only way to startup correctly seems to be removing the USB connection from the launchpad (and replacing the connection, re-launching code composer.)

We are at a point where any errors coming up from the HAL are not being monitored.  My suspicion is the safety library has detected something and bypassed restoration of a clock.

Once the problem occurs, will defiantly post the state of ERROR and the crystal's activity.

Hello FJ,

This is a problem we have not seen previously on these boards. Can you provide scope plots so we can see what is happening better?

Also, removing and restoring the USB connector is simply performing a new power up on the board so this would be expected to clear things up the the device were stuck in a fault mode. If this were during a debug session, it could also cause CCS to lose sync and maybe freeze up or have a fatal error.

Keep me posted if you can recreate the issue or if you get a feel for a way to robustly recreate the issue.

Chuck,
We have also experienced this issue on some recently purchased Hercules Launchpad TMS570LS12x dev kits. The code is generated by Halcogen (for the most part). We are using a BH-USB560_v2 connected to the JTAG header. The debug session will detach due to JTAG comm errors -180 and -181. The error LED continues to flicker. The PLL scopes between 15.9-16.1MHz (low signal amplitude calculation) on our Tektronix TDS 754C.

When it gets in this state, all subsequent (JTAG) connect attempts fail. So I can only speculate on what is happening here.

Thoughts?

Thanks!
Stephen

Stephen,

You said this is on recent LP development kits. Had you experienced similar issues before or only on recently purchased kits?

When you state that scope results show 15.9-16.1MHz with low signal amplitude, what pin are you measuring and what is expected? Is this the OSCIN side or directly at the crystal? Is there any indication on what clock rate the application is running at? i.e., has it reverted to HF LPO due to an OSC FAIL?

Chuck,
We only have new dev kits. This is a new target for us. I believe the PLL should run at 16MHz (faster than the 10MHz HF LPO if I'm not mistaken). I was scoping the crystal.

Thanks!
Stephen

Hi Stephen,

The system clock will fall back to the HF LPO on OSC Fail which will make the overall system operation much slower than expected. OSCIN on the Launchpads is derived from the 16MHz crystals. 15.9MHz to 16.1 MHz is a very wide a range for the crystals when the crystal accuracy is ususally measured in PPM. I also know that care must be taken when probing a crystal because of the impact of the probe capacitance on the oscillation. In fact, applying the probe can sometimes even cause the OSCFAIL mechanism to trigger which requires a hard reset or power cycle to clear.

Ideally, an active scope probe with very low input capacitance is preferred for crystal measurements because standard probe capacitance can have a significant impact on the crystal load.

Chuck,
Thanks for your prompt replies. It sounds like I need to probe the clock input next time this occurs. What is the recommended course of action if A) the OSCFAIL did trigger and B) if OSCFAIL did not trigger?

Regards,
Stephen

Hello Stephen,

If OSCFAIL triggers and the device goes to the failsafe mode (i.e., HF LPO sysyem clock) the only way to correct it is through a hard reset. When there is an OSCFAIL event, the ESM flag will be set and nERROR asserted. Going through a soft reset, the ESM information is reserved so you can check if this is the cause or not by review of the ESM registers. For offline debug. you could also use the clockout pin to output a clock divided down from the either PLL output or from OSCIN. When you you see that this clockout is significantly slower as a result of the issue it can be surmised if you are in the failsafe mode or not given the known prescaler to reverse calculate the clockout source. If it is the HF LPO (8-12MHZ but usually 10 MHZ) then it is a good bet this is the cause of the issue.

Also, as a side note, which version of CCS are you using? I am hearing of some issues with the 560v2 emulators with the latest versions of CCS. Not necessarily stating this is a cause but just want to be certain which version you are using so I can check with our CCS team.

Chuck,

We are using CCS 7.1.0.  It may be worth noting that we usually have to power cycle the device several to many times.  Although it may be coincidental, there has been a few times where I couldn't seem to get the thing to resume normal operation after power cycling until I unplugged the JTAG from the BH-USB-560v2 emulator.  It makes me wonder if there could be a race condition on the reset between the two JTAG interfaces that causes the thing to reset over and over.  Is this one of the issues you have seen with CCS 7.1.0? 

Thanks!

Stephen

I've not personally seen any issues or seen any specific details of any issues. The one issue that was I am aware of turned out to be a debig configuration error that the customer had made. I have only heard through comments here and there that some have been experiencing problems so take this for what its worth.

There shouldn't be any race conditions on reset since the emulator controls nTRST on the JTAG interface. It is, however, possible to program the device with code that utilize the bulk of the CPU bandwidth making it very difficult for the emulator to break into the CPU and halt it for establishing a debug session. If this happens, timing of the debug request becomes key.

Chuck,
In this failure scenario: the emulator fails to connect to the target (error 180 "The controller has detected a target power loss") and OSCIN (pin 18) reads 16MHz. I still read +- 0.1MHz. I can't say whether this is accurate, or error induced by the oscilloscope.

It seems to me the bigger issue is this suggests that whatever is happening on the launch pad will happen in-field, and is concerning at best. To date, it seems we have yet to fully understand this issue, and how to guarantee it wont happen in field.

Thoughts?

Regards,
Stephen

Steve,

I certainly understand your concerns, but until we understand what is causing the failure we can't determine if this is a board level issue or a device level issue. Also note that debug behavior of this nature doesn't necessarily reflect the behavior of a real application.

Measuring the clock at 16MHz is expected at OSCIN. The boards have 16MHz crystals on board. In your first post, you mentioned a warning from the scope about low amplitude on the clock signal which is what I was alluding to as a possible source of any OSCFAIL events. If an OSCFAIL event does occur it requires a hard reset to correct it and this is part of the normal use of the device. In fact, under several fault conditions, reset is the fail safe to correct potential transient errors or to validate HW failures.

Also note that the launchpad is a development board and is implemented in such a way to be cost effective (note the very inexpensive board.) This means there may be some design choices affecting this behavior that could be avoided in a normal application.