Hi,
I am using the TPS65381 on a TMS570LS0332. On the same bus I have an IO expander chip.
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.
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.
I first started this in the Hercules forum, and from Anthony Seely
"Hi David,
If it is the SDO error then I would post on the automotive forum and ask the TPS team for help.
I did dig up earlier a few slides from a field apps engineer talking about false SDO errors that were triggered by clock activity while NCS was inactive (i.e. talking to another SPI device) but I wasn't able to find anything about this in a silicon errata on the TPS product folder. So it may be something like you having pre-production silicon with this issue but it's cleaned up in the production silicon. That's just speculation though - best to get the answer from the team directly responsible from the TPS65381. They monitor the automotive forum. But if you don't get an answer from there - I can try to get you a contact.
Best Regards,
Anthony Seely
"
I took out all of my error handling and acted as if all calls returned true. The TPS chip seems to acknowledge my watchdog answers and responds correctly to all queries. Is there a possible false error occurring? Is there anything I can do besides ignoring the output from the TPS driver?
Thanks,
David
