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.

RTOS/LAUNCHXL-CC1310: TI15.4 Stack - Coprocessor is going to assert every second run

Part Number: LAUNCHXL-CC1310
Other Parts Discussed in Thread: CC1310

Tool/software: TI-RTOS

Hello,

I'm playing with the newest versions of Coprocessor example (3.10.00.11) and linux gateway SDK - collector example (2.09.00.09). I'm running coprocessor on CC1310 Launchpad, debugging it via another Launchpad and running Linux Mint in Virtualbox where I'm using it as Coprocessor for Collector example.

Examples are clean as downloaded, only configured to use EU frequencies.

When I start the collector app first time, all is working as expected. When I kill it (CTRL+C) and start it again, it always goes into xdc_Void Main_excHandler on the coprocessor. 

Is this right? I was tried to debug it, but it seems assert source is somewhere in linked library.

Thanks,

JC

  • Hi,

    could you enable logging in the linux collector in collector.cfg "flag = everything" and share the logs

    Also, have you tested this with other versions of the SDK or only with 3.10.00.11 together with Linux SDK 2.09.00.09?
  • Hi, attached are logs. First run is OK, during second run there is reset. It is also indicated in the log, that there was rtos-assert reset.

    I tested also Linux SDK v. 2_08_00_04. The same behavior.

    collector_log_firstRun.txt

    collector_log_secondRun.txt

  • Hi,

    I believe this is happening because the collector application in the linux side does not reset the coprocessor at initialization, therefore when you restart the collector application it assumes the coprocesor is not initialized and it tries to initialize it again which seems to be causing something to assert in the coprocessor side and triggering a reset.

    I haven't been able to test this theory to confirm that this is the root cause but I will give you some code changes that you can add to test this out.

    Also, I found another bug looking into this. See code changes below.

    In file mt_msg.c go to the function void MT_MSG_reset(struct mt_msg_interface *pIface, int type)

    void MT_MSG_reset(struct mt_msg_interface *pIface, int type)
    {
        struct mt_msg *pMsg;
        int r;
    
        /* allocate the message */
        pMsg = MT_MSG_alloc(1, 0x41, 0x00); //[MODIFIED] Replaced (1, 0x21, 0x01) with (1, 0x41, 0x00)
        if(pMsg == NULL)
        {
            return;
        }
    
    ...

    To reset the coprocessor every time you start the Collector application modify code below:

    In the file api_mac.c go to the function void *ApiMac_init(bool enableFH)

    void *ApiMac_init(bool enableFH)
    {
        int r;
        bool b;
    
        MT_MSG_init();
    
        if( API_MAC_msg_interface == NULL )
        {
            BUG_HERE("msg interface not specified(NULL)\n");
        }
    
        r = MT_MSG_interfaceCreate(API_MAC_msg_interface);
        if(r != 0)
        {
            FATAL_printf("Cannot init interface (%d)\n", r);
        }
    
        /*[MODIFIED] Add Line of code below to reset device*/
        r = MT_MSG_reset(API_MAC_msg_interface, 1); //ADD this line of code
    // If this doesnt work properly you might need to call "TIMER_sleep(uint32_t nMsecs);" to sleep for a few milliseconds to allow the coprocessor to reset
        
        memset( (void *)(&MT_DEVICE_version_info), 0, sizeof(MT_DEVICE_version_info) );
        r = MT_MSG_getVersion( API_MAC_msg_interface, &MT_DEVICE_version_info );
    
      ...
    

    I am currently working on submitting tickets to get this properly fixed.

    Thanks for reporting this issue!

  • Hi, I modified linux source according to your suggestion, but it does not solve the issue. See attached logs.

    collector_log_firstRunModified.txt

    collector_log_secondRunModified.txt

  • from the logs it seems like you didnt modify the function "void MT_MSG_reset(struct mt_msg_interface *pIface, int type)" correctly

    it looks like you are using

    pMsg = MT_MSG_alloc(1, 0x41, 0x01);

    instead of

    pMsg = MT_MSG_alloc(1, 0x41, 0x00);

  • You are right, sorry for this stupid mistake. Now it works. FYI in my case both code changes are needed and there is needed 50ms delay after reset.
  • Thanks for the feedback. I already submitted a ticket for this to be fixed in the next release of the linux SDK.

    Thanks!