2022-04-11 03:54 AM
Hi, we are facing a strange problem with your MCU + GD combo - STSPIN32G4.
In general, about 60% of soldered ICs are not working properly, we test on the default firmware generated for EVSPIN32G4 and we get error "64 overcurrent" and / or gd_nfault and gd_ready flags are false (which is bad).
We use our own PCBs, so far we have tested >50 chips, because we are in the R&D phase, we solder the chips inhouse using various methods:
We haven't yet baked the chips according to the JEDEC (J-STD-033D) procedure.
We switched to SPIN32 from DRV8323 from TI, which we've never had such problems with.
We suspect a problem during assembly, although the technician has experience with QFN / SMD soldering (and with DRV8323 there were no such problems). Or the problem with damp chips. Or possibly poor layout, due to generic centerpad footprint (autogenerated by Ultra Librarian) - lot of tiny vias, that come out "blinded" / impermeable, no air will pass, let alone the tin, I attached cutout picture of what I mean:PCBs were mnfg by JLC.
Motor control schematic is based 100% on EVSPIN32G4 schematic, and we can get some of the MCUs to work, and when they do, they're great little beasts.
ICs itself were purchased from Mouser late last year and from Farnell like 5 days ago.
2022-04-12 01:44 AM
Hello @KKost.3 and welcome to the ST Community.
Are you using the STM32 Motor Control Workbench (X-CUBE-MCSDK)?
Could you share the STATUS register content before starting the motor and after the fault event?
2022-04-13 02:24 AM
Hi, @Cristiana SCARAMEL.
Yes, We're using X-CUBE-MCSDK.
Here are status registers, before starting motor, so g_fsm_status:state is FSM_INIT
On this particular board, motor won't start at all, even tho gd_nfault is true (so correct), no error occurs, and stm_state_motor is RUN. On other boards, there are indications, that there's some problem, like false-positive "error 64 - overcurrent" or gd_nfault == false.
In general, after soldering new chip, motor starts to spin, tho not always.
Is there a problem with our PCB layout? Soldering technique? Storage method?
If it is, its weird that MCU part always works (we can talk with rest of the system, program MCU ofc), but GD part gives Error 64 or gd_nfault == true.
We could switch chips over and over again, but it doesn't make much sense. We need to figure out why this all is so inconsistent.
2022-04-14 12:42 AM
Hi @KKost.3 ,
I meant the contents of the device STATUS register, refer to STSPIN32G4 datasheet at page 33.
We try to understand the actual condition of the device before starting and when fault event occurs.
2022-04-14 04:01 AM
Ah, okay, using this code:
HAL_I2C_Mem_Read(&hi2c3, 0b10001110, 0x80, 1, &g_reg_80, sizeof(g_reg_80), 100);
I'm reading STATUS register with result of
On this particular board, error 64 occurs right when encoder aligning begins.
2022-04-21 02:27 AM
Hi @KKost.3 from the device STATUS register no fault event is occurred in the gate driver.
It seems that internal comparator is triggered causing the spurious overcurrent error.
Assuming this event is caused by noise on the comparator, you can try to reduce its effect increasing the duration of Digital filter (refer to following figure:
In general, about the board assembly, the manual soldering is not recommended.
Edit: added missing figure :grinning_face_with_sweat:
2022-04-26 11:31 PM
Hello, @Cristiana SCARAMEL. Thanks for helpful answer, tho actually modifying Digital filter duration didnt help us, setting "Over Current Protection Topology" to "No protection" did make our boards working. And now every board that had error 64 works. I know this is only bypass, not a solution.
2022-04-27 02:26 AM
Hi @KKost.3,
based on this feedback I see two possible root cause:
2023-06-09 03:53 AM
Hi KKost,
Were you able to solve the problem of over current. I also face the same issue now.
I have designed a custom board based on STSPIN32G4 schematic but with an automotive mosfet (iaua200n04s5n010auma1).
Everything works except that the controller enters over-current state every time I tried to run the motor pilot GUI.
Does this have to do with the internal Mosfet gate driver?
Thanks, and best regards,