TMS320F2800157-Q1: Issue with the custom board - F2800157 and DRV8301

Hi,

Danish Malhotra said:

We are able to run the motor using our custom board with level 4 build without any issues till 500 Hz (1400 RPM) but we observe OC LED starts blinking

What is driving this OC LED? Is it a DRV8301 device signal or the C2000?

Danish Malhotra said:

We don't see any error on the status registers. But the same motor works fine with the DRV8301 Eval kit.  

Which status registers are you meaning? Have you verified the C2000 CMPSS is not causing the OC trip?

Best,

Kevin

Hello Kevin,

Thanks for your response. 

OC led is driven by OC pin (nOCTW) of DRV8301. 

Tripzone setup is disabled in our firmware. Code is using the CMPSS1 and CMPSS3Lite but none of the registers are changing when OC fault led lights up. 

Regards,

Hi,

Have you read out the DRVx registers over the SPI interface to confirm if its OC or OT condition? If OC condition is occurring you may need to adjust the R_DS(on) value in the DRVx register. See the datasheet for further details.

You may also consider increasing the PWM deadtime / deadband, maybe it's too small currently (Note: I did not check if the DRV8301 has a feature built in for this).

Best,

Kevin

Hello Kevin,

We tried increasing the OC_ADJ_SET value but no change. Also, DRV8301 has a deadtime setting feature. We tried increasing the time to its max but no luck with that. We are having trouble reading the SPI registers when the motor is running. 

Hi,

Danish Malhotra said:

We tried increasing the OC_ADJ_SET value but no change

It's tripping at the same speed and motor current after changing OC_ADJ_SET value? Are you using a current probe while testing to collect waveforms?

Danish Malhotra said:

Two parallel mosfets are used in the design. 

I wonder if some additional consideration is needed for the Vds sensing when driving two MOSFETs in parallel. I'm going to pass this to the motor drive team for support.

Best,

Kevin

Yes Kevin it's tripping at the approximately same speed even after changing the OC_ADJ value. 

Please let me know if any other consideration is required for the dual mosfet design. 

Thanks,

Hi Danish, 

I'm a supporting Brushless DC Motor drivers and will be helping to look into this inquiry. 

Danish Malhotra said:

We are having trouble reading the SPI registers when the motor is running. 

Can you please help to clarify what issue you're having trying to read the SPI registers on the device?

This will be very important for us to help narrow down the source of this behavior. 

Best Regards, 

-Joshua

Yes, when we run the code on DRV8301-69M-KIT, we see that the SPI data stored in drivcVars_M1 is not getting updated when the flagEnableRunAndIdentify is disabled. But when we connect a logic analyzer with the board we can see that MCU is sending data and DRV8301 is replying with correct values at initilization. (Please see the image attached)

When we enable flagEnableRunAndIdentify and the motor is running, then we can see the values of drivcVars_M1 update. But those values are not correct, since the DeviceID keeps changing (which should be constant).

We also see noise in the SPI data when the motor is connected to the kit.



Talking about our own PCB, we do not have test pads for the SPI lines so it is really hard to connect a logic analyzer to those lines. But there the drivcVars_M1 variable never changes even if flagEnableRunAndIdentify is True.

At the time of board bringup, we did connect SPI lines to a logic analyzer to see if the data is going properly and it was.

Thank you for the explanation and image,  this will help as I look into this matter further.  Please expect a further response by early next week at the latest. 

Best Regards, 

-Joshua

Hi Sheershak, 

I apologize for the delay as I previously went on leave. 

Would it be possible to share the board layout design for this parallel mosfet configuration? The VDS monitoring behavior may be caused by an issue/imbalance in the dual power stage layout.  

Also, There may be some issue with the SPI line connections (which could be a soldering issue is the connection is faulty). I would confirm the SPI data limes being sent on the custom board are to the correct registers with the proper clock/SPI timing requirements and that the signals aren't being interfered. 

Can other SPI settings be changed and observed? It's said that the OC_ADJ_SET value being changed is showing no effect, but can we check this case when the OCP mode is disable to completely confirm this fault response?

Thank you for your patience and I apologize again for the delay. 

Best Regards,

-Joshua