• State TI Thinks Resolved
  • Locked Locked
  • Replies 1 reply
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 847 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CCS/TPS65381A-Q1: TPS65381A-Q1: TMS570LC4357 spi example code

sanghun han
Prodigy 10 points
Part Number: TPS65381A-Q1
Other Parts Discussed in Thread: TMS570LC4357, , HALCOGEN, TMS570LS1227, TMS570LS3137

Tool/software: Code Composer Studio

Hello.
I am trying to reset TMS570LC4357 using TPS65381A-Q1.
Do I have examples of SPIs for TMS570LC4357 and TPS65381A-Q1?
If there is a similar example, I would like to share it.

  • 0
    TI__Guru**** 196306 points

    Hello Sanghun,

    There are several board specific sample applications are bundled with the TPS65381 Driver to demonstrate the use of the driver APIs.

    The project relies on HALCoGen to provide the system initialization and application framework. The project can be imported using the File -> Import -> Existing CCS Eclipse Project and pointing it to the particular build folder in:

    C:\ti\Hercules\SafeTI Diagnostic Library\2.4.0\build\TMS570LS1227_CNCD

    or

    C:\ti\Hercules\SafeTI Diagnostic Library\2.4.0\build\TMS570LS3137_HitexKit

    depending on the board. This may then be built and run on the specified target board. The application cannot be run with the debugger connected.

    In the main() function, several TPS APIs are tested. The Testing is done in various phases:

    1.In the First phase - TEST_BASIC_SETTINGS - TPS is kept in diagnostic state.

    • TPS is initialized using the TPS_DriverInit.
    • TPS is set to MCU debug mode using TPS_SetMCUSoftwareDebugMode to stay in diagnostic state.
    • Verification of the current state of TPS is done.
    • AMUX/DMUX diagnostics is tested.
    • Interface tests are done so as to verify the TPS interface API.
    • CRC and Fault injection CRC tests are performed.
    • VMON status API and Error monitoring API are tested.
    • The next phase is testing of the Watchdog functionality - TEST_WD_DIAGMODE

    2.In phase - TEST_WD_DIAGMODE(Testing of Watchdog in Diagnostic mode of TPS)

    • Watchdog servicing is tested.
    • Behavior of ENDRV pin is verified.
    • RTI module of the MCU is used so as to respond to TPS watchdog at appropriate times.
    • The next phase is TEST_WDDIAG_ERRORS

    3.In Phase - TEST_WDDIAG_ERRORS(Testing of Watchdog errors in DIAGNOSTIC mode of TPS)◦Various error scenarios of the watchdog are verified.

    • Fault injection watchdog API is verified.
    • Behavior of ENDRV is verified.
    • RTI module of the MCU is used so as to respond to TPS watchdog at appropriate times.
    • Next phase is TEST_WD_ACTMODE(Testing of the watchdog servicing in the ACTIVE mode of TPS)

    4.In Phase - TEST_WD_ACTMODE◦The diagnostic mode is exited.

    • It is verified that the TPS is is in ACTIVE MODE.
    • All other operations or tests are similar to TEST_WDACT_ERRORS.The next state is TEST_WDACT_ERRORS.

    5.In the phase- TEST_WDACT_ERRORS(Testing of the watchdog errors in ACTIVE mode of the TPS)

    • The operations/tests performed are same as TEST_WDDIAG_ERRORS except that the tests are performed when the TPS is active mode.
    • The next state is changed to TEST_WD_ACTMODE and this is the final state TPS watchdog is serviced with Watchodg answers at right time.