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/TMS570LC4357: Safety Library HALCOGEN Example do not start Selftest of CAN Controller

Part Number: TMS570LC4357
Other Parts Discussed in Thread: HALCOGEN

Tool/software: Code Composer Studio

Hi together, I have some trouble with the sfety lib example from halcogen.

I followed the instructions and get a correct build. After I load it to the mcu, my programm starts. But after the programm try to start the self test of the first CAN-Controller, it gets a negative Response from the function calls and ends in the following while(1) instruction.  

         if(SL_SelfTest_CAN(CAN_ECC_TEST_MODE_1BIT, SL_DCAN1) == false)
         {
          while(1);    // here the progamm ends

}

I had a look into the function and figuered out, what is the Problem. The function is defined in sl_selftest.c. There the programm checks, if the INIT-BIT in the CANREG1->CTL Register is set. If it is, then the function Returns false. In my case, the bit is set, so I end in the while(1) instruction above.

  if((boolean)sl_canREG)
    {
        /*SAFETYMCUSW 134 S MR: 12.2 <APPROVED> Comment_5*/
     if ((uint32)CAN_INIT_BIT == (sl_canREG->CTL & CAN_INIT_BIT)) {
            SL_Log_Error(FUNC_ID_ST_CAN, ERR_TYPE_ENTRY_CON, 3u);
            retVal =  FALSE;
            return retVal;
        }

The Problem is, that the bit is always set after a restart of the mcu. And there is no instruction in before, which will reset the bit. There is a function before, which shoul initilize the CAN_RAM.

SL_Init_Memory( RAMTYPE_DMA_RAM     |
          RAMTYPE_NHET1       |
          RAMTYPE_HET_TU1     |
          RAMTYPE_NHET2       |
          RAMTYPE_HET_TU2     |
          RAMTYPE_DCAN1_RAM   |
          RAMTYPE_DCAN2_RAM   |
          RAMTYPE_DCAN3_RAM   |
          RAMTYPE_DCAN4_RAM   |
                   RAMTYPE_MIBSPI1_RAM |
                   RAMTYPE_MIBSPI2_RAM |
                   RAMTYPE_MIBSPI3_RAM |
                   RAMTYPE_MIBSPI4_RAM |
                   RAMTYPE_MIBSPI5_RAM |
                   RAMTYPE_MIBADC1_RAM |
                   RAMTYPE_MIBADC2_RAM );

But this function do not clear the Control Register of the CAN-Module. So I added 4 extra lines, where I manually reset the bits for all CAN-REGs, before I start with the self test.

 canREG1->CTL =(0 << 0);
 canREG2->CTL =(0 << 0);
 canREG3->CTL =(0 << 0);
 canREG4->CTL =(0 << 0);

After this add, my programm runs without any Problems. I don't know, if it is the right way. Can somebody confirm it, please?

In my opinion, the test of the bit have a special reason, which I do not know and I manupulate the programm, which is not a good kind. So maybe sth. is wrong with my Settings? Or why the bit is always set, when I start the selftest function?

Thanks very much in advance.

  

  • Hello,

    You are right that the init bit should be cleared before any kind of selftest. I checked the main() function, the canInit() is called before calling SL_SelfTest_CAN(..), so the init bit should be cleared. Please double check if the canInit() is called.

    Regards,
    QJ
  • Hello QJ, thanks for your feedback.

    I use the sys_startup file from the safety lib example of HALCOGEN, so the selftest function is called in the sys_startup before the main. Of Course I call canInit() in main, but thats too late for the selftest in sys_startup. In sys_startup the init function is not called, this is why I used my Workaround above. I can also use the canInit() instruction in sys_startup, this also runs (so thanks for the hint), but only if I enable ECC-RAM for all CANs(1-4). By Default it is disabled in HALCOGEN.

    It wonder me, that such a Basic example doesn't work. I followed the instruction in the HALCOGEN example, but as you can see, it doesn't work without some additions. In my opinion, the documentation or the files in the HALCOGEN Examples are not complete or I'm not smart enough to handle it ;) Or maybe it is a problem of different SW Versions. I use HALCOGEN 4.06.01 and CCS 6.2.

    Another problem I recognized with this safety lib example from HALCOGEN is, that I sometimes get a nERROR Flag, when I Flash a new Programm Code to the mcu. It seems to be, that the Debugger causes a CCM Failure, while start Connection to the MCU. After loading the Programm to the MCU the nERROR Flag is not reseted. This Flag will be only reseted after PORRST, if I trust the TRM. So I think, the Debugger do not make a PORRST, only a debug reset and this is why, the Flag is still activ, right? It's a Little bit similar to the errata DEVICE#56, but I have other esm channels activated than in the errata described.
    In this case, my the selftest functions (for example sl_selftest_PBIST(...)) also do not start, because they check the nERROR Flag.
    Therefore I used another workaround and clear the esm everytime after PORRST, DEBUG and Ext Reset with:

    SL_Set_nERROR();
    SL_Clear_nERROR();
    while(SL_ESM_nERROR_Active()==true);

    Then the Flag is reseted and the program runs well. Is this wokaround okay, or should I be careful with resetting the esm?

    I wonder me, why nobody else have the same Problems.

    Thanks in advance.

    Regards
    Marcus