softdevice error code 0x0000000D1

[Ron]

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

[Håkon Alseth]

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

[Ron]

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!

[Ron]

Changes to the application code to change the effect on the sd_ble_gatts_hvx ,the error occurs when calling sd_ble_gatts_hvx which is a softdevice function, so, if the problem is a corrupted or null pointer, can I assume that it is a corrupted pointer that I have passed to the sd_ble_gatts_hvx function? throughout the code I have other notification service-characteristics without any issues.

If the problem is a stack overflow, what is the best way to verify it?

Thanks again

[Ron]

Hi, 

Another question if I may, I played around with the code a bit, without using irq_diable(), I was able to avoid Hardfault but still getting error 0x0003 returned from sd_ble_gatts_hvx  , what can this mean?

Thanks and best regards

[Håkon Alseth]

Hi,

 

Ron said:

Another question if I may, I played around with the code a bit, without using irq_diable(), I was able to avoid Hardfault but still getting error 0x0003 returned from sd_ble_gatts_hvx  , what can this mean?

Did you try to increase the stack size? This error is an internal error, and its the default return code if the input parameters are not matching the expected format.

 

You can set the stack size as high as you'd like, but it is restricted towards how much RAM you have available.

 

Ron said:

If the problem is a stack overflow, what is the best way to verify it?

When in debug mode, check the cpu register "SP", and see if the address there is outside the area that is set-aside for the stack. You can find the stack area in your .map file.

 

Kind regards,

Håkon

[Ron]

Hi Håkon

I am using the nrf51822xxaa with s130, what is the maximum stack size I can chose and how exactly it is done? Increasing the stack size will be done via the arm_startup_nrf51.s file?

                IF :DEF: __STARTUP_CONFIG
Stack_Size      EQU __STARTUP_CONFIG_STACK_SIZE
                ELIF :DEF: __STACK_SIZE
Stack_Size      EQU __STACK_SIZE
                ELSE
Stack_Size      EQU 2048
                ENDIF

This is what I am seeing on the .map file 

STACK$$Length                            0x00000800   Number         0  anon$$obj.o ABSOLUTE

After failing on the sd_ble_gatts_hvx I checked the SP, it is 0x20003918

According to the .map file 

STACK     0x20003178   Section     2048  arm_startup_nrf51.o(STACK)

STACK$$Base 0x20003178 Number 0 arm_startup_nrf51.o(STACK)
__initial_sp 0x20003978 Data 0 arm_startup_nrf51.o(STACK)

between 0x20003918 and 0x20003978 there is some space although I don't know how much the softdevice used during the execution of sd_ble_gatts_hvx  what do you think?

Thanks and best regards

[Håkon Alseth]

Hi,

 

Could you share the full function that calls sd_ble_gatts_hvx()?

Does the issue still occur immediately, or does it happen "after some time"?

 

Ron said:

After failing on the sd_ble_gatts_hvx I checked the SP, it is 0x20003918

 This shows that there's only 0x60 bytes of stack being used, so there's no stack overflow.

 

Ron said:

I am using the nrf51822xxaa with s130, what is the maximum stack size I can chose and how exactly it is done? Increasing the stack size will be done via the arm_startup_nrf51.s file?

You can increase the size by setting the ASM define "__STACK_SIZE=3072" in your keil project settings -> assembly tab. You have to ensure that you do not exceed the amount of RAM that you have available. If you have the 16k version, you can currently set it to max. 3720 bytes for instance.

Kind regards,

Håkon

[Ron]

Hi

Håkon Alseth said:

Could you share the full function that calls sd_ble_gatts_hvx()?

uint32_t ble_eff_notify_hvx_send(ble_led_t * p_ble, uint8_t * data)
{
    uint32_t err_code = NRF_SUCCESS;
	
    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.			
        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;
			
        err_code = sd_ble_gatts_hvx(p_ble->conn_handle, &hvx_params);
					
				
    }
    else
    {
        err_code = NRF_ERROR_INVALID_STATE;
    }

    return err_code;
}

Håkon Alseth said:

Does the issue still occur immediately, or does it happen "after some time"?

This happens every time the the sd_ble_gatts_hvx  function is called, I have a breakpoint after the 

err_code = sd_ble_gatts_hvx(p_ble->conn_handle, &hvx_params);

 

Håkon Alseth said:

You can increase the size by setting the ASM define "__STACK_SIZE=3072" in your keil project settings -> assembly tab. You have to ensure that you do not exceed the amount of RAM that you have available. If you have the 16k version, you can currently set it to max. 3720 bytes for instance.

Ok, I tried this, did not work...

Any other ideas?

Thanks again!

[Ron]

Hey another small note, I am now in a situation in which just adding some local variables in the function (or the function that calls that function) results in this problem, again when I am in a non optimized compilation. 

Thanks!

[Håkon Alseth]

Hi,

  

Ron said:

again when I am in a non optimized compilation. 

 Can you try comparing what goes into the sd_ble_gatts_hvx() function (in debug mode), with optimized and non-optimized firmware?

What do you change in the optimization, is it only the level 0 to 3?

 

Where is ble_eff_notify_hvx_send called from, and how does that code look?

 

Kind regards,

Håkon

[Ron]

Hi Håkon, your help is much appreciated

Håkon Alseth said:

 Can you try comparing what goes into the sd_ble_gatts_hvx() function (in debug mode), with optimized and non-optimized firmware?

This is a comparison I put together for the hvx_params 

Håkon Alseth said:

What do you change in the optimization, is it only the level 0 to 3?

So far all I have changed was optimization between 0 and 3, now I have also tried level 1 and 2, both of those optimization levels showed no problems.

Håkon Alseth said:

Where is ble_eff_notify_hvx_send called from, and how does that code look?

It is called from the app_schedeuler, not from an interrupt. by the way, I have another notification which is called from an interrupt and it never had any issues.

As I said, I have noticed that a minor change such as changing the order in which variables are declared, results in this failure, I compared the .hex compilation files, between one successful version and one bugged version, and it is clear that this small change in order of variable declaration caused a very dramatic change in the .hex file compilation output, altering more than half of the lines in the entire .hex files. 

What do you think can cause this? 

Thanks again

[Håkon Alseth]

Hi,

 

Ron said:

This is a comparison I put together for the hvx_params 

All those looks correct in terms of what goes into the sd_ function. Can you please post the full function where you modified the code in order to make it work?

 

Kind regards,

Håkon