EVSPIN32G4 driver protection glitching during boot-up

[jimmydvr]

Hi 

Recently, I am working on a 3-phase hub motor with hall sensor to be able to drive low speed accurately. I came across the EVSPIN32G4 and works fine with sensorless-PLL speed sensing by using the MC Workbench V6.3.2. I precedeed to modify the hardware board to a single-shunt resistor (Instead of 3 shunk resistors)

When changing the speed sensing to hall sensing, I started to see driver protection fault errors. Occasionally when I start ST Motor Pilot V1.2.12, the Driver Protection flickers between Orange and red, with no way of clearing the fault condition, unless I reset the STSPIN32G4 (Reset button). 

I tried increasing the Driver protection digital filter duration (Default 47.06 ns) to 941.18ns but it made no difference.

I tried unplugging the hall sensor, but the fault condition still happens. 

I checked the cubeMX code configuration and the driver protection pin (PE15) is set to Open drain with pull-up. 

I later found out that it's something to do with boot-up issue, by checking the Motor Pilot Terminal FAULTS_FLAGS (Code: 0x0019). 

Why does this happen when switching sensorless-PLL to hall sensing? Is there a way to check why it is not booting up correctly (Every time I run in debug on the STM32CubeIDE and step execute the code, it does not error out) - The firmware is as is from the code generated from the MC Workbench?

Any guidance on where to look for is greatly appreciated, as I am stomp on this situation.

Kind regards,

Jimmy

[jimmydvr]

Hi GMA,

I have brought another new EVSPIN32G4 and uploaded the project code (Not modified). However, the device does not respond to ASPEP_BEACON. (Had to update the programmer firmware)

I have tried building the code from a new MC workbench (Not hall sensing - Default to Observer sensorless and three phase shunt resistors). The only part I changed are the potentiometer and switch off the start/stop on control board. The device still does not respond to ASPEP_BEACON. 

I am stomp here. The debug code steps through to the while (1) loop. I checked the pinout configuration USART1 and the parameters looks right.

I am going to try on another PC to see if there is some strange behaviour the PC is experiencing first. 

[jimmydvr]

Hi GMA,

I just noticed the baud rate was incorrect. It is now working. The Driver protection race condition is gone for now and I haven't seen it since.