• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 78 subscribers
  • Views 343 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CCS/MSP430F2012: Flash fails after setting MCLK to ACLK

FranzS
Prodigy 30 points
Part Number: MSP430F2012
Other Parts Discussed in Thread: UNIFLASH

Tool/software: Code Composer Studio

Hi,

while trying to reduce the power consumption of my MSP430F2012 microcontroller, I tried to use the 32kHz ACLK clock as system clock (MCLK). After flashing the corresponding code to the device, I cannot access it anymore. This includes flash operations with Code Composer Studio as well as with the UniFlash tool (this tool cannot even automatically detect the connected device).

Some detailed information:

  • I'm using the MSP-EXP430G2 launchpad with the 32kHz crystal soldered on it, Windows 10 (all updates installed), Code Composer Studio 9.1.0.00010 and UniFlash 5.1.0.2397
  • I have bought 5 MSP430F2012 microcontrollers, 2 of them have the described problem. I have not flashed the code to the other 3, so I am able to test the connection with these devices. Therefore, I can say, that there is no problem at any other place, because the 3 "good" microcontrollers work as expected.
  • The code I used to modify the MCLK looks as follows:
    DCOCTL = 0;
BCSCTL1 = XT2OFF + DIVA_0;
BCSCTL2 = SELM_3 + DIVM_0;
volatile unsigned int i;
do {
    IFG1 &= ~OFIFG;
    for(i = 0; i < 1000; i++){} // wait at least 50us => 800 cycles for 16MHz => round up to 1000 cycles!
} while (IFG1 & OFIFG);
  • The code I'm trying to flash now is the standard blink example from TI

While flashing this example to the broken microcontrollers, following error is returned by the CCS:

This message is followed by the Information "Unable to connect  to the target".

I'm trying to solve this problem since several days, so I've already tried things that I found somewhere on this forum and somewhere else, but nothing worked until now. Things I've already tried:

  • Updating all used tools, drivers, software, etc.
  • Replacing available ressources like USB-Ports, Cables, microcontrollers, etc.
  • Using the cloud tools - failed due to the longer existing and already known problem with the cloud agent that is described in this thread.
  • Lowering the JTAG Clock speed (TCLK) as described here.

Can anyone help me to get back control over my microcontrollers?

