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.

AWR1843AOP: In the MRR Lab how is the CAN Bus off condition handled

Part Number: AWR1843AOP

Tool/software:

Hi,

I am trying to interface the AWR1843AOP radar with my ECU, and both are communicating via CAN at 500 kbps.

I am experiencing software crashes in the DSS core at this line:

MmwDemo_dssAssert(dataPathObj->chirpCount != 0);

Both systems work fine as standalone units and also as an integrated system during lab testing. However, we are encountering crashes during field testing.

Upon closer inspection, I found that the CAN sampling point for the radar is set to 75%, while it is 72.22% for the ECU. I have read that:

If the sampling points between two CAN nodes differ slightly, such as one at 75% and the other at 72.22%, communication may still function under low bus loads and ideal conditions. However, as bus traffic increases (as in our case during field testing), the sampling point mismatch can cause frequent misinterpretation of bits. Nodes will then generate error frames to indicate a problem, which increases bus load and can potentially lead to bus-off conditions for nodes with recurring errors.

I wanted to check:

  1. How is the bus-off condition handled in such scenarios?
  2. Could a bus-off condition cause crashes on the DSS side?
  • Hi,

    Let us get back to you on this by next week

  • Hello Tanoop,

    1) Bus off condition can be checked if the TEC is crossing 255, then only the busoff. You can monitor the MCAN_PSR.BO for the Busoff bit.
    I found an example implementation of handling:

    Can_bussoff_recovery (1).c
    /*
     *   @file  Can_bussoff_recovery.c
     *
     *   @brief
     *      This file holds recovery function for CAN Bus off recovery
     *
     *  \par
     *  NOTE:
     *      (C) Copyright 2020 Texas Instruments, Inc.
     *
     *  Redistribution and use in source and binary forms, with or without
     *  modification, are permitted provided that the following conditions
     *  are met:
     *
     *    Redistributions of source code must retain the above copyright
     *    notice, this list of conditions and the following disclaimer.
     *
     *    Redistributions in binary form must reproduce the above copyright
     *    notice, this list of conditions and the following disclaimer in the
     *    documentation and/or other materials provided with the
     *    distribution.
     *
     *    Neither the name of Texas Instruments Incorporated nor the names of
     *    its contributors may be used to endorse or promote products derived
     *    from this software without specific prior written permission.
     *
     *  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
     *  "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
     *  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
     *  A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
     *  OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
     *  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
     *  LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
     *  DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
     *  THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
     *  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
     *  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
     */
    
    
    CAN BUSOFF recovery function listed below, you need to rebuild the CANFD driver after you add it to the CANFD lib.
    How to rebuild CANFD lib: 
    1.        Open CMD,cd C:\ti\mmwave_sdk_03_05_00_04\packages\ti\drivers\canfd 
    2.        Call “C:\ti\mmwave_sdk_03_05_00_04\packages\scripts\windows\setenv.bat”  with enter 
    3.        Call ”C:\ti\mmwave_sdk_03_05_00_04\packages\scripts\windows\checkenv.bat”   with enter
    4.        gmake all   with enter
     
      
    ----Add function CANFD_BusOffRecovery  in canfd.c 
    int32_t  CANFD_BusOffRecovery(CANFD_Handle handle,  int32_t* errCode) 
    { 
       CANFD_DriverMCB*                ptrCanFdMCB; 
       uint32_t                        baseAddr; 
        int32_t                         retVal = 0; 
         
       ptrCanFdMCB = (CANFD_DriverMCB*)handle; 
       if ((ptrCanFdMCB == NULL) ) 
       { 
           *errCode = CANFD_EINVAL; 
           retVal = MINUS_ONE; 
           
       } 
       
       baseAddr = ptrCanFdMCB->hwCfg.regBaseAddress; 
       /*Check if the busoff status and also the Error counter*/ 
       
       /* Put MCAN in opertional mode */ 
       MCAN_setOpMode(baseAddr, CANFD_MCANOperationMode_NORMAL); 
     
       /* Wait while MCAN is not in operational mode. TODO add timeout */ 
       do 
       { 
       } while (MCAN_getOpMode(baseAddr) != CANFD_MCANOperationMode_NORMAL); 
       
       return retVal; 
    } 
    	
    	 
    ----Add function in main.c 
    static void MCANAppErrStatusCallback(CANFD_Handle handle, CANFD_Reason reason, CANFD_ErrStatusResp* errStatusResp) 
    { 
       int32_t                 errCode; 
       gErrStatusInt++; 
       gErrorReason = reason; 
     
    	 
    		// check the callback reason
    		// you can also adding CANFD_transmitDataCancel here to avoid TX to cause busoff
    		
    		   /*Try Busoff recovery*/ 
    		   CANFD_BusOffRecovery(handle, &errCode); 
    		       
    		   return; 
    		}
    

    2) If you are not handling busoff I don't think it would cause this issue.
    This means that processing was not done for the last frame, did you get the object then? You can try relaxing the frame timings a little and observing as well.
    If you think it is because of the mismatch, you could also try to match the exact timings on your end.

    Regards,
    Saswat Kumar