High Estimator Bandwidth During High Load and Inertia Causes Software Hang

[derekcook]

Hello, 

I ran across this problem in my testing of the sensorless motor control. I have the minumum startup current set to 100% of rated (which is 150A - I need this to always be 150A so I can start at high loads), I have my estimator bandwidth set to 76Hz, my inertia is 0.0672 A /RPM/s, and the load on my motor is at 70 Nm. When the bandwidth is set to 76Hz with the high inertia and high load, the software hangs. This causes a reboot on my system, because the software quits petting the watchdog. 

If I lower the Estimator Bandwidth below 30 Hz the software hang goes away. All of the other settings and loads remain the same. Any idea why the high bandwidth would cause the software to hang?

[derekcook]

The hang seems to happen after the startup block. It seems to happen in the transfer between startup and estimator.

[linestream-adam]

My guess is that with the high bandwidth on the estimator, at the transition from open-loop to closed-loop there is a large amount of current draw and the processor browns out. You would need to look at the SSRS registers to know exactly why the processor reset.

That being said, given the large inertia of your application, do you see an issue with the lower estimator bandwidth?

[derekcook]

Adam, 

How would I look at the SSRS registers? I can take a look at that. I do not see an issue with the lower bandwidth. The control works just fine.

[philip_drake]

Yes, the MCU reference manual details the reset states.  The registers are RCM_SRS0 and RCM_SRS1 - which are in the Reset Control Module. In the MCUXpresso IDE you can choose peripherals, choose the RCM and then look at the registers after a pause.  The SRS bits reflect what caused the last reset.

Best Regards,

Philip

[derekcook]

Thanks for the help, and pointing out these registers in the MCU datasheet. Since the issue cleared with the lower bandwidth we moved on to other aspects of software testing for now, but I will increase the bandwidth again once we test some more aspects of the software, and check the SRSS register to see what caused the reset.

[derekcook]

Hey Adam and Philip, 

I can't use the debugger while in the system due to high positive and negative voltages. 

I can use the RCM_GetStickyResetSources() command from fsl_rcm.h, however:

static inline uint32_t RCM_GetStickyResetSources(RCM_Type *base)
{
#if (defined(FSL_FEATURE_RCM_REG_WIDTH) && (FSL_FEATURE_RCM_REG_WIDTH == 32))
return base->SSRS;
#else
return (base->SSRS0 | ((uint32_t)base->SSRS1 << 8U));
#endif /* (FSL_FEATURE_RCM_REG_WIDTH == 32) */
}

First I wanted to see what the SRSS bits return in Normal Reset Cases:

This to me looks like SSRS0 is stored in bits 0-7, and SSRS1 is stored in bits 8-15. 

On a normal reset using the NVIC_SystemReset() Command I see: 

0x00000400 is the value returned by this function, which corresponds to bit 2 in SSRS1: 

Which makes sense since NVIC_SystemReset() sets the SYSYRESETREQ bit in the MCU.

If I hang the slow or fast thread, and let my watchdog reset the MCU, this register returns 0x00000040. This is bit 6 in SSRS0, which indicates that the reset was caused by the System Reset been being driven low, which makes since: 

It looks like powering off the MCU causes 0x00000082 to be set in SRSS0 which corresponds to reset caused by low voltage:

It also looks like powering off the MCU clears the previous SRSS bits. 

Now I'm going to duplicate the reset to see what happens. I think it will just tell me the watchdog reset the MCU because the software thread hung. It did look like the high estimator bandwidth caused the software to hang

[linestream-adam]

Derek,

I would be surprised if the watchdog ends up being the issue. There should be no correlation between high estimator bandwidth and CPU usage.

[linestream-adam]

Look at the mcu datasheet. That should give you the address of those registers. From there you could save them into a variable or read them with your debugger after the brown-out event.