reset entry when using TPSDriverLib_BE.lib

Hi David,

Before using any of the other API's of TPS device the TPS driver has to be initialized. By calling TPS_DriverInit.

Did you have a look at the example application bundled in the Safety Diagnostic library installation.

You can import the TPS driver demo application into CCS  from path

C:\ti\Hercules\SafeTI Diagnostic Library\2.1.0\build\RM46L852_CNCD

and have a look at the sys_main.c to see how the TPS driver API's have been used to initialize the TPS device.

Can you also send me your init code for the TPS so that I can have look at it and see if anything is missing.

Can you also check the page named Build in the TPS driver documentation.Please do get back to me if there is 

anything urgent.

Regards

Manoj

Hi,

Thanks for your help.

I had looked at some of the examples attached to the user guide, but was unaware of the examples in the installation directory.

Unfortunately I don't have any of the TPS code I had written, I removed it when I wrote my own driver, but I will take time in the next couple of days to use the TPS driver and follow the examples to see if that changes anything.  I will update here with my results.

Thanks,

David

Hi,

I took a look at the example you referenced, and have configured my system to use spi1 in compatibility mode. using data format 0 with the appropriate delays.  It is worth noting that I also use the spi to communicate with an io expander chip, which works OK. 

I wanted to take it in baby steps, so I tried setting up the initialization structure, sending it through the TPS_DriverInit function, and then reading the device information through TPS_GetDeviceInformation.

However, I never return from TPS_DriverInit.

In sys_main.c I initialize spi, then call a function which does the following (should be almost identical to the example)

 /*initialize TPS driver*/
    initstruct.AMUXVoltageRailLimits = TPS65381Q_VoltageLimits;
    initstruct.GetTPSDiagPinSampledValue = NULL;
    initstruct.blNRES_Monitoring = TRUE;
    initstruct.blbist_at_startup = TRUE;
    initstruct.blenable_drv_op = TRUE;
    initstruct.blerror_pin_monitoring = FALSE;
    initstruct.blignition_power_latch = FALSE;
    initstruct.blsafe_state_timeout = TRUE;
    initstruct.dev_configreg_settings.blMASK_VBAT_OV = TRUE;
    initstruct.dev_configreg_settings.blMASK_VDD1_UV = TRUE;
    initstruct.dev_configreg_settings.blPOST_RUN_RST = TRUE;
    initstruct.dev_configreg_settings.blVDD3_5_OT = TRUE;
    initstruct.dev_configreg_settings.blVDD5_OT = TRUE;
    initstruct.error_pin_monitoring_mode = ERROR_PIN_MODE;
    initstruct.error_pin_pwm_width.u8PWM_HIGH = 8;
    /* the min error pin low dyuration in 204.8 us*/
    initstruct.error_pin_pwm_width.u8PWM_LOW = 40;
    initstruct.send_recieve_data_TPS = sendAndRecieveDataTPS;
    initstruct.u8pwd_threshhold_value = 5;
    initstruct.u8safe_lock_threshhold = 5;
    /* timeout duration in 198 ns*/
    initstruct.u8safe_state_timeout_scaler = 4;


   result = TPS_DriverInit(&initstruct);
    TPS_GetDeviceInformation(&tps_device_information);

my sendAndRecieveDataTPS function is

bool sendAndRecieveDataTPS(const uint16* const u16TransmitData,const uint32 u32TransmitSize,volatile uint16* u16RecieveData,uint32 *u32RecieveSize)
{
    boolean blRetVal = TRUE;
    volatile uint32 temp_read;

    if(1U != u32TransmitSize)
    {
        blRetVal = FALSE;
    }
    else
    {

        (Spi_Param_Handle->SPI_TPS)->DAT1 = 0x04FE0000U | *u16TransmitData;
        while(((Spi_Param_Handle->SPI_TPS)->FLG & 0x100)!=0x100);
        *u16RecieveData = ((Spi_Param_Handle->SPI_TPS)->BUF);
        (Spi_Param_Handle->SPI_TPS)->FLG = 0x300;
        temp_read=(Spi_Param_Handle->SPI_TPS)->FLG;
        blRetVal = TRUE;
    }

    return blRetVal;
}




I have Spi_Param_Handle set up as

#define SPI_TPS_DEFAULTS { (spiBASE_t *)spiREG1, \
                           0, \
						 }

Hi David,

Sorry for the delay in replying to the post.

Just needed some more information to address this.

Can you try to use the source code provided with the Diagnostic library installation instead of the .lib and debug where in the API TPS_DriverInit execution is getting stuck.If you look at the API TPS_DriverInit there is only one loop 

while (TPS_DEVICE_DIAGNOSTIC != u8tps_device_state)
{
blRetVal = TPS_GetCurrentTPSDeviceState(&u8tps_device_state);
}

if the TPS device is is not in the diagnostic state then the API waits for the TPS to come to the diagnostic state.

