• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 30 subscribers
  • Views 337 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.

MCF8329EVM: What does an "APP_RESET" fault actually indicate?

John Potts
Prodigy 30 points
Part Number: MCF8329EVM
Other Parts Discussed in Thread: MCF8329A,

Tool/software:

I've been developing an ESC using the MCF8329A gate driver, and am currently using the MCF8329EVM as a bridge between motor studio and my ESC (done by removing the jumpers on the SCL and SDA connections, and wiring the i2c lines on my ESC to the mcu-side pins). However, when I try to start spinning one of my potential target motors, it frequently stops almost immediately and motor studio shows an "APP_RESET" fault. To characterise "frequently": it may start just fine 10 times in a row, or it may throw a fault 5 times before it starts a single time. If I spin the same motor with the ESC circuitry built into the MCF8329EVM, it works with no issue.

I would like to know what sequence of events are actually known to lead to an app reset fault. Could it be the MCF8329A browning out? A loss of communication between the MCF8329A and the machine running motor studio? Some software issue with motor studio itself (unlikely, since it only seems to be failing when attached to my ESC)? A malformed i2c instruction causing the app to experience an error?

What I've tried:

  • Assuming it was possibly related to noise during the open loop portion of the cycle, I tried decreasing the open loop acceleration coefficients. Using the ESC built into the EVM, coefficients of a1=50 and a2=1000 work well. With the ESC I've been developing, I can get the motor spinning sometimes if I have a1 set to 25, 50, 75, or 100, and a2 set to 0 (with the highest rate of success at a1=25).
  • I was seeing some noise (about 200ns of 40MHz ripple every 20us or so) on the Vreg line of the gate driver, ie pin 2, so I added an additional 0.1uF decoupling cap in parallel with the 2.2uF decoupling cap I already had. The noise now appears to be an 80MHz ripple, and the ESC might be spinning the motor a little more consistently.
  • There's no appreciable noise visible on the input power rail (48V) when the app reset fault happens
  • I have a 3.3V regulator rather than running the MCF8329A off it's own Avdd rail, and while there's no visible noise on the input of the voltage regulator, the noise that's visible on pin 2 seems to be visible on the output of the voltage regulator.
  • I've confirmed that the noise on pin 2 is happening at the same amplitude and frequency whether or not the motor starts spinning properly, suggesting to me that it isn't related.
  • 0
    TI__Expert 6011 points

    Hi John,

    Thanks for reaching out. APP_RESET is usually caused when the DC supply dips below UVLO of the MCF8329A and the device resets. Since you are saying the DC rail is stable, I will have to investigate this issue further, please give me time till 24-Feb to get back to you.

    Regards,
    Sachin S

  • 0 in reply to Sachin S
    Prodigy 30 points

    Hello Sachin, thank you for looking into this. On page 13 of the datasheet, I see undervoltage thresholds for Vreg, Vdvdd, Vpvdd, Vgvdd, Vbst, and a "POR" threshold for Vavdd. Would any of these dipping below the listed thresholds for longer than the listed deglitch times cause APP_RESET?

  • 0 in reply to John Potts
    TI__Expert 6011 points

    Hello John,

    I am sure that PVDD undervoltage causes an APP_RESET. With respect to others, I am looking into the code of the GUI to figure it out.

    Thanks and regards,

    Sachin S

  • 0 in reply to Sachin S
    Prodigy 30 points

    Hello again Sachin. Any updates on this?

    Also, some added context: based on the MCF8329A datasheet, the normal implementation is to route AVDD_out (pin 26) to VREG (pin 2). AVDD_out is a 3.3V rail created inside the chip from the PVDD line in, so a drop in PVDD would also cause a drop on VREG (which seems to supply power to the logic portions of the chip from what I can tell). I was previously seeing stability issues, so on the current revision of my board I have an external 3.3V regulator with additional capacitance supplying the VREG pin. Given this setup, is the PVDD pin a likely culprit for causing APP_RESET, or should I specifically be investigating the VREG pin? Or could any of the other voltage rails (Vdvdd, Vgvdd, VbstA, VbstB, VbstC) be part of the issue?

  • 0 in reply to John Potts
    TI__Expert 6011 points

    Hi John,

    You're right, the VREG does power the logic portions of the chip. If there is a VREG_UVLO event, the device considers it as a shut down. And on power up we expect an APP_RESET. Could you verify both PVDD and VREG lines to see if you are seeing any dip that may cause the device to reset?

    Thanks and regards,

    Sachin S

  • 0 in reply to Sachin S
    Prodigy 30 points

    Hello Sachin, I've had a bit of a breakthrough. The capacitors between each phase leg's high side drain and low side source (Chsd_lss on the datasheet) were marked as optional along with other external power phase circuitry, so I provisioned a footprint but only planned to test with them once I had established a baseline functionality. 

    I recently realized the EVM includes the Chsd_lss capacitors though, even though it omits all of the other external power phase circuitry. I've started with the default 10nF and will be tuning that value, but my ESC now works as well as the EVM does.

    Thank you for your help,

    John Potts