This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP430FR5994: Gets Stuck when trying to Retrieve External Fast Clock Signal

Part Number: MSP430FR5994

When Using the Debugger for MSP430FR5994IRGZR and running through the Programming, it seems to get stuck when try to get an External Fast Clock Signal. 

Tried Changing Crystal but didn't make a difference. 

After inspecting a bit further I removed the crystal and measured the voltage on the output of the micro (HFXOUT) I don’t know if this will affect the voltage measurement or not. But on the ones without the issue I found a voltage of 0.68V and the ones with the issue seemed to have an output voltage of 1.4V to 2.5V which I suppose could be overdriving the crystal and causing damage to it or causing it to not oscillate at all. But again removing the crystal all together could cause issues with the measurement I’m not sure. 

Another Issue is that it draws a lot of current and this can be as high as 100-120mA. When in normal operation it draws around 10mA. Whilst its like this it can't be programmed or read using a debugger? I don’t know if there is internal circuitry that can be damaged and cause this situation? Just to be clear this current draw is constant as soon as the processor is switched on.

Any Help you can provide on both these issues would be much appreciated. 

  • Hi,

    I am not sure whether I have understood all the details perfectly, but you certainly cannot assess the crystal oscillator functionality by disconnecting the crystal and measuring directly at the oscillator pins.

    Please check out this application report on crystal oscillators (it is addressing 32kHz, but the theory is in most important points and testing applicable to high frequency crystals as well).

    http://www.ti.com/lit/an/slaa322d/slaa322d.pdf

    Have you tested the operation of the device using a crystal oscillator clock system code example only from CCS and TI Resource Explorer? I'd recommend reducing the problem to the minimum to isolate the root cause.

    It also would be useful to understand your clock system initialization and settings, including the crystal data.

    Best regards

    Peter

    Peter

  • hello Peter, 

    i have read the application note and we will try safety factor tests to see how close we are to the limit. however we have produced these in the thousands and only had this problem with a small amount of them. so i don't think that it will be this issue. we have tried changing the crystal for working crystal that still didn't work, when we changed the chip however that made it work so it looks more like the issue is with the chip not the crystal. 

    i will try using the code so that it isolates the crystal and i can rule out all other possibilities.

    also do you have insight on the excessive current draw issue that we have been having to?

    thank you

  • Hello Peter, 

    Feedback from today i have done what you recommended in reducing the code to the bare minimum using the TI example code this was still stuck trying to get the crystal signal again when measuring using an oscilloscope the clock line seems to just pull high and stay there. I also set one up to use the bypass code and tried to feed an external clock signal into it but this didn't work either. 

    I'm still unsure of how to progress with the current draw issue?

    again any information or guidance would be much appreciated. 

    thank you

  • Hi Jamie,

    my apologies for the belated response on this. Many thanks for the additional information. Based on it, especially when changing the MSP430 device resolves the problem, this indicates, there is at least a difference between the MSP430 samples. The current values are too high to be able to justify them from some fall back functionality, switching to other oscillators being a backup clock source. Especially if you see also with see same values with the basic code, then it does not make sense.

    Of course we would need further investigations with the devices, but the indications are pointing to some kind of malfunction of the device, and to me it sounds like the devices have been damaged at the oscillator pins, e.g. by ESD.

    Best regards

    Peter

  • Hi Jamie,

    please let me know, whether you have been able to nail down the root cause. Many thanks in advance.

    Best regards

    Peter

  • Hello Peter, 

    I have been able to do more investigation on the device last week, when we measured from the HFXIN pin to analog ground we found a short on the micro itself. also with the current draw issue i found a short between the power rails and grounds. this is with the chip removed from the board so there is not a short on the board. 

    what confused me was that in some cases the power rails and grounds were shorted inside the chip which could be a ESD issue, but for the HFXIN and analog grounds to be shorted just sounded a bit odd. 

    i have got in touch with the sales rep for us and hopefully i will be able to get some samples sent out to you for further investigation. 

    thank you

  • Hi Jamie,

    many thanks for the update. The results indicate my suspicion, that something is damaged for whatever reason with the failing devices. In terms of shipments of affected devices for investigations, please let me know whether you have the right contacts and information. There is a quality procedure including advises on communication paths, documents for start of the quality process etc.

    Please let me know, whether you need support on this.

    Best regards

    Peter

  • Hi Jamie,

    if I understood it right, we're now handling this case offline. Thus I am closing this thread for now.

    Best regards

  • hello Peter, 

    yes that is correct. 

    thank you for your help

**Attention** This is a public forum