Please note that the testing of the TPS driver has to be done using power on reset debug reset does not change the state of the TPS device. The initialization of the TPS device is possible only when the TPS device in the diagnostic state if the TPS is not in diagnostic state then the driver init API waits in a infinite loop.

we have to be very cautious when debugging TPS related features as debug reset does  not reset the TPS device.

Waiting for update from you

Regards

Manoj

Thanks for your response.  I will look today into using the source code instead of the .lib and report my findings.

If I understand correctly, the TPS device should start in the diagnostic state when power is applied, but if it changes to another state, then launching another debug session (even if it resets the target) will not put it back in to the diagnostic state, I need to do a full power on reset?

[Edit] It looks like the device is in state 0, not 0x7.  What do I need to do to get it to the diagnostic state?  All I am doing is turning on power, connecting CCS and downloading my program.

I may not be able to look at this again soon as I am no longer able to connect my xds200 emulator to my board.   When I try to test the connection I get an error.  I would say this is unrelated, but this is the second board I have had this error occur on when troubleshooting the TPS chip.

Yes your understanding is correct,you need to do a full power on reset.

Coming to the edited part

--------------------------------------

How do you know that the TPS is in state 0 not 0x7?

If you look at the init code in the example given it looks like below

if(TRUE == TPS_DriverInit(&initstruct))
{
blRetVal == TPS_SetMCUSoftwareDebugMode();
TPS_SendDebugText(INFO,(uint8*)"INIT_TEST PASS",0);
/*stays in diagnostic mode and disables watchdog reset
Init has to be called again after any call to SetMCUSoftwareDebugMode*/
if(TRUE == blRetVal)
{
TPS_SendDebugText(INFO,
(uint8*) "Setting DEBUG mode PASS", 0);
}
else
{
TPS_SendDebugText(INFO,
(uint8*) "Setting DEBUG mode FAIL", 0);
}
}

immediately after initializing the TPS I am calling an API TPS_SetMCUSoftwareDebugMode(),This API  sets appropriate registers in the TPS device which blocks the exit from the diagnostic state of the TPS device.So you should also have a similar code as part of your TPS initialization code and also do have a switch which connects the NRST pin of the TPS device to the MCU nPOR_RST?

By default the TPS device on power moves to the reset state and then moves to diagnostic state and stays there for 600 ms time (if TPS_SetMCUSoftwareDebugMode is not called) Please have a look at the Figure 5-17. Device Controller State Diagram to understand more on the TPS state transitions.You are not able to connect your debugger probably because TPS is resetting your mcu continously? you have to find what is causing a reset.

Let me know if my inputs help.

Regards

Manoj

How do you know that the TPS is in state 0 not 0x7?

DS - The code was stuck in an endless loop in TPS_DriverInit

    while (TPS_DEVICE_DIAGNOSTIC != u8tps_device_state)
    {
        blRetVal = TPS_GetCurrentTPSDeviceState(&u8tps_device_state);
    }

It was always returning 0 in u8tps_device_state.

If you look at the init code in the example given it looks like below

if(TRUE == TPS_DriverInit(&initstruct)) { blRetVal == TPS_SetMCUSoftwareDebugMode(); TPS_SendDebugText(INFO,(uint8*)"INIT_TEST PASS",0); /*stays in diagnostic mode and disables watchdog reset Init has to be called again after any call to SetMCUSoftwareDebugMode*/ if(TRUE == blRetVal) { TPS_SendDebugText(INFO, (uint8*) "Setting DEBUG mode PASS", 0); } else { TPS_SendDebugText(INFO, (uint8*) "Setting DEBUG mode FAIL", 0); } }

immediately after initializing the TPS I am calling an API TPS_SetMCUSoftwareDebugMode(),This API  sets appropriate registers in the TPS device which blocks the exit from the diagnostic state of the TPS device.So you should also have a similar code as part of your TPS initialization code and also do have a switch which connects the NRST pin of the TPS device to the MCU nPOR_RST?

DS - I have that in the initialization code, but never get there. The nReset pin is connected to nPORST of the MCU, but it is connected directly.  It sounds like you are saying there should be a physical switch in between them?

By default the TPS device on power moves to the reset state and then moves to diagnostic state and stays there for 600 ms time (if TPS_SetMCUSoftwareDebugMode is not called) Please have a look at the Figure 5-17. Device Controller State Diagram to understand more on the TPS state transitions.You are not able to connect your debugger probably because TPS is resetting your mcu continously? you have to find what is causing a reset.

DS - I will take a look at the state transitions.  I believe that is the reason that I can't connect to the MCU.  I will investigate further, but probably won't be able to try anything new for a few days or a week. 

Thank you for all of your help,

David

How do you know that the TPS is in state 0 not 0x7?

DS - The code was stuck in an endless loop in TPS_DriverInit

    while (TPS_DEVICE_DIAGNOSTIC != u8tps_device_state)
    {
        blRetVal = TPS_GetCurrentTPSDeviceState(&u8tps_device_state);
    }

It was always returning 0 in u8tps_device_state.

