MCF8316A: Cannot clear faults

Hi Thomas,

If fault is triggered after MPET_CMD is set to 1, clearing fault will cause the device to immediately start MPET again. Maybe you could try clearing MPET_CMD to 0 before clearing fault to see if the algorithm state return to MOTOR_IDLE?

Regards,
Eric C.

Hi Eric,

now I got the MPET to complete after changing to another motor for testing. State is MOTOR_IDLE afterwards. If I set a duty command then, I get LOCK_ILIMIT which can still not be cleared with CLR_FLT, even after setting zero duty again.

Regards

Thomas

Hi Thomas,

Our team will follow up on this before end of week 

Best Regards, 
Andrew 

Hi Thomas,

• Are you reading the device registers after setting a duty command?
• Once the device gets stuck in LOCK_ILIMIT fault state, are you still able to communicate with the device through I2C? (device sending ACK?)

If so, you may be running into one of this device's errata #8: https://e2e.ti.com/support/motor-drivers-group/motor-drivers/f/motor-drivers-forum/1066777/faq-production-device-information

Once the device enters this bad state, the device will become unresponsive, and this could explain why you weren't able to clear the fault. The workaround is to avoid reading device registers during motor operation..

Could you please also ensure that you have sufficient inter-byte delays (at least 100us) when sending I2C commands? 

Regards,
Eric C.

Hi Eric,

I already heard, that it is bad to read the motor state while it is spinning? Will this be fixed in a future version of the device?

With my current setup, I start the MPET by writing MPED_CMD. I then manually wait until the motor stops spinning. When I read the state afterwards, it says MOTOR_IDLE. Next I set the duty to a nozero value, which causses the motor to make a little move and stop immediately. When I read the state again (after the motor has stopped), it has the LOCK_ILIMIT fault which I can not clear. I can still communicate with the device and get ACKs but I cannot reset the fault.

Regards

Thomas

Hi Thomas,

Yes, the errata where I2C access during motor operation causing device to get stuck will be fixed in future version of the device.

1. Could you please share your register settings by reading all registers after running MPET?
2. If you have a current probe, could you please capture the current waveform on all 3 phases from setting the non-zero speed command to fault getting triggered?
3. Could you please share your I2C waveforms for setting the speed command, reading motor/fault status, and clearing the fault?

Regards,
Eric C.

Hi Thomas,

Just following up on your issue, are you still having trouble with the device getting stuck with LOCK_ILIMIT fault? Would you be able to provide your register settings and waveforms?

Thanks,
Eric C.

Hi Eric,

I finally got an evaluation board these days and wanted to experiment with it before writing here again. With the board I was able to find settings for running my motor (the MPET still failed). I also found an error in my code which was the reason for not being able to clear the faults. So now I got the motor running with our custom board.

I also recognized, that the MCF8316A did not get stuck when writing to I2C while it was spinning. When I observed the I2C communication I found, that the board used a delay of 400us between each byte (contrary to the 100us in the data sheet) and with this big delay I am also able to communicate with the driver while the motor is spinning.

While I observed the communication I  found, that the evaluation board uses the CRC but the crc-value that is calculated does not match what I would calculate based on the data sheet. I do not necessarily need the CRC but would be interrested in how it is calculated by the MCF8316A.

I would also like to know where the difference is between the FG_SPEED_FDBK and SPEED_FDBK.

Regards

Thomas

Hi Thomas,

Glad to hear you were able to spin up your motor.

Let me consult with our internal team regarding the CRC calculation and FG_SPEED_FDBK vs SPEED_FDBK and get back to you.

Regards,
Eric C.

Hi Eric,

thank you very much for this answers. Indeed the initial value was the missing part for CRC.

Regards,

Thomas

Hi Thomas,

You're very welcome. Please let me know if you have any other questions.

Regards,
Eric C.