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!

[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

[Ron]

Hey,

I think I found the problem, it was in the definition and creation of the notification characteristic, specifically I had the following configuration ble_add_char_params.is_value_user = 1 

is_value_user was configured as 0x01, when calling characteristic_add  that resulted at attr_md.vloc to be configured as 0x02, meaning BLE_GATTS_VLOC_USER, before passing it to sd_ble_gatts_characteristic_add

BLE_GATTS_VLOC_USER - Attribute Value is located in user memory. This requires the user to maintain a valid buffer through the lifetime of the attribute, since the stack will read and write directly to the memory using the pointer provided in the APIs.

When I set it is_value_user to 0x00, vloc was set to 0x01 - BLE_GATTS_VLOC_STACK, attribute Value is located in stack memory, no user memory is required. 

That made the project stable, working properly in every variation I tried and the problem with sending the notification disappeared. 

Thanks for all of your help and kind regards

[Håkon Alseth]

Hi,

  

Ron said:

I think I found the problem, it was in the definition and creation of the notification characteristic, specifically I had the following configuration ble_add_char_params.is_value_user = 1 

is_value_user was configured as 0x01, when calling characteristic_add  that resulted at attr_md.vloc to be configured as 0x02, meaning BLE_GATTS_VLOC_USER, before passing it to sd_ble_gatts_characteristic_add

BLE_GATTS_VLOC_USER - Attribute Value is located in user memory. This requires the user to maintain a valid buffer through the lifetime of the attribute, since the stack will read and write directly to the memory using the pointer provided in the APIs.

When I set it is_value_user to 0x00, vloc was set to 0x01 - BLE_GATTS_VLOC_STACK, attribute Value is located in stack memory, no user memory is required. 

Good work on finding this issue! I am very glad to hear that  its working as expected now.

Cheers,

Håkon