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

softdevice error code 0x0000000D1

Hi all

I am using S130 SDK12, nRF51822 

This is the error I am getting - line_num 0x07C0, p_file_name 0x06D1, error code 0x00D1, fault id 0x0001, pc 0x83CC (a print-screen from the debugger is also below)

The error occurred repeatedly in the same scenario

I added a notification characteristic to an existing custom service, and when the central subscribe to the notification and it is being sent the error occurs.

The error occurs only when I compile with optimization (I optimized to level 3)

The notification was sent (using sd_ble_gatts_hvx) from a function invoked by at timer interrupt (timer_timeouts_check()), so I changed it to be sent from the event scheduler, and this apparently resolved the issue, partly, I still wish to 

1. Understand what happened, to assure the problem or bug is not still hiding somewhere

2. Return to my original implementation simply because it saves me important flash memory. 

Would appreciate any help

Thanks

Parents
  • Hi,

     

    This is the error I am getting - line_num 0x07C0, p_file_name 0x06D1, error code 0x00D1, fault id 0x0001, pc 0x83CC (a print-screen from the debugger is also below)

    The pointers p_* are NULL, so the content is not valid as assertion info.

    The address of the assert, 0x83CC, is inside the softdevice flash area, and it is asserting on a check to see if you still have a connection.

      

    I added a notification characteristic to an existing custom service, and when the central subscribe to the notification and it is being sent the error occurs.

    The error occurs only when I compile with optimization (I optimized to level 3)

    The notification was sent (using sd_ble_gatts_hvx) from a function invoked by at timer interrupt (timer_timeouts_check()), so I changed it to be sent from the event scheduler, and this apparently resolved the issue, partly, I still wish to 

      The SoftDevice interrupt handler (SD_EVT_IRQn / SD_EVT_IRQHandler) runs in the lowest priority (APP_IRQ_PRIORITY_LOWEST), and if a disconnect event occurs while you're in the timer interrupt handler, it will be serviced after the timer is done. It looks like there's a race condition. Is it expected that you get disconnected in this scenario?

     

    Kind regards,

    Håkon

  • Hi Håkon

    Thanks for your Help

    No there is no disconnection, I do not plan one and I don't see any such Disconnection occurring when I debug.

    The sd_ble_gatts_hvx apparently still causes the same problem when I compile on a 0 optimization level, If I optimize to level 3, the HardFault is avoided.

    As I said I am no longer calling the function from an interrupt, but rather via the scheduler 

    Any other ideas?

    Thanks!

Reply
  • Hi Håkon

    Thanks for your Help

    No there is no disconnection, I do not plan one and I don't see any such Disconnection occurring when I debug.

    The sd_ble_gatts_hvx apparently still causes the same problem when I compile on a 0 optimization level, If I optimize to level 3, the HardFault is avoided.

    As I said I am no longer calling the function from an interrupt, but rather via the scheduler 

    Any other ideas?

    Thanks!

Children
  • Hi,

     

    The former PC could have been a red-herring.

    Could you share the whole stack trace and callstack when you fault?

     

    Kind regards,

    Håkon

  • Hi, 

    Could you share the whole stack trace and callstack when you fault?

    This is the call-stack, I am not sure I get what you mean by the "whole stack trace", 

    This is the code calling the function 

        if (p_ble->conn_handle != BLE_CONN_HANDLE_INVALID)
        {
            ble_gatts_hvx_params_t hvx_params;
            uint16_t hvx_len = sizeof(uint8_t);
    
            // Initialize value struct.
            memset(&hvx_params, 0, sizeof(hvx_params));
    
            hvx_params.handle = p_ble->eff_notify_handles.value_handle;
            hvx_params.type   = BLE_GATT_HVX_NOTIFICATION;
            hvx_params.p_len  = &hvx_len;
            hvx_params.offset = 0;
            hvx_params.p_data = data;
    			
    				__disable_irq();
            err_code = sd_ble_gatts_hvx(p_ble->conn_handle, &hvx_params);
    				__enable_irq();
    			
        }

    I disabled the interrupt previously to calling it hoping it would help, it didn't help much, but before I did that I could not see anything in the call stack beside for the Hardfault

    Thanks again!

  • Hi,

     

    You should not disable/enable IRQs while the softdevice is active. This will block it from executing, and will cause assertions inside the softdevice.

    Do you actively use disable_irq() other places in your firmware?

    Use CRITICAL_REGION_ENTER() and CRITICAL_REGION_EXIT() instead. these disable all interrupt expect those that the softdevice uses.

     

    Kind regards,

    Håkon

  • Hi,

    I understand, if I remove the irq disable, the call stack only shows the following:

    And, no, I am not using it elsewhere.

    I now also observed that the order in which I add the characteristics is significant, when I initialize, if I add the notification characteristic after the a write characteristic , it fails, if the notification characteristic  initialize at first, it works. any idea why?

    How would you suggest to proceed?

    Thanks!

  • In another configuration of the project it does not go into Hardfault, but returns error code 0x0003 when calling for the sd_ble_gatts_hvx function

Related