Banner_AURIX_Security-Solution Banner_AURIX_Safety_Products ShieldBuddy TC275 Banner_AURIX_OnzerOS


infineon4engi@twitter twitter

infineon4engineers Facebook

infineon@linkedin linkedin

infineon@youtube youtube


+ Reply to Thread
Results 1 to 6 of 6
  1. #1
    New Member New Member Macro is on a distinguished road
    Join Date
    Oct 2019
    Posts
    3
    Points
    40

    SMU Configuration Steps

    Hi,

    Can someone help me checking if it`s correct to config the SMU by following 2 steps:

    1. Config the Alarm Configuration Register Group: SMU_AGxCFy(x=0~6, y=0~2)
    2. Start the SMU by set SMU_CMD.CMD = 0(=SMU_Start), SMU_CMD.ARG = 0

    I`m not sure if there is some step missing or wrong. Please guide me.


    Thank you in advance.

  2. #2
    Advanced Advanced UC_wrangler is on a distinguished road
    Join Date
    Jun 2019
    Posts
    41
    Points
    865
    Hi Macro. You should probably add configuring the FSP output to your list, and locking the SMU registers. Here's a more complete example.
    Code:
       _endinit_clear();			// Pad Driver Mode registers are endinit protected
       P33_PDR1.B.PD8 = 0;			// enable strong driver for the SMU output (default is weak)
       _endinit_set();
    
       P33_OUT.B.P8 = 1;			// set P33.8 output high (inactive)
       P33_IOCR8.B.PC8 = 0x10;		// P33.8 push-pull output
    
       _safety_endinit_clear();		// SMU registers are safety endinit protected
       SMU_KEYS.B.CFGLCK = 0xBC;	// unlock SMU configuration registers
       SMU_PCTL.U = 0x83;			// enable SMU fault output (causes P33.8 transition)
    
       SMU_FSP.B.MODE = 0;     		// Fault Signaling Protocol configuration: 0=Bi-stable protocol
    
       SMU_AG3FSP.U = 0x40000000;    	// enable ALM3[30]
    
       // set ALM3[30] to 101b (SMU_NMI)
       SMU_AG3CF0.U = 0x40000000;
       SMU_AG3CF1.U = 0x00000000;
       SMU_AG3CF2.U = 0x40000000;
    
       SMU_KEYS.B.CFGLCK = 0x00;	// lock SMU configuration registers
    
       // Permanently lock SMU configuration registers
       // - If you enable this, you can't use ReleaseFSP - the only way to get the SMU running again is through a reset.
       //SMU_KEYS.B.PERLCK = 0xFF;
    
       _safety_endinit_set();		// end SMU configuration - safety endinit protected
    
       _endinit_clear();			// SCU NMI trap configuration is endinit protected
       SCU_TRAPDIS.B.SMUT = 0;      // enable SMU NMI trap generation
       _endinit_set();
    
       // Here the SMU is in the START state
       // Deactivate the fault output with SMU_ReleaseFSP
       //
       SMU_CMD.U = 0x2;				// ARG=0, CMD=2: SMU_ReleaseFSP(0)
    
       // The SMU_Start command causes a transition from START to RUN
       //
       SMU_CMD.U = 0;    			// ARG=0, CMD=0: SMU_Start(0)
    Last edited by UC_wrangler; Oct 22nd, 2019 at 09:26 AM.

  3. #3
    New Member New Member Macro is on a distinguished road
    Join Date
    Oct 2019
    Posts
    3
    Points
    40
    Hi wrangler,

    Thanks for your great help.

    Actually in my project the FSP is not available as it was used as GPIO for other purpose and the HW can not be changed, so I need to implement it in another way.

    From the Table 9-24 SMU Alarm Configuration, there`re 6 options for each Alarm can be chosen:
    0x2 - SMU_IGCS0
    0x3 - SMU_IGCS1
    0x4 - SMU_IGCS2
    0x5 - SMU_NMI
    0x6 - SMU_RESET
    0x7 - SMU_IDLE

    If we want to handle the SMU Alarm in application layer, how it interact with application SW ?
    I`m thinking get the alarm info from ISR as the config 0x2~0x5 would route a interrupt to IR module,
    but seems it`s not be able to distinguish which Alarm was set.

    From the tc27x User Manual, I can not get a clear picture for the alarm handling, do you have any suggestion ?

    Thank you sincerely.

  4. #4
    Advanced Advanced UC_wrangler is on a distinguished road
    Join Date
    Jun 2019
    Posts
    41
    Points
    865
    Hi Macro. I recommend using SMU_NMI for the alarms your application deems critical. Non-Maskable Interrupts are handled by the CPU trap system, not the interrupt system. NMIs cannot be disabled, and all CPUs will receive the NMI trap at the same time.

    If you use a CPU interrupt, your application might be disabling interrupts, or have CCPN set so that the SMU interrupt is not handled quickly enough.

    It's simplest to handle SMU alarms as a one-way trip. Generally, the NMI handler should:
    • Set the system to a safe state, which means microseconds, not seconds. Examples include: disable a bridge driver (stop driving a motor), disable a CAN transceiver (so you don't send out an incorrect message), etc.
    • Save context information into RAM somewhere. This can include which alarm was triggered (by reading SMU_ADx), but can also include where the CPU was executing (A11), and possible task-level information as well. If your handler needs a little more time, be sure to extend the watchdog recovery timers, or a reset will occur.
    • Remember that all CPUs get an NMI trap simultaneously, so don't write over the same saved context with each CPU.
    • Reset the system with a reset request (SWRSTCON.SWRSTREQ=1).
    • Note that the watchdog recovery timer alarms should be left at SMU_RESET, in case the CPUs fail to respond to the NMI. This covers the case where the CPU has mangled its BTV trap vector table, run out of context save areas, etc.
    Trying to recover from an SMU alarm without doing a reset quickly becomes complicated. For example, consider what happens if a double-bit fault occurs in DSPR, resulting in an uncorrectable ECC trap when reading from that location. The NMI handler could simply write a 0 to that location, which would probably clear the ECC error, and continue. But the value at that location probably wasn't a 0 - how do you restart the software components that relied on that value? You'd have to map out a failure strategy for every variable your program uses, which spirals into a vast ocean of fault handling.
    Last edited by UC_wrangler; Oct 23rd, 2019 at 09:40 AM.

  5. #5
    New Member New Member Macro is on a distinguished road
    Join Date
    Oct 2019
    Posts
    3
    Points
    40
    Hi wrangler,

    Thank you again for your great help.

    Now I`m trying to config the SMU in my project.

    Do we have the training doc/example code for all hardware diagnostic mechanism which are under SMU handling?
    since no much useful info can be found from Infineon website/forum..

  6. #6
    Advanced Advanced UC_wrangler is on a distinguished road
    Join Date
    Jun 2019
    Posts
    41
    Points
    865
    Hi Macro. For any application using the SMU, the AURIX Safety Manual is a vital guide: it describes all the hardware safety mechanisms, as well as the Assumptions of Use that your application needs to address.

    For the TC2xx generation, Infineon's SafeTlib software library ensures there are no latent faults within the safety mechanisms. For example, it injects a lockstep comparator error, and verifies that the SMU asserts the lockstep comparator alarm. SafeTlib requires a software license.

    For the TC3xx generation, the addition of the Logic Built-In Self Test (LBIST) makes development much simpler: your application simply needs to make sure the 32-bit signature result of the LBIST matches the expected value.

Tags for this Thread

Disclaimer

All content and materials on this site are provided “as is“. Infineon makes no warranties or representations with regard to this content and these materials of any kind, whether express or implied, including without limitation, warranties or representations of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, whether express or implied, is granted by Infineon. Use of the information on this site may require a license from a third party, or a license from Infineon.


Infineon accepts no liability for the content and materials on this site being accurate, complete or up- to-date or for the contents of external links. Infineon distances itself expressly from the contents of the linked pages, over the structure of which Infineon has no control.


Content on this site may contain or be subject to specific guidelines or limitations on use. All postings and use of the content on this site are subject to the Usage Terms of the site; third parties using this content agree to abide by any limitations or guidelines and to comply with the Usage Terms of this site. Infineon reserves the right to make corrections, deletions, modifications, enhancements, improvements and other changes to the content and materials, its products, programs and services at any time or to move or discontinue any content, products, programs, or services without notice.