Using TPS65381 on the same bus as other chips

Hi David,

I'm going to have to research this one. I think this came up when the HSK was being developed and I remember people having trouble w. this but I think it was just a case where you had to be very careful rather than something you couldn't do. I'll do some digging to see what I can find and let you know.

Thanks for your follow up. We have several boards that are using the TPS chip, and I think most of them have it on the same bus as something else, so getting it working is very important since changing the boards would be a difficult task.

Thanks,
David

Hi David,

Selecting the TPS65381 using a SPI chip select does seem to be supported, from what I can tell. There isn't any mention that it's not supported in the TPS65381 datasheet for starters. And there are some forum posts on the topic.

One pitfall is mentioned by Haixiao in his appnote (SPNA176) - and also in TPS65381-q1 datasheet. This is that the TPS has a minimum time for NCS\ deasseration that is long compared to what the MibSPI would naturally - 788ns according to section 5.5.1.1 of the TPS datasheet.

A good idea might be to double check my answer by posting on the Automotive Forum - that's where the TPS65381 is supported.
That is if you don't have a specific issue but were just checking.

If you have a specific issue then would be good to get the details.

Best Regards,
Anthony

Thanks for your reply.

I followed SPNA176, as well as the link below when configuring halcogen

http://processors.wiki.ti.com/index.php/Configuring_HALCoGen_for_using_TPS_Driver

I have Wdelay set to 63, so I believe that should cover the timing requirement.

I will post in the automotive forum as well.

Specifically though, I have a task (running freeRTOS) that services the TPS Q and A watchdog. So on startup I initialize the TPS driver and tell the TPS chip to stay in the diagnostic state. Then I start servicing the watchdog and once the fail count gets to 0 I tell it to go to the active state and then continue to service the watchdog.

This works fine when it is the only thing running.

If I add in code that initializes an IO expander on the same spi bus (but after that never touch the bus), the first TPS call I make after that I have to make a few times until it goes through without failing and then the TPS task works OK.

If I initialize the IO expander and run a task that blinks an led that is connected to the IO expander (1 Hz rate), all of the TPS calls fail.

The IO expander uses a different data format than the TPS chip, and is on a different chip select. I will take another look at the signals electrically, but they seem OK. At first I thought that maybe the IO expander was holding the chip select, but this is not the case.

Thanks,
David

Hi David,

When you say that the TPS call fails - specifically what does this mean?  (is some data returned by the TPS itself indicating a failure?)

-Anthony

The function call returns false.  So for example if I have

uint8_t devState = 0xFF;

bool noErr = FALSE;

noErr = TPS_GetCurrentTPSDeviceState(&devState);

 

 

noErr is returned as false and the value in devState is still 0xFF.  When I don't use the IO expander noErr returns as TRUE and devState changes to 0x07, which is what I would expect.

Hi David,

Have you tried either turning on the "TPS_SendDebugText" logging or stepping into the function calls to find out which step is failing ?
Looks like it is pretty simple until you get down into the TpsIf_SendCommandOverSPI function.. But knowing exactly which step fails and what register value of the TPS is associated w. this fail could really shed some light as to what is going on.

Looks like building the lib w. -DDEBUG_ENABLE=1 and -DERROR_ENABLE=1 is what you would need to do.

Thanks for your response. That is what I am working on at the moment. There are a few build issues I am running in to with the lib, but I should be able to sort them out.

Thanks for your help.

It is failing the check in TpsIf_SendCommandOverSPI

 if (NO_ERROR
                        == BFU8_GET(u8SAFETY_STAT_4, BF_SPI_ERR_START,
                                BF_SPI_ERR_LENGTH))
                {
                    /*checking whether there were no errors in the previous SPI transfer phase*/
                    if ((MULTIBITKEY_SET
                            == BFU8_GET(u8SPIPreviousStatus,
                                    BF_MULTIBITKEY_START, BF_MULTIBITKEY_LENGTH))
                            && (0u
                                    == BFU8_GET(u8SPIPreviousStatus,
                                            BF_SPI_ERRFLAG_START,
                                            BF_SPI_ERRFLAG_LENGTH)))
                    {
                        blRetVal = TRUE;/*Sth is wrong with the previous SPI transfer*/
                    }
                    else
                    {
                        blRetVal = FALSE;
                        TPS_SendDebugText(ERROR,
                                "TpsIf_SendCommandOverSPI SPIPreviousStatus error",
                                (uint32) u8SPIPreviousStatus);
                    }
                }
                else
                {
                    blRetVal = FALSE;
                    TPS_SendDebugText(ERROR,
                            "TpsIf_SendCommandOverSPI SPI ERR  ",
                            (uint32) u8SAFETY_STAT_4);
                    TPS_SendDebugText(ERROR,
                            "TpsIf_SendCommandOverSPI  u8SPIPreviousStatus is",
                            (uint32) (uint32) u8SPIPreviousStatus);
                }

So it falls into the bottom else.  The value of u8SAFETY_STAT_4 is 0x4C, and the value of u8SPIPreviousStatus is 0xA4, which I think indicates an SDO error on the previous transmission.  Doesn't an SDO error mean that the output on the SDO pin doesn't match what it should be shifting out?

When I comment out initializing the IO expander, u8SPIPreviousStatus = 0xA0 and u8SAFETY_STAT_4  = 0x0C.

 

The simplified flow of my program is this:

 

- Create an executive task

- Run the scheduler, exec task starts

- Initialize TPS - returns no error (calls TPS_DriverInit and TPS_SetMCUSoftwareDebugMode)

- Initialize IO expander chip - This is the only thing outside of the TPS code that accesses the spi, it only sets a few registers and then is done.

- create a task for the TPS watchdog

- Exec tasks main is nothing but a sleep, so TPS watchdog task runs

- Call TPS_GetCurrentTPSDeviceState - This is where I see the behavior above.  Nothing else is accessing the spi at this point.  When I make the call to TPS_GetCurrentTPSDeviceState again, it passes with values of 0xA0, 0x0C, and after that it is OK. 

However, if I create another task which blinks a led through the IO expander at 1 Hz, then I see the same failure later in the code when the TPS code is trying to send the wdog answer, so it always fails.

 

Thanks for your help. I'll let you know if I don't get a response from them.

 

[EDIT] I quickly took out all of my error checking, so I always act like the functions returned OK, and everything seems to work, so you may be on to something. The TPS chip is at least receiving transfers / responding correctly.
 
David

Hi David,

Do you see a problem in the driver with your use case. We have not tested  the tpsdriver in similar setup

Just was curious to know the behavior.

Regards

Manoj

Hi Manoj,

It looks like the issue is that I am getting a false SDO error. Since this comes from the TPS chip I don't think it's an issue with the driver. I got a response from the automotive forum and am working with them to see what is going on.

Thanks,
David

Thanks David.