• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 78 subscribers
  • Views 1069 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.

MSP430F5527 jumping to random addresses and freezing

Alex Long
Prodigy 40 points
Other Parts Discussed in Thread: MSP430F5527

Background:
I have developed a control board for a large, intelligent air conditioning system. Last year, I had 4 control boards manufactured by MyroPCB, and everything came out fine. I just received 12 more of the boards, and am seeing this issue on 6 of the 12 (that is, 6 of the new boards work perfectly fine, just like the original 4).
The board uses a MSP430F5527 microcontroller.

The Problem:
on half of the boards, I load in the program (done with a FET430-UIF), and in less than a minute, the microcontroller stops operating normally. When I halt the debugger (I'm using Code Composer Studio), it shows an error like "No source available for 0x40000" (the address is never really the same, I've seen it at 0xFFFFE, 0x4, etc.), even though this should never be an area that the microcontroller should be in. My program is around 40kB, so it's still well within the lower flash section. The stack size is plenty big, there's more than enough ram, but for some reason the microcontroller is jumping to a random part of the code. The voltage to the chip looks perfect right at 3.3v, and doesn't ever appear to drop. Again, on the other 6 new boards (and 4 old), this has never happened - the current one in the field has been operating nonstop since September of 2014.

The Question:
My real question is if this is a known issue. The markings on the microcontroller are "OCCE4ZTC4 M430F5527 Rev E". Could this somehow have been a bad batch of microcontrollers? Could something like this happen if the manufacturer was soldering at too high of a temperature or something? My debug configuration is set to Full Verification and the program appears to upload just fine without any errors.

  • 0
    TI__Guru 68116 points

    Hi Alex,

    On the F5xx, there are actually 2 voltages that are key for operation. First there is Vcc (which you already checked) but there is also Vcore which supplies the core voltage for the part. This would be the first place I would look for an issue like this, so here are some diagnostic questions:

    1. Can you confirm that the correct cap is on the Vcore pin on the board? It should be 470nF as per the datasheet. You probably would not only check your design, but check the failing board to make sure they put the right value of cap on at assembly.


    2. Can you try swapping a device from a failing board and a device from a good board (put the passing part on the failing board and the failing part on the passing board) - does the issue follow the device, or the board? (this should help tell you if there is an assembly issue on the board contributing to the problem)


    3. In your code, what frequency do you run MCLK at, and what Vcore level do you have set? This must meet the matrix in the datasheet (see figure 1 Maximum System Frequency, under Recommended Operating Conditions)


    4. For setting the Vcore level, do you use our Driver Library API, the 5xx core libraries, or something custom? Please note that the Vcore level can only be moved one setting at a time - I've seen issues very similar to yours when this rule was missed (see www.ti.com/.../slau208 section 2.2.4 about increasing Vcore) - there are a lot of complicated checks involved with stepping the core level so we recommend that you use the driver library PMM_setVcore() API because this is known good code with all bug fixes etc.

    Regards,
    Katie

  • 0 in reply to Katie Pier
    Prodigy 40 points
    Katie,

    Thank you so much, this appears to have fixed the problem I was seeing. I was operating at 12MHz, but had neglected to step up the vcore voltage from the default. Interesting how it only seemed to affect certain boards.
  • 0 in reply to Alex Long
    TI__Guru 68116 points
    Hi Alex,

    I'm so glad to hear that you fixed your issue!

    Concerning only some parts failing: this is typical of this kind of issue. Basically what's happening if you run the part at 12MHz without stepping up Vcore, is that you are running the part in an out of spec condition. A lot of times, some units may tolerate running out of spec better than others - we have to set our specifications in the datasheet in such a way as to make sure we can say that all units, across lots, device variation, operating conditions, etc will be able to run correctly with that setting. This means that if you go beyond it, some parts fail, but some may tolerate it to an extent, simply due to device variation - but we can't guarantee anything at that point because that's not what it was designed/tested to meet.

    Regards,
    Katie

**Attention** This is a public forum