This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

USB interface in light switch client implemented for nrf-dongle gives mesh assert upon receiving data on USB

Using 

SW : NRF_SDK_16, SDK_MESH_v4.0

HW:  NRF52840 DONGLE.

I have implemented light_switch_client which also has USB part initialization and then added in USB_DONGLE. I have followed below mentioned guide for the necessary changes while loading the code in dongle

https://devzone.nordicsemi.com/nordic/short-range-guides/b/getting-started/posts/nrf52840-dongle-programming-tutorial

Now my PC detects Dongle as one of the USB ports.All I want to do is send the data from serial terminal on detected USB PORT and then publish it over the mesh.

Issue as below :-

I am getting app_error_weak.c,  105, Mesh assert at 0x0002C8FA (:0) upon trying to publish the received data over mesh.

1.I think this issue is related to interrupt priority of USB and MESH. Mesh uses NRF_MESH_IRQ_PRIORITY_LOWEST where as USB uses NRFX_USBD_CONFIG_IRQ_PRIORITY 6  as a interrupt priority levels.

Please see the attached code for the reference

        case APP_USBD_CDC_ACM_USER_EVT_RX_DONE:
        {
            
            index++;
            do
            {
              if(m_cdc_data_array[index-1]==0xFA && m_cdc_data_array[index-2]==0x5F)
             {
                __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "ready to publish\n");
                app_onoff_status_publish(&m_onoff_server_0); // publishing the data here which causes the error
                index=0;
                memset(m_cdc_data_array,0,sizeof(m_cdc_data_array));
             }
            



              ret = app_usbd_cdc_acm_read(&m_app_cdc_acm,
                                         &m_cdc_data_array[index],
                                         1);
              if (ret == NRF_SUCCESS)
              {
                    index++;
              }
             __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "--index=%d-----\n",index);
             __LOG_XB(LOG_SRC_APP, LOG_LEVEL_INFO,"RX: Msg : Received", m_cdc_data_array,index);

            }while(ret == NRF_SUCCESS);

Parents
  • Hi,

    Interrupt levels may be a reason for the assert, yes. There is a chapter of the nRF5 SDK for Mesh documentation dedicated to setting interrupt priority levels. There could also be some relevant information in the Integrating Mesh into nRF5 SDK examples section.

    I also notice that you have a do while loop inside of what looks to be an event handler, is that correct? Depending on what interrupt context the event is handled in, you may want to use the Schedule handing library or similar technique for doing the time consuming work triggered by the event, in order not to block high priority tasks.

    Regarding the use of app_onoff_status_publish(), I see that the API documentation states that "This API should never be called from transition callback", although I am not sure what is the reason for that. Interrupt context related issues may be part of it.

    For further analysis, it would be great to know exactly where the assert is happening. You can for instance do a debug session with breakpoint in app_error_weak() then have a look at the call stack, or you can use an utility such as addr2line to figure out what line of code corresponds to 0x0002C8FA as reported from the log message.

    Regards,
    Terje

Reply
  • Hi,

    Interrupt levels may be a reason for the assert, yes. There is a chapter of the nRF5 SDK for Mesh documentation dedicated to setting interrupt priority levels. There could also be some relevant information in the Integrating Mesh into nRF5 SDK examples section.

    I also notice that you have a do while loop inside of what looks to be an event handler, is that correct? Depending on what interrupt context the event is handled in, you may want to use the Schedule handing library or similar technique for doing the time consuming work triggered by the event, in order not to block high priority tasks.

    Regarding the use of app_onoff_status_publish(), I see that the API documentation states that "This API should never be called from transition callback", although I am not sure what is the reason for that. Interrupt context related issues may be part of it.

    For further analysis, it would be great to know exactly where the assert is happening. You can for instance do a debug session with breakpoint in app_error_weak() then have a look at the call stack, or you can use an utility such as addr2line to figure out what line of code corresponds to 0x0002C8FA as reported from the log message.

    Regards,
    Terje

Children
No Data
Related