• State Answer Suggested
  • Locked Locked
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 32 subscribers
  • Views 1271 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.

MCU cannot run at 120MHz

Tianlei Zhang
Expert 1320 points


Hi,

We are using TM4C129 / EKCPDT13 / 55A379W for our product. Recently we just had a new hardware revision which involves MCU position translation and rotation, but this new revision does not work. Our previous revision works well. The reason we made this revision is trying to eliminate noise on the analog circuit. 

The firmware configures the MCU to run at 120MHz. There is no problem on the old revision board. On the new revision board, it does not work. The device will repeatedly trigger watchdog reset (the watchdog is turned on in the firmware). By debugging the firmware, it was discovered that hardware fault will be triggered when letting the firmware run free.  Later I discovered that if I change the firmware to let the MCU run at 80MHz, the hardware fault will not be triggered and firmware will run normally (however we need the MCU to run at 120MHz for proper device function).

The simple reasoning on this is that the new revision has layout problem, my question is: could this be a power problem or the MCU is not getting proper d-cap? or any other reason that I am not aware of? anybody has experience on this?

  • 0
    TI__Guru**** 244440 points
    Hello Tianlei

    Can you please share the layout of the Micro and the schematic for Micro so that we can check if the power grid issue?

    Also what type of Hardware Fault is triggered?
  • 0 in reply to Amit Ashara
    Guru 47900 points
    Hi Amit,

    And - is it not wise to, "Eliminate Single Board Anomaly" before greater time/effort is expended?

    Poster should build several boards - very carefully inspect each - and determine if the fault is "board specific."

    A good test which my firm (often) employs is to run a, "Known Good" short program - which targets one MCU peripheral at a time. The intent here is to determine if the "slow down" is Software or Hardware (or both) caused.

    Tightening poster's focus surely trumps (run everything) in finding the issue's source quickly & efficiently...
  • 0 in reply to cb1
    TI__Guru**** 244440 points
    Hello cb1

    Yes. It could be. But sometimes the board design may itself lend a clue.
  • 0
    Expert 1320 points
    Hi Amit and cb1,
    Thanks for response. I have got to the root of the issue. The dcaps for VDDC pins need to be very close to the chip. Our board layout is not good. I guess if these dcaps are not close, when MCU is running at high speed, the noise becomes too strong for the chip to stand. I put an additional 0.1u dcap right at the pin and the problem was solved.
  • 0 in reply to Tianlei Zhang
    TI__Guru**** 244440 points
    Hello Tianlei,

    Glad to hear that. We would have also looked at the same and referred the System Design Guidelines.
  • 0 in reply to Tianlei Zhang
    Guru 47900 points
    While we're glad to hear that - it still makes sense to confirm this "fix" over a larger sampling of your new boards. It may even be that (some) MCUs have this sensitivity - and others do not.

    In general - as System Clocks climb in speed - it is important to employ good, High Frequency Techniques. Recall that 120MHz is w/in the VHF Radio/TV band.
  • 0 in reply to cb1
    TI__Guru**** 244440 points
    Hello cb1

    With a good layout and following the System Design Guidelines we have seen this issue getting resolved over multiple devices.
  • 0 in reply to Amit Ashara
    Guru 47900 points

    Hi Amit,

    While I've no doubt in your having seen this issue getting resolved - that does not (fully) speak to poster's issue & desire.

    His "Charging ahead" after a "Single Board Fix" (maybe)... is unwise.
    Other issues may lurk - and a, "Rush to claim Fixed" when adequate test/verification has NOT been performed - may just delay his discovery of those items - less easily noted - which cannot be good!

    A serious read/review & then FULL Compliance w/the Design Guide you've listed (really) should be followed...

    Full/Proper testing of a 120MHz MCU-based board is neither simple nor fast.   The fact that a (few) functions & peripherals "appear to work" is little insurance that the board is executing to its full potential - and will continue to do so - long into the future...

  • 0 in reply to cb1
    TI__Guru**** 244440 points
    Hello cb1

    Agreed. I have stuck my designs to the Design Guide and over multiple devices and boards it has been useful to see that 120Mhz operation with a lot of peripherals active, the device works as expected.
  • 0 in reply to Amit Ashara
    Expert 1320 points

    Hello cb1,

    I did the same modification on 3 of my boards and they all started working.

    I think it may be useful to post some details so that other readers won't run into this:

    When the board did not work:

    1. the JTAG port does not work reliably. With a JTAG programmer, the 'blank check' yield inconsistent result. Sometimes it passes, but a lot of time it reports different locations of non-blank memory.

    2. 'erase' operation most of the time can go through, but combined with inconsistent 'blank check', it makes you believe the chip is damaged.

    3. The above behavior is for the blank chip. Once you managed to burn your firmware into the chip (running at 120MHz), the JTAG immediately becomes in-responsive. This makes you wonder if your firmware is a chip killer or it has disabled the JTAG port, which force you to perform the unlock sequence to try to rescue the chip.

    4. once the chip is erased, it goes back to the state described in 1 and 2.

    5. during the struggle, you may start to have a few really damaged chips caused by careless handling. This will even complicate the situation.

    6. I have a chip damaged even with very careful handling. I doubt it is caused by the spikes on VDDC that is not sufficiently filtered. (I cannot confirm this).