DRV8363-Q1EVM: Query on DRV8363-Q1EVM compatibility with MSPM0G3519 MCU

Hey Sakhan,

The C2000 49C launchpad is the recommended one because of thew compatibility with the EVM Software/GUI, and its what we have tested to work.

But no, there is nothing preventing you from jumping over the signals from another MCU provided you write its firmware for motor control. 
We dont have a general purpose MCU bring up guide but as long as the EVM schematic can be used to jump over signals to your MCU's I dont expect it to be much different. 

For 6 step commutation, you can use MCU deadtime, and or rely on the DRV deadtime (provided your are not using independent mode - no dead time insertion).

I can pass this thread over to the M0 team to see if they have any guides to bring up with M0 for motor control.

Best,

Akshay

Hi Sakhan,

Here is some documentation on motor control with MSPM0:

• MSPM0 Motor Control
• Using MSPM0 MCUs to Design Trapezoidal-Based BLDC Motor Controllers

Furthermore, our SDK has some motor control examples available:

Best,

Owen

Hi Owen,

Can I validate the DRV8363-Q1EVM by generating PWM and basic GPIO signals (like nSLEEP ..etc) without using SPI, and will this be sufficient to verify the driver’s functionality?

Regards,

SaKhan

Hi SaKhan,

Based on the DRV6383-Q1 datasheet, SPI is used for setting device configurations, operating parameters, and reading out diagnostic information.

If you need further support on this, I can loop in the motor drive team on this thread.

Best,

Owen

Hi Owen,

I’d appreciate it if you could add the motor drive team to this thread.

Regards,

Sakhan.

It would be great if I could get an application note for the DRV8363S SPI implementation for each mode, including the register configuration.

Hi Sakhan,

I have just added the motor drive team to the thread.

Best,

Owen

Hey Sakhan,

The basic device bring up and functionality can be done without SPI, by using the default register configurations. 

We dont have an application not for the SPI configs but the definitions and the default configurations are shown in the datasheet SPI table.

Best,
Akshay

Hi Akshay,

Thank you for the clarification.

Could you please explain the basic device bring up and functionality in more detail? It would be helpful if you could outline the steps involved, including how the device initializes and operates using the default register configurations without SPI.

How to reset the DRV8363 to bring all the register to default values.

Regards,

SaKhan

Hi Akshay,

I have configured the MSPM0 SPI controller to send the DRV8363 SPI frames.

IC_STAT1 Register (Offset = 0h) [Reset = 8080h]

Now Address of IC_STAT1 Register is 0x00 (Offset = 0h).

RW is 1

Data is 0x0000 

Parity is 1

1. The frame formed as per the DRV SDI Frame format (24 bits). Verified the SPI Tx and Rx by Enabling the Internal Loop Mode before connecting to DRV8363.

2. Code Section

#include "SPI_Frames.h"
#include "globalVariables.h"
#include "ti_msp_dl_config.h"
#include <ti/driverlib/m0p/dl_interrupt.h>

#define SPI_PACKET_SIZE 8
#define TIME_BETWEEN_EACH_FRAME 13 // 400ns is 13, 1us is 32 (as per DRV datasheet)

SDI_Frame tx;
SDO_Frame rxFrame;
uint8_t gTxPacket[SPI_PACKET_SIZE] = {0x11, 0x22, 0x33, 0x44,
                                      0x55, 0x66, 0x77, 0x88};
uint32_t sendBytes;
uint8_t i;
uint8_t sdi[3];
uint8_t txBytes[3];
uint8_t rxBytes[3];

//func proto
static SDO_Frame drv8363_spi_transfer_frame(SDI_Frame txFrame);

int main(void) {
  SYSCFG_DL_init();

  //nSLEEP to "HIGH" (Enable the DRV)
  DL_GPIO_setPins(GPIO_GRP_0_PORT, GPIO_GRP_0_PIN_B12_PIN);
  drv8363_ReadFrame(&tx, 0x00);
  

    drv8363_spi_transfer_frame(tx);

    drv8363_ReadFrame(&tx, 0x00);
    
    drv8363_spi_transfer_frame(tx);

  while (1) {
  }
}

static SDO_Frame drv8363_spi_transfer_frame(SDI_Frame txFrame)
{



    /* -------- Split SDI raw into 3 bytes (MSB first) -------- */
    txBytes[0] = (txFrame.raw >> 16) & 0xFF;
    txBytes[1] = (txFrame.raw >> 8)  & 0xFF;
    txBytes[2] = (txFrame.raw)       & 0xFF;

    /* -------- Start SPI frame -------- */
     for (int i = 0; i < 3; i++)
    {
        DL_SPI_transmitDataBlocking8(SPI_0_INST, txBytes[i]);
        rxBytes[i] = DL_SPI_receiveDataBlocking8(SPI_0_INST);
    }

    while (DL_SPI_isBusy(SPI_0_INST));

    /* -------- End SPI frame -------- */


    /* -------- Assemble received bytes into SDO raw -------- */
    rxFrame.raw =
        ((uint32_t)rxBytes[0] << 16) |
        ((uint32_t)rxBytes[1] << 8)  |
        ((uint32_t)rxBytes[2]);

    return rxFrame;
}

3. Verified the PICO pin data using the Picoscope. There are 48 rising edge (Each frame = 24 clock rising edge) 

4. Now, connected the DRV8363 with proper pin mapping. [SPI CLK to DRV SCLK, SPI CS to nSCS, SPI PICO to SDI, SPI POCI to SDO]

Also, the nSLEEP made HIGH to clear Fault Pin after power up. Refer the below MSPM0 and DRV setup,

When I send the read frame [0x810000] to DRV there is no response (nothing recieved in Rx register) why? Even I achieved delay between each frame sent to MSPM0 to DRV (Refer the Picoscope data).

I am not getting the data from the DRV even after sending required frames? 

Kindly help me on this.

Regards,

SaKhan

Hey Sakhan,

Is the green chipselect? it should go high once per word (24 bits).

Have you checked out the DS section 6.6 Programming 6.6.1 SPI?

Best,

Akshay

Akshay,

1. I have added my device setup, MSPM0 configuration and frame validation using Picoscope. Please have a look above my response for all details.

2. From MSPM0, I have validated the Tx and Rx code by send data from PICO and received in POCI using Internal Loopback. As expected the Tx frame recieved in Rx buffer.

3. When I connect the DRV, I am not getting response for the Tx frame send by MSPM0. Please check all post above and tell me where I am doing wrong like Pin mapping or wrong SPI mode setup or anything. Please guide me to solve this.

4. I have asked you about the basic functionality (BLDC or BDC) test to prove the DRV is working as expected. Tell me the way to check the functionality with SPI.

Regards,

SaKhan

The photo doesn't zoom very well, but I think I don't see anything connected to the PA14 (PICO) pin on J1.2. 

Alternatively: maybe the wire is connected to J1.2, in which case I don't see a 3V3 connection.