TPS65313-Q1: TPS65313 Reference Code for SPI Communication

Hi Ashwin,

I'm not aware of reference code for TSP65313 with C2000, however there is a TPS65381A-Q1 with C2000 reference design:  RE: TPS65313-Q1: TPS65313 Reference Design 

For TPS65313 -Q1 code, you will need to work from the SPI information found in the device datasheet. 

Regards,

Katie

Hi Katie ,
Thank you for the reply
I tried creating my own SPI library to interface the PMIC with F28P65x but i am unable to read values consistently , I was hoping for a reference code to validate software side. If its not available with c2000 , any microcontroller library that interfaces the TPS65313 would do . If no reference is available you can close this thread.

Warm Regards
Ashwin Bhaskar 

Hi Katie,

I am unable to find any example reference of SPI based PMIC in this reference design , PMIC is not seen in the schematic as well . I might have missed it can you tell me where exactly is the PMIC related code in this reference design.

Even in the HAL , SPI isnt initialized so i am assuming it isnt used anywhere , what am i missing here?

Warm Regards

Ashwin Bhaskar A

Hi Katie, 

Thank you for the reply ,

I made a preliminary code base for interfacing SPI with the PMIC based  off the datasheet , but i am unable to read the registers or configure it reliably. If i share the code base with you can you maybe look into it and validate it if possible . I am hard pressed for time and this is a crucial component for us before going to field since we are facing pmic related issues where the pmic is shutting off during current spikes eventhough its within its rated limit . 

Thank you in advance 

Ashwin Bhaskar A

Hi Ashwin,

it could be faster to debug if you could sent an oscilloscope capture of the SPI communication (all 4 SPI channels with labels and clear enough we can see the separate clock cycles). Have you made sure that the hardware connections for the PMIC and between MCU and PMIC are correct? Do you have some other way you can test communication to PMIC (for example an external debugger or similar)?

regards,

Niko

Hi Niko ,

We have a custom board with the PMIC and the controller and the wirings seem to be correct , and im not sure what do you mean by external debugger for the PMIC , if you mean if i have a way to debug the system then yes i have a xds110 module for the f28p65x, i am trying to read the rev id and one of the config registers whose default values are known. To send you an oscilloscope capture is a bit difficult since i dont have physical access to the board at the moment , all i have is the remote access to the system connected to the board. I just wanted to get clarity on two things , from my understanding the SPI mode is SPI mode 1 , and we cannot have consecutive spi operations without the NCS pin going HIGH for 788ns. I am posting a snippet of the SPI transaction logic , if any of my understanding on this is flawed please let me know.

uint16_t spi_transmit_seq_function(uint16_t tx_data) {
    pmic_cs_low();

    SPI_writeDataBlockingNonFIFO(PMIC_SPI_BASE, tx_data);
    
    uint16_t rx_data = SPI_readDataBlockingNonFIFO(PMIC_SPI_BASE);
    
    pmic_cs_high();
    
    DEVICE_DELAY_US(1);
    
    return rx_data;
}

tps_status_t tps_read_register(uint8_t read_cmd_code, uint8_t* data)
{
    if (platform_spi_transfer == NULL) {
        return TPS_ERROR_SPI_FAIL;
    }
    if (data == NULL) {
        return TPS_ERROR_NULL_POINTER;
    }

    uint16_t tx_frame = (uint16_t)read_cmd_code << 8;
    uint16_t rx_frame = spi_transmit_seq_function(tx_frame);

    *data = (uint8_t)(rx_frame & 0x00FF);

    uint8_t status_byte = (uint8_t)((rx_frame >> 8) & 0xFF);
    if (status_byte & 0x01) { 
        return TPS_ERROR_SPI_FAIL;
    }

    return TPS_OK;
}

Warm Regards

Ashwin

Hi Ashwin,

I meant some device like USB2ANY which could be used to communicate with the PMIC (bypassing the on-board MCU) just to see that you are able to communicate with it with some existing solution. 

The SPI mode is 1 so received data is sampled on the falling edge and data is transmitted on the rising edge. SCK standby state is LOW. The NCS pin has to stay HIGH for at least 788ns between operations. 

Sorry I don't really understand how your code works as I am not software engineer. Are you sure you are not trying to write the SPI CRC in the transmission as SPI_CRC is disabled by default. 

regards,

Niko

Hi Niko ,

Sorry for late reply as i was on leave,

Niko Alatalo said:

I meant some device like USB2ANY which could be used to communicate with the PMIC (bypassing the on-board MCU) just to see that you are able to communicate with it with some existing solution.

I dont have access to PMIC via USB since we are using only the IC and not the EVK of the PMIC. I am assuming you wanted to test the PMIC through TI GUI for TPS65313, but that isnt possible since i dont have an evk module and the GUI is not available to download in TI website i believe.
Thank you for confirming the SPI Mode , and i am using 16bit transmissions for SPI so no i am not using the CRC which is 24bit transmissions.

Warm Regards,

Ashwin

Hi Ashwin,

I know you mentioned you do not have physical access to the board, but do you know someone who could help you get captures? We really need to see what is going across on the SPI lines to help troubleshoot further, not just the code. 

