NRF5340dk bluetooth notify fatal error

Hi , I'm using nrf5340 and nrf connect  sdk 1.5.1  , recently I found out when sending large amount of data with low RSSI through bt_gatt_notify_cb the system would enter some sort of fatal error and won't reset unless re-power .

Here's the scenario , with about -70dbm RSSI and average data rate  50kbyte/s the device would disconnect and become completely dead (Neither app core nor net core is working , won't reset unless re-power) . Normal power consumption is about 3.7V/ 10mA + , but when it's dead it drops to below 3.7/ 2mA , I assume nrf5340 cut down it's power supply in order to prevent such error damages the chip .

On net core we are using hci_rpmsg sample from  nrf connect  sdk 1.5.1 , with these additional settings in prj.conf :

CONFIG_BT_CTLR_TX_BUFFER_SIZE=251
CONFIG_BT_CTLR_DATA_LENGTH_MAX=251
CONFIG_BT_RX_BUF_LEN=255

On app core here are all bt settings in prj.conf:

CONFIG_BT=y
CONFIG_BT_DEBUG_LOG=y
CONFIG_BT_SMP=y
CONFIG_BT_PERIPHERAL=y

CONFIG_BT_RX_BUF_LEN=255
CONFIG_BT_GATT_CLIENT=y
CONFIG_BT_ATT_TX_MAX=10
CONFIG_BT_ATT_PREPARE_COUNT=2
CONFIG_BT_CONN_TX_MAX=10

CONFIG_BT_L2CAP_RX_MTU=247
CONFIG_BT_L2CAP_TX_MTU=247
CONFIG_BT_L2CAP_TX_BUF_COUNT=10
CONFIG_BT_L2CAP_DYNAMIC_CHANNEL=y

CONFIG_HEAP_MEM_POOL_SIZE=2048
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=2048

CONFIG_BT_SETTINGS=y
CONFIG_BT_DEVICE_NAME_DYNAMIC=y

CONFIG_BT_PERIPHERAL_PREF_MIN_INT=12
CONFIG_BT_PERIPHERAL_PREF_MAX_INT=12

I also tried only call bt_gatt_notify and k_sleep without calling any other function in a loop (which simulate a 50kbyte/s transmission , avoiding other parts of the system go wrong) , it still dies when RSSI drops below about -70dbm .

  • Hi Zheng, 

    It's more like an assertion to me. The reason you see the current consumption dropped was because the chip stopped sending /receiving data on the radio and only the CPU is running that's why it's around 2mA. 

    Have you checked the log to see if there is any information about the crash ? 
    Could you configure CONFIG_ASSERT=y so we have more info in the log ?

    Could you show how you send your data in your code ? 

    A sniffer trace would be useful to analyze what happens in the air. 

  • Hi

    Thanks for your suggestions.

    I already checked log and there's no information about the crash. 

    Debug mode isn't helpful either, since system stopped at different places thus breakpoints aren't always reachable.

    Here's abstraction of our codes sending the data.

      

        func1 (struct bt_conn *conn, const uint8_t *data, uint16_t len){
        const struct bt_gatt_attr *attr = &ble_collect_service.attrs[4]; 
    
        struct bt_gatt_notify_params params = 
            {
                .uuid   = BT_UUID_CLS_DATA,
                .attr   = attr,
                .data   = data,
                .len    = len,
                .func   = NULL
            };
        
        
            if(bt_gatt_is_subscribed(conn, attr, BT_GATT_CCC_NOTIFY)) 
            {
        	    if(bt_gatt_notify_cb(conn, &params))
                {
                    
                    return false; 
                }
                else
                {
                    return true;
                }
            }
            else
            {
                //printk("Notification not enabled\n");
                return false;  
            }
        }
        
        func2()
        {
        if (buffer_size >0){
        
            if(func1(parameters))
                {
                buffer_size -=1 ;
                pointer = (pointer +1)%max_size ;
                }
            
            }
        
        }
        
        
        
        
        main()
        {
        
        
        
            while(true){
            other functions filling the buffer 
            
            ...
            ...
            
            func2
            
            }
        
        }
        
        
        
        
        

    I will try out CONFIG_ASSERT=y and sniffer trace later, if there's anything new I will update it here .

  • Hi Zheng, 

    Please try to capture a sniffer trace. 

    If you run the device in debug mode and when the device "dies" , if you stop the debugger , which function the MCU is in ?  

    Do you have any delay in the main while loop in main() ? 

    Could you try testing using an example in the SDK  ?  peripheral_hr for example. 

    I have made a throughput test example here that you may want to try. 

Related