Thank you in advance, best regards,
Franz

  • 0
    TI__Genius 17960 points

    Hello Franz,

    sorry to hear you're experiencing these issues. When looking at the your problem description and the data you have provided I see two major critical things.

    1. You're switching the MCLK and thus the CPU to the clock of LFXT1 before the OFIFG clearing loop, means before the stabilization of the respective clock source. You're even setting the MCLK divider to 1, this means the digital clock derived from the 32kHz crystal goes directly as is to the CPU. Here you need to keep in mind, the origin of this clock is an analog signal of the crystal oscillator, which is basically a sine wave of increasing amplitude from 0 to the settled level. This analog signal is then converted to digital, by basically a comparator function. This means on startup, from the state of no amplitude to sufficient amplitude and DC level, the sine wave will start moving through the comparator threshold, probably generating glitches at entry of the comparator threshold. These glitches can overclock the CPU even if the sine wave is as low as 32.768kHz, as it's not only the frequency of MCLK, but also the pulse length, which is critical in terms of overclocking. Thus the switching from DCO to 32kHz needs to happen either after settling of the 32kHz, means the instruction needs be placed after the OFIFG loop, or you need to set the MCLK divider to 1/2.

    2. On power up the WDT is active and set to Watchdog functionality. Means if it expires, it will reset the device. A reset will always break a JTAG synchronization. I am not seeing the stop instruction for the WDT in your code snippet, but even if it should be placed before the code, in some cases with C-programming the WDT expires during the C-startup code activities. Especially as you're slowing down the CPU code execution by switching to 32kHz instead of DCO, you slow down the code execution towards WDT expiry. This might be another reason for the observed behavior. The MSP would be looping in startup and reset during startup, not being able to synchronize with the IDE and other tools. In this case you need to insert the WDTHOLD into the C-startup code.

    These are two quite probable root causes for the observed behavior. We need to check on both, and take it from there, if it problem should persist.

    Best regards

    Peter

  • 0 in reply to Peter Spevak
    Prodigy 30 points

    Hello Peter,

    thank you for your fast and very detailed reply.

    The first problem regarding the stabilization of the clock source was definitely my fault, I haven't seen that. Of course, I've immediately changed it (including a MCLK divider of 2 - to be on the safe side).

    Regarding the stopping of the watchdog timer: this was already part of my code in the main function. I've only copied the code snippet of setting the MCLK, so that was omitted. I changed the watchdog stop to be done in the startup phase.

    After both modifications, I'm able to flash the new code to one of the "good" microcontrollers and keep control over it, meaning that I can flash another program to it afterwards. To sum up, I can say that your advises seem to solve the source of the problem. Thank you for that!

    The problem of lost control over the microcontrollers with the failing code still remains. Do you have an Idea how to solve that with the gained knowledge?

    Best regards,
    Fanz

  • 0 in reply to FranzS
    TI__Genius 17960 points

    Hello Franz,

    many thanks, glad to hear that.

    If it would not be the MSP430F2012, like also applicable for other F20xx, we could try erasing the device by using the BSL. Unfortunately these derivatives are the ones of the very few MSPs without the BSL.

    The basic problem is with both root causes the device reset, or in the overclocking case an unintentional run into LPM4, switching all clocks off before JTAG synchronization, and thus running into the observed problem with tools.

    All the tools are applying a HW reset on the RST pin of the MSP430, and then trying to synchronize with its JTAG, or Spy-Bi-Wire, which is basically just another use of the JTAG logic. Now if, like in your case the device generates after the reset from tools during or even shortly after an internal reset, or switches all clocks off before synchronization, the tools are not able to establish access to the device. A part of the problem here is the extremely fast startup of the MSP430 after reset.

    Means gaining access to the devices you've programmed with the critical code might be impossible. If it would be the overclocking, you could try to solve it by feeding in a digital clock divided down by an external resistive divider to limit the amplitude, but avoid glitches from the oscillator startup.

    But my suspicion is, it is the WDT expiry, if not only, than in combination with overclocking. I am afraid the effort to address this is by far bigger than removing the device from a PCB. Basically the only chance you have is breaking the timing between device reset executed by the tools and the JTAG synchronization. This could only be done by disconnecting the RST line from tools to the MSP430, and try to apply a delayed RST from another source, means shrinking the time between RST at MSP430 and synchronization activities on JTAG. Still potentially the time window might be so small, that you'll never hit it. Thus as stated, probably it is easier to remove the "broken" device from PCB and replace them by new ones. Sorry for that.

    Best regards

    Peter

  • 0 in reply to Peter Spevak
    TI__Genius 17960 points

    Hello Franz,

    actually after giving it another thought, there might be a slight possibility even in the WDT case. Basically the WDT expires due to slow CPU clock. Thus if you apply a higher frequency digital clock to Xin, you could be able preventing the WDT expiry. The open question is, which I cannot answer, whether you'll be able getting that clock through, as you need to get that through the 32kHz crystal oscillator, which's bandwidth is very limited.

    Best regards

    Peter

  • 0 in reply to Peter Spevak
    Prodigy 30 points

    Hello Peter,

    the BSL thing is exactly of that type I was counting on... Bad luck...

    I would like to thank you a lot for your efforts on solving my problems! The suggested methods seem to be a lot of effort and I only have limited time, so maybe I'll try that later. At the moment, it is absolutely fine for me if I can use the slow CPU clock without loosing control of the microcontroller. I only need one of the MSPs, so 2 lost ones are not a real problem. (I bought them exactly for such a case)

    I will mark your first answer as the solution. If I can solve the problem with the lost devices later, I will add that to this thread.

    Best regards and many thanks,
    Franz

**Attention** This is a public forum