Manoj: Then you are right.TPS is not in diagnostic state.

If you look at the init code in the example given it looks like below

if(TRUE == TPS_DriverInit(&initstruct)) { blRetVal == TPS_SetMCUSoftwareDebugMode(); TPS_SendDebugText(INFO,(uint8*)"INIT_TEST PASS",0); /*stays in diagnostic mode and disables watchdog reset Init has to be called again after any call to SetMCUSoftwareDebugMode*/ if(TRUE == blRetVal) { TPS_SendDebugText(INFO, (uint8*) "Setting DEBUG mode PASS", 0); } else { TPS_SendDebugText(INFO, (uint8*) "Setting DEBUG mode FAIL", 0); } }

immediately after initializing the TPS I am calling an API TPS_SetMCUSoftwareDebugMode(),This API  sets appropriate registers in the TPS device which blocks the exit from the diagnostic state of the TPS device.So you should also have a similar code as part of your TPS initialization code and also do have a switch which connects the NRST pin of the TPS device to the MCU nPOR_RST?

DS - I have that in the initialization code, but never get there. The nReset pin is connected to nPORST of the MCU, but it is connected directly.  It sounds like you are saying there should be a physical switch in between them?

Manoj: Yes a physical switch makes sense during developmental phase as it helps you in debugging.Can you have a look at this schematic http://processors.wiki.ti.com/images/b/b4/RM46_CNCD_Schematic.pdf  and make sure that the interfacing you have done to TPS device is appropriate.You can use this scematic and verify your interfacing with the TPS device.

By default the TPS device on power moves to the reset state and then moves to diagnostic state and stays there for 600 ms time (if TPS_SetMCUSoftwareDebugMode is not called) Please have a look at the Figure 5-17. Device Controller State Diagram to understand more on the TPS state transitions.You are not able to connect your debugger probably because TPS is resetting your mcu continously? you have to find what is causing a reset.

DS - I will take a look at the state transitions.  I believe that is the reason that I can't connect to the MCU.  I will investigate further, but probably won't be able to try anything new for a few days or a week. 

Manoj: This week its vacation here from tommorrow so I will not be available till monday.Let me know if you need more help today I will be available.

Regards

Manoj

Hi,

After going off and working on some other items I am back at looking at the TPS driver and I have a follow up question:

If the TPS chip automatically goes to the diagnostic state and after 600 ms transitions, how am I going to be able to send code to keep it in the diag mode but sending that function?  The time it takes to give the board power, load a program and run it is at least a minute, so I don't understand how that works.

Also, if (when) the watchdog fails, how would I be able to tell?

 [EDIT] I have been debugging the TPS driver.  I find myself in an infinite loop in the function TPS_DriverInit

    /*wait for the device to be diagnostic state*/
    while (TPS_DEVICE_DIAGNOSTIC != u8tps_device_state)
    {
        blRetVal = TPS_GetCurrentTPSDeviceState(&u8tps_device_state);
    }

The first couple of loops through the device state is 0 (standby) and then it reads 0x5 (Active).  It is as if it is skipping the diagnostic state completely.  It seems to then stay in the active state, even though it is stuck in the while loop so there is no refreshing of the watchdog.

Thanks for your help.  Developing / interfacing with this chip has proven to be very difficult, even with the examples and driver.

David

Hi David,

I saw your other two posts raised on the same issue  being deleted, Are you still facing issues.Let me know if you were able to resolve?

Regards

Manoj

Hi Manoj,

So, a few things:

1) My system has a couple of boards that are connected together.  I found when one board is connected to the other it is stuck in the standby state, if I run it on its own it behaves as  I expect (goes into the diagnostic state),  I suspect there is some signal holding the TPS chip in standby, but I haven't had a chance to track it down yet.

2) I don't fully understand what should happen if the watchdog isn't refreshed and how I can test this aside from initializing the watchdog and just never sending answers.  Does it signal the reset line? Does it turn off the voltage regulators?  Can the voltage regulators be turned off through the TPS registers?

3) I have run the example for the tms 1227 and it seems to run OK, which is very encouraging, I hadn't been able to get that far before.  The example has a state machine in main() and then once it gets to the point where the watchdog is active it uses an rti interrupt to handle sending answers over the spi and then modifies the compare time so it gets tripped in the open / close window.  For my application, I would really like to run this from only the task level.  I have several other tasks that are running (I am using freeRTOS on some boards and uc-os ii on another).  The task based example I found from spna176a does not use the TPS lib, it uses functions pre-fiexed with ecmp, but it more closely follows the architecture I would like to use, but I am having some trouble translating between the functions they call and the functions in the TPS driver lib.  Is there any reason using rti is better than purely task based?

4) If I am debugging in general, not necessarily TPS, but I am setting breakpoints, do I need to not start the TPS watchdog so it doesn't interfere with debugging?

Thanks for your help,

David

Thanks for all of your help.  I think I have a good enough understanding I should be able to get it working.

If I run into any other issues I will start a new thread.

Thanks,

David