• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 30 subscribers
  • Views 1223 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

DRV8305: CONTROL REGISTERS MODIFICATION (NOT -Q1)

DRV8305: CONTROL REGISTERS MODIFICATION ISSUE

Al J
Prodigy 190 points
Part Number: DRV8305
Other Parts Discussed in Thread: TIDA-00643

Hi,

Finding strange issues when modifying registers in my DRV8305 via SPI. When trying to modify in a lab the registers and I read back the same same registers to make sure they have changed, I keep reading deault values. Checked SPI buffer meage is correct, and I doubt it is an SPI protocol issue (otherwise I would be reading 0's instead of deafults). Unfortunately I don't have a scope to show the signals... any ideas of what could be going wrong?

Please find the added code to lab 3a below: (Also modified the SCS function to manual low/high for each SPI transmission in hal.c, as done in reference design TIDA-00643.)


#ifdef DRV8305_SPI
// turn on the DRV8305 if present
HAL_enableDrv(halHandle);
// initialize the DRV8305 interface
HAL_setupDrvSpi(halHandle,&gDrvSpi8305Vars);
#endif

//ADDED:

gDrvSpi8305Vars.Ctrl_Reg_05.IDRIVEP_HS = ISour_HS_0p500_A;
gDrvSpi8305Vars.Ctrl_Reg_05.IDRIVEN_HS = ISink_HS_0p500_A;
gDrvSpi8305Vars.Ctrl_Reg_05.TDRIVEN = TSour_1000_ns;

gDrvSpi8305Vars.Ctrl_Reg_06.IDRIVEP_LS = ISour_LS_0p500_A;
gDrvSpi8305Vars.Ctrl_Reg_06.IDRIVEN_LS = ISink_LS_0p500_A;
gDrvSpi8305Vars.Ctrl_Reg_06.TDRIVEP = TSink_1000_ns;

gDrvSpi8305Vars.Ctrl_Reg_0A.GAIN_CS1 = Gain1_20VpV;
gDrvSpi8305Vars.Ctrl_Reg_0A.GAIN_CS2 = Gain2_20VpV;
gDrvSpi8305Vars.Ctrl_Reg_0A.GAIN_CS3 = Gain3_20VpV;

gDrvSpi8305Vars.Ctrl_Reg_07.DEAD_TIME = DeadTime_2000_ns;
gDrvSpi8305Vars.Ctrl_Reg_09.EN_SNS_CLAMP = 1;
gDrvSpi8305Vars.Ctrl_Reg_09.SLEEP = 0;


gDrvSpi8305Vars.WriteCmd=true;
HAL_writeDrvData(halHandle,&gDrvSpi8305Vars);
gDrvSpi8305Vars.ReadCmd=true;
HAL_readDrvData(halHandle,&gDrvSpi8305Vars);

  • 0
    TI__Intellectual 2595 points
    Hello,

    First and foremost, if you're able to get a scope capture of the SPI transaction, please do so, as it will make debugging this a lot easier if we know for sure what's being communicated between the MCU and the DRV.

    That said, the fact that you're able to read the default values back suggests that the SPI formatting is working correctly at least. Are you sure that the EN_GATE pin is not going low at any point between your write and your read transactions? If EN_GATE goes low, the device will enter the standby state, and the digital logic will be reset.

    Thanks,
    Garrett
  • 0 in reply to Garrett Walker
    Prodigy 190 points

    Hi Garrett,

    Altough I cannot probe the signal, how about this, then? From the datasheet:

    7.4.2 Standby State
    After the power up sequence is completed and the PVDD voltage is above VPVDD_UVLO2 threshold, the DRV8305
    will indicate successful and fault free power up of all circuits by releasing the nFAULT pin. At this point the
    DRV8305 will enter its standby state and be ready to accept inputs from the external controller. The DRV8305
    will remain in or re-enter its standby state anytime EN_GATE = LOW or a fault type error has occured. In this
    state the major gate driver blocks are disabled, but the passive gate pulldowns are still active to maintain the
    external MOSFETs in their high impedence state. It is recommended, but not required to perform all device
    configurations through SPI in the standby state

    Thanks

  • 0 in reply to Al J
    TI__Intellectual 2595 points
    You're correct, the device will behave as described in the datasheet section you've copied. I was thinking of another device, but the DRV8305 will not clear the SPI registers from EN_GATE going low.

    I'll keep looking into this.

    Thanks,
    Garrett
  • 0 in reply to Garrett Walker
    Prodigy 190 points

    Could you give some advice/solution? I've read the whole datasheet and I cannot see any reason why that could happen. Moreover, if I loop the write/read part of the code, it manages to modify the (only some) of the registers after a while, and those are kept with the modified values in the following readings, so there cannot be any logic reset condition.

    Thanks.

  • 0 in reply to Al J
    TI__Intellectual 2595 points
    Just to confirm, you're saying that if the write/read is looped multiple times, eventually some of the registers are written, and then those values are retained?

    Do you have any external pull-up or pull-down on SDO, and if so, what is the resistance? Also, which version of the device are you using (3.3V, 5V, or no VREG), and what is the MCU's interface voltage?
  • 0 in reply to Garrett Walker
    Prodigy 190 points

    Garrett Walker said:
    Just to confirm, you're saying that if the write/read is looped multiple times, eventually some of the registers are written, and then those values are retained?

    Exactly.


    Garrett Walker said:
    Do you have any external pull-up or pull-down on SDO, and if so, what is the resistance? Also, which version of the device are you using (3.3V, 5V, or no VREG), and what is the MCU's interface voltage?

    No resistance in the SDO line, but as I read non-zero values I doubt there is a problem in the lines. Also, I'm using the 3 version, but I've included a buck converter to act as a supply for the rest of the circuitry, so, although Vreg is attached to the same power (3.3V) net, that shouldn't mean anything, as the buck is much more powerful.

    Thanks. 

  • 0 in reply to Al J
    TI__Intellectual 2595 points
    Yeah, the 3.3V line should be fine. The fact that writes are inconsistent makes me somewhat suspicious of the timing. Can you double-check the configuration of the clock polarity and clock frequency in your SPI code?

    The DRV8305 captures data on the falling edge of the clock, so if nSCS is being de-asserted at the same time as the final falling edge of the clock, it could potentially close the SPI frame when only 7 bits of the second byte have been transmitted. This would cause the DRV8305 to ignore the frame, which could explain why the writes are sometimes being ignored, but the reads function correctly (no data is being lost in the second byte). If you are able to get access to a scope for investigation, please ensure that the time between the last falling edge of the clock and the rising edge of nSCS is at least 50ns, as per the SPI timing requirements of the datasheet.

    Thanks,
    Garrett
  • 0 in reply to Garrett Walker
    Prodigy 190 points

    Finally added more delay between each write frame at now it writes without a problem.

    Thanks.