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.

MSP430G2452: USI operation with asynchronous clock

Part Number: MSP430G2452

Hello Team,

Posting on behalf of my Customer:

We are using the USI (as a timer resource, not SPI/I2C) on a MSP430G2452 and clocking from a source asynchronous(ACLK) to the CPU clock. Are there any known issues with the clock divider going into latch-up if the USIIFG signal and the input to the clock divider are asynchronous and happen to line up just perfect? We are getting a dead USI and can’t really trace it to much else. Any input you have would be appreciated.

 

(Refer to Figure 14-1 in Family Users Guide)  We are setting USIIFG in software to stop the clock (ACLK) and once in a blue moon (probably 1 in a billion) it takes a complete power-down to recover.

  • Hi Keith,

    This is an interesting use of the USI module but it should be possible. I'm not aware of any issues with the USI becoming locked when the USIIFG get's set. Are you sure the flag is getting reset before attempting to use the module again?

    Can you provide a reduced code version that reproduces the issue or is at least representative the customer's setup?

    Best regards,
    Caleb Overbay
  • Thanks Caleb, I'm the mystery customer Keith is talking about so I can hopefully shed some more light on this situation. I do have a reduced-code version that I've used to narrow down the problem - but it's still across multiple files and not exactly convenient for posting. But I don't think I need to do that anyway, I can explain.

    We've all been in the situation where after some design decisions / commitments have been made, we have to add just this one feature that is difficult to support given those decisions. And such is the case, I needed another timer resource in the 'G2452 but can't really upgrade the part. Running in LPM3 (no high-speed clocks) I want to source a timer from ACLK. Simple, you source TimerA from ACLK, set it up to interrupt on a heartbeat.

    Except TimerA is already used for something, I cannot use it for my low frequency clock.

    The USI has a bit counter in it that can count from any number from 0 to 31. And it has a very flexible divider before that. If you don't configure the output pins, you can just load the counter and divider with the appropriate values, source it from ACLK, and presto you have a whole another timer resource. It's great! And it usually works.

    Looking at the block diagram for the USI, you can see that the USIIFG disables the clock divider. The USI module does not automatically clear this flag, you must do it in software. That means, I might re-enable the clock just a picosecond before an ACLK edge. Does this cause a problem? I don't know, but I can tell you that once in several hundred million interrupts, it hopelessly stops and nothing I do in the code or with the USI registers seems to recover it. The WDT can't help - I literally have to hard power cycle to recover.

    So my hope was, I'm missing something easy, or there is a workaround to this but as you said it's probably unusual to source a serial port from ACLK so data could be limited.

    Let me know your thoughts. I appreciate the help.

    Thanks!

  • Hi Dan,

    Thanks for the extra information. If you're uncomfortable posting the code on the forum, you can send it to me via private message after requesting friendship on E2E. Since it's across multiple files, it's probably best to zip the whole project and send it to me.

    Right now I don't have many thoughts on what could be causing the issue. I'd need to dig around in the code a little more. I'm suspicious of the USIIFG and if it is actually getting reset. When you encounter the issue is the debugger attached? Can you view the USI registers and see if the interrupt flag has been cleared? Also can you toggle the flag a couple times and see if the module starts back up?

    Best regards,
    Caleb Overbay
  • Hi Dan,

    Were you able to solve this issue or find a workaround to your problem?

    Best regards,
    Caleb Overbay

**Attention** This is a public forum