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.

MSP430 sometimes does not start up.

Other Parts Discussed in Thread: MSP430F235

Hi,

I have a strange problem. After testing 20 prototypes of a product without problems, a pilot run started. Some of these products fail to start up about 3 times out of 10.

The controller is a MSP430F235 running on the DCO clock together with an TSP79733 as LDO/startup circuit. The LDO has several 100nF on the input and 100nF parallel with 1µF on the output. All ceramic caps.  When i add an 10µF electrolytic cap over the output the MSP doen not even start at all. 

Any idea what can be wrong? Can it be a hardware problem?

Regards,

Johan

  • Did you change the DCO frequency? The frequency is dependent of the voltage applied on the MSP, so if the voltage is not sufficiently high this will cause problem to start the DCO. Adding some uF on the output of the LDO will longer the power-on ramp (time to charge the capacitor), so when you change the frequency, it is not the voltage expected. Try adding a waiting loop during power on to be sure the power is ok.
  • The first thing the MSP does (after setting up al I/O ports) is changing the DCO frequency. So i'm almost sure you're right, that must be the reason.

    I've had this problem before with another design when using an external Xtall, and solved this by a waiting loop, as you proposed. Because here there is no external xtall and i did not expect the to have the same problem with the DCO, the waiting loop was removed. Stupid...

    I've not been able to test this, because i need to reprogram the MSP with the BSL and i do not yet have the right tools for this. So i have to wait for a few hours, but i'm quite sure your solution is the correct one.

    ( This is what happens if hardware designers make software ;-) )

    Thanks,

    Johan

  • Hello,

    In the meanwhile we have made some batches with the corrected code (so with the waiting loop), and the problem seemed to be solved completely.

    But now we suddenly have 10pcs that never start up. These 10 MCU's seem to crash at the moment their DCO-range is modified. Code of the DCO setup:

    BCSCTL1 |= RSEL3+RSEL2+RSEL1+RSEL0; 
    DCOCTL   = DCO0+DCO1+DCO2;                     
    DCOCTL  |= MOD4+MOD3+MOD1;                  
    BCSCTL2 &= ~SELS;                    
    BCSCTL1 |= DIVA_1;                     
    BCSCTL2 |= DIVS_1;                     
    BCSCTL2 &= ~DIVM1+DIVM0;     

    So when the first line is removed, the software works fine (but with the wrong clockfrequency).  Increasing the waiting loop does not help at all.

    Any ideas why this happens? Should i poll for a "DCO - OK" flag, or so???

    EDIT: When i put a waiting loop after the first line, the MCU works fine again... But this is not the best solution i suppose...

    Thanks and regards,

    Johan

  • I have figured out what is going wrong... In the original code, the DCO modulation was enabled first, and afterwards the DCO range was set. When the order of these two lines is changed, the problem is solved.

    Only 10 parts had this problem, and they never start up. All other parts have been tested intensively and not even 1 failed. Strange...

    Anybody an idea why the DCO range cannot be set with the modulation switched on?

    Regards,

    Johan

  • Johan Bleumers said:
    Anybody an idea why the DCO range cannot be set with the modulation switched on?

    Oh, it can.

    Mopdulation, however, switches the DCO to the next higher DCO tap and back. The next higher might be out of operating range with the default tap settings.

    It's recommended to set the MCLK to DCODIV (or divide it with the MCLK divider) before swtiching any DCO parameters, especially if switching RSEL, as the DCO might temporarily overshoot. Once all registers are set, teh divider can be removed.

    Sicne teh effective frequency with default DCO settings has a large variation, maybe these 10 devices are jsut at the edge while the others aren't. Once teh calbrated values are set for all registers, all is fine, but before, the wrong setting order may temporarily cause a much too high DCO frequency. Once clock cycle might be enough for the FLASH to throw out a wrong next opcode and the system crashes immediately.

     

  • Thanks for the clarifying explanation.

    Regards,

    Johan

**Attention** This is a public forum