• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 32 subscribers
  • Views 237 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

MSPM0C1104: Clock shifting by 100x unexpectedly

Seth Kazarians
Prodigy 80 points

Part Number: MSPM0C1104

I'm using an MSPM0C1104 MCU in the 20 pin QFN package.  I'm having it blink a few LEDs in sequence and then make some ADC measurements.

I've had a couple situations where the MCU will look like it locks up.  I say look like because it seems to have it's internal clock slow down by about 100x.  I'm gauging this based on the LED pulsing with an on-time of 20ms (verified with oscope), which then turned into roughly 2 seconds (also verified on oscope, but as it's rolling mode, is harder to get an accurate measurement).

Unfortunately, it happens unexpectedly and seemingly randomly.  It seems to be associated with me touching the PCB, which suggests an ESD event.  However, I would expect a latch up or reset to be the result, and not a main clock shift. 

Has this been observed in this series?

Are there registers I should be checking the next time this happens?  (This assumes that I'll be able to debug it using an SWD debugger)

  • 0
    TI__Mastermind 30085 points

    Hey Seth,

    Is this a TI board or a custom board?   

    Based on your initial description, I can't think of any MSPM0C1104 pin currently that you could touch that would cause the clock speed to change...  If it happens semi regularly/consistently then it probably isn't ESD, do you have a pull-up on the reset pin?  

    When the MSPM0 goes into sleep modes like Stop or Standby, the timer clock could switch from 24MHz sysosc to 32kHz LFOSC.  But I don't expect going to sleep modes to be randomly.  Do you have some GPIO interrupts that your touch could be triggering?  

    Good luck!

    JD

  • 0 in reply to JD Crutchfield
    Prodigy 80 points

    Hi JD,

    This is a custom board. It's the SRUK package chip, with all 20 pins broken out to 0.1" headers (aka easy targets for stray, charged fingers).  The rest of the board is an LDO, a couple LEDs, an op-amp, and a FET to drive a load. It has 1uF on the VDD rail, so there is some bypass capacitance. It's not an ideal layout (I can't share why due to NDA limitations), but speaking from experience, that shouldn't cause this sort of behavior. 

    So, it's hard to say that it's happening semi-regularly.  I've had it happen within minutes, then I've also left it for over a weekend, and it's been running just fine. 

    The ~NRST signal has a 470k pull up and a 10nF filtering cap.  I'll have to dig it up, but I believe this is the recommended values for it. 

    I don't have any code that puts it to stop or sleep.  It's a while(1) loop that should ideally never exit.  

    I'll check the GPIO interrupts to see if that might be happening.  Pure conjecture, aka grasping at straws: maybe the interrupt location it jumps to has some garbage leftover that changes the clock or puts it to stop/sleep?  

    Thanks for the response!

  • 0 in reply to Seth Kazarians
    Guru 102575 points

    My first guess (from the symptom) is some sort of interrupt storm -- either the code doesn't consistently clear the NVIC or the interrupt trigger keeps recurring. In this case, if you pause the program in the debugger it is (with high probability) in the relevant ISR.

    Something to consider anyway.

  • 0 in reply to Bruce McKenney
    TI__Mastermind 30085 points

    Hey Seth,

    Here is the MSPM0Cxx Hardware Development guide that helps concentrate any info that could be useful for hardware/board layout.  Here is the typical application circuit.  I would recommend lowering the nRST to 47k and adding more VDD capacitance.   With a 470k pull-up on nRST, I'm still considering that the device is actually being reset.   

    Thanks,

    JD

  • 0 in reply to JD Crutchfield
    Prodigy 80 points

    Hi JD,

    If it were being reset, wouldn't the device go back to it's original settings? As in, it being reset should just start the firmware over again, and (ideally) the initialization code should get everything set to the right settings.   Or am I missing something?

    Thanks,
    Seth

  • 0 in reply to Seth Kazarians
    TI__Mastermind 30085 points

    Hey Seth, 

    Yes, an external reset will cause the device to re-run the bootcode and start at the top of your application.

    Since you are seeing the LED slow down, do you think you'd be able to tell the difference between a reset and a slow clock? 

    As for Bruce's idea, do you have any interrupts initialized?    

    As I mentioned, I still don't see how touching any pin could slow the Sysosc/Busclk so something else is probably happening.  Code could be jumping somewhere un-intended.  Device could be resetting.  ect.  

    Thanks,

    JD