-Katie

Hi Katie,

It may take some time to get the captures. Once i receive the captures i will update in this thread

Regards

Ashwin

Hi Ashwin,

thank you we are waiting for the captures.

regards,

Niko

Hi Niko and Katie ,

I received a capture of the SPI communication which was taken on a logic analyzer. The controller is sending a command 0x1 which is to read the DEV REV ID of the PMIC and the response along with CLK and NCS pin is attached below. Let me know if you need anything else.

The value read by the SPI is 0x88 which is the lower 8 bits , but according to datasheet this value must be 0x21 i believe . So i am assuming there is a flaw in the way SPI communication works here. Please let me know your inferences from this .
Warm Regards
Ashwin

Hi Niko and Katie,
I wanted to ask a follow up question the PMIC , currently we are facing issue where when our systems demand high currents the PMIC is resetting completely and the controller is shutdown . Is there a way to disable the feature of PMIC shutting of the BOOST and BUCK converters during an overload event and instead just generate an interrupt ? . I know this isnt possible in severe short circuit events , but my controller and its peripherals require sudden bursts of current during certain operations and the PMIC isnt allowing this extra power requirement.
From my interpretation of the PMIC datasheet , all switch mode regulators are disabled in overload , overcurrent states . Is there any way for the PMIC not to disable these regulators and instead just generate the interrupt .

Warm Regards

Ashwin

Hi Ashwin,

thank you for the waveform. To me it seems like the CS/ENABLE is going high too soon as it should go after the last clock falling edge but here it might go at the same time. Also the status bits (first 8 bits of the SDO channel) show some errors.

I will have to take a look at disabling these safety features and will get back to you tomorrow.

regards,

Niko

Hi Ashwin,

for configuring state transitions when UVOV happens please see data sheet table 11-1 as it lists the registers that affect the device behavior.

regards,

Niko

Hi Niko , 

Thank you for the reply 

I will look into the table and see if its possible to disable any of the protection feature , but in order to do that the SPI communication needs to be solid , from your earlier reply i am unable to proceed forward in code as i am unable to understand why the waveform is in this way , I am doing a simple read command operation and it isnt functioning as expected . The delay you are talking about is already part of the code and it still dosent seem to have any effect . I am assuming the spi communication expects a dummy data command after my original command for which it sends the actual response . Even then the communication seems flawed.

Warm Regards
Ashwin 

Hi Ashwin,

have you used this same SPI code in some other project and tested that the SPI implementation works? I want to rule out the possibility of incorrect implementation of the SPI handling in which case it wouldn't be a PMIC issue. 

Would it be possible to get a capture of the two very first SPI operations after boot up? I would prefer to have this as the raw data for Saleae/Logic software as you also seem to be using that. 

regards,

Niko 

Hi Niko ,

Sorry for late reply,

I am working on getting you those SPI Captures but it might take some time since the custom board we were using earlier is no longer functional due to an accidental short while probing. Once we get the SPI captures i will post it here , One interesting observation was right before the board became faulty i tried changing the SPI mode from mode 1 to mode 0 and i was able to read the revision id correctly as 0x021 and some other RD registers also read correctly based on the initial values mentioned in the datasheet. I am not sure if this is a coincidence because from what you confirmed and what i read on the datasheet the SPI mode is definitely mode 1 . Can you explain why mode 0 seemingly works now ?
 

Niko Alatalo said:

have you used this same SPI code in some other project and tested that the SPI implementation works? I want to rule out the possibility of incorrect implementation of the SPI handling in which case it wouldn't be a PMIC issue

I tested the code in loopback mode and it seems to work just fine , i made a similar SPI driver for DRV8343S which was also SPI based and i followed similar procedure to make it. I don't think its a implementation issue as of now , but i can conduct more tests to be sure.

As i said it may take some time to get those captures. I will post it ASAP.

Warm Regards

Ashwin

Hi Ashwin,

thanks for the information. I am not quite sure why selecting SPI mode 0 seems to work but I have taken an example capture when using the TPS65313 EVM and communicating with the GUI. See below figures on how it looks with this setup. I have read register 0x1 and got the read value of 0x21. Looking now at your transfer figure there seems to be something wrong as the command you send is not 0x1. The PMIC is sampling this command on the falling edge of the clock but in your transaction it seems like the code is implemented in a way that it is expected to be sampling on the rising edge. The rising edge of the clock is in the middle of the MOSI bit. Also I am not sure how you get 0x88 as the read value as to me it seems like it should be 0x10 as the sampling by the MCU should happen on the falling edge of the clock. 

Entire transaction

Zoomed in on the first half of the transaction (showing the CMD in MOSI)

Zoomed in on the latter half of the transaction (showing the read value on MISO)

regards,

Niko

Hi Niko ,

These captures are of great help . Thank you so much 
Give me some time to look into it the driver to see if i have missed something. Looking at these captures i know what to expect so i will try accordingly . I will get back to you as soon as i have an answer .

Warm Regards

Ashwin

Hi Ashwin,

great I am waiting for your results.

regards,

Niko