High Estimator Bandwidth During High Load and Inertia Causes Software Hang

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

High Estimator Bandwidth During High Load and Inertia Causes Software Hang

1,459 Views
derekcook
Senior Contributor I

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?

Labels (1)
0 Kudos
8 Replies

1,229 Views
derekcook
Senior Contributor I

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

0 Kudos

1,229 Views
linestream-adam
Senior Contributor I

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?

0 Kudos

1,229 Views
derekcook
Senior Contributor I

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.

0 Kudos

1,229 Views
philip_drake
NXP Employee
NXP Employee

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.

kv31_RCM_SRS0.png

kv31_RCM_SRS1.png

Best Regards,

Philip

0 Kudos

1,229 Views
derekcook
Senior Contributor I

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.

0 Kudos

1,229 Views
derekcook
Senior Contributor I

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: 

pastedImage_3.png

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: 

pastedImage_2.png

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

pastedImage_5.png

pastedImage_4.png

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

0 Kudos

1,229 Views
linestream-adam
Senior Contributor I

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.

0 Kudos

1,229 Views
linestream-adam
Senior Contributor I

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. 

0 Kudos