Erroneous BLE disconnection associated with trivial, unrelated code changes with nRF51822

RE: Erroneous BLE disconnection associated with trivial, unrelated code changes with nRF51822

Edvin — Fri, 30 Aug 2019 06:45:39 GMT

Ok, so sd_ble_gatts_hvx() returns BLE_ERROR_GATTS_SYS_ATTR_MISSING.

I see a couple of posts like this, such as this one:

https://devzone.nordicsemi.com/f/nordic-q-a/1948/strange-error-code-13313-0x3401-returned-by-sd_ble_gatts_hvx

Do you use bonding in your application? I ask because I see a lot of these posts having issues with bonding.

Also, if this case is not in your on_ble_evt() in main.c (or wherever you have it), please try to include it:

        case BLE_GATTS_EVT_SYS_ATTR_MISSING:
            // No system attributes have been stored.
            err_code = sd_ble_gatts_sys_attr_set(m_conn_handle, NULL, 0, 0);
            APP_ERROR_CHECK(err_code);
            break; // BLE_GATTS_EVT_SYS_ATTR_MISSING

Best regards,

Edvin

RE: Erroneous BLE disconnection associated with trivial, unrelated code changes with nRF51822

inf_sup_bus — Fri, 30 Aug 2019 01:40:28 GMT

Hello,

Yes there is definitely an APP_ERROR_CHECK(err_code) function call in line 406 in knee_angle.c. Removing the first breakpoint and adding the second breakpoint (where the second breakpoint is on line 54 of app_error.c) returns the same error information in the error_info_t structure as in my previous post.

The err_code in this context is not directly returned by a SoftDevice call, it is returned by ble_central_adv_information_update(...). The definition of ble_central_adv_information_update(...) is defined exactly as you recommended in your response on the 12th August.

The err_code variable is being returned from sd_ble_gatts_hvx(...), which is called within ble_central_adv_information_update(...). The value of the error code is 13313 decimal or 0x3401, which is the same error code as my last post (essentially, it's the same error that's occurring). This sd_ble_gatts_hvx(...) call is performing a notification, where the knee angle is being transmitted to a remote mobile phone.

RE: Erroneous BLE disconnection associated with trivial, unrelated code changes with nRF51822

Edvin — Fri, 16 Aug 2019 07:05:20 GMT

ok. Closing in. Can you hover over the p_file_name, and see if you can find the name of the file that it is pointing to. Alternatively, copy the memory 1 values that you have in your screenshot, and see the path (if you convert them to ascii/char values. It is somewhere in components\Leg<something-something>. Should be a .c file.

If you remove the first breakpoint and add the second, it should update the error_info variable, but you can see that the line number "line_num" that is passed onto this function is 0x196 = decimal: 406. So in one of the files in the path components\Leg... there is a APP_ERROR_CHECK(err_code) on line 406. This one receives an err_code != 0. What is the function that returned this err_code?

EDIT:
I checked your path, but I believe you can see it if you hover over the mouse. In case not:

So your file knee_angle.c has an APP_ERROR_CHECK(err_code); on line 406. What function returned this value? If it is not a direct softdevice call, what function inside this function returned this return value?

Best regards,

Edvin

RE: Erroneous BLE disconnection associated with trivial, unrelated code changes with nRF51822

inf_sup_bus — Thu, 15 Aug 2019 23:58:50 GMT

Hello Edvin,

I have adjusted the code to how you have suggested. These are the values of the error code, line number and file names in the error_info_t after the application stopped at the breakpoint in app_error_handler.

The error code has value 0x3401 or 13313 decimal.

RE: Erroneous BLE disconnection associated with trivial, unrelated code changes with nRF51822

Edvin — Mon, 12 Aug 2019 07:12:18 GMT

This is your peripheral, right? I believe it is, but I get a bit confused by the name (ble_central_adv_information_update).

You should check the return values of your softdevice function calls, such as sd_ble_gatts_hvx();

I suggest that you change the function from void ble_central_adv_information_update() to uint32_t ble_central_adv_information_update(), and return the value from last function call:

void ble_central_adv_information_update(ble_mpu_c_t *p_mpu, uint8_t* knee_angle)
{

    if(p_mpu->conn_handle != BLE_CONN_HANDLE_INVALID)
    {
        ... // All the things that you already had
        hvx_params.p_data = (uint8_t*)knww_angle;
        return sd_ble_gatts_hvx(p_mpu->conn_handle, &hvx_params);
    }
    else // p_mpu->conn_handle == BLE_CONN_HANDLE_INVALID
    {
        return NRF_ERROR_INVALID_STATE;
    }

}

and then check the return value from your function:

uint32_t err_code;

knee_angle[0] = (int16_t) knee_angle_deg;
err_code = ble_central_adv_information_update(&m_ble_mpu_c, knee_angle);

if (err_code != NRF_ERROR_INVALIDE_STATE)
{
    APP_ERROR_CHECK(err_code);
}

This way it is easier to check what the application is doing. What is the return value from ble_central_adv_information_update(&m_ble_mpu_c, knee_angle);

RE: Erroneous BLE disconnection associated with trivial, unrelated code changes with nRF51822

inf_sup_bus — Mon, 12 Aug 2019 02:27:59 GMT

This project is not using FreeRTOS. The snippet of ble_central_adv_update() is attached.

Would you agree that the application is likely crashing because '(int_16t) knee_angle_deg' is being copied into an unallocated space in memory, which is an illegal memory access, thus firing the HardFault_Handler?

My reasoning is that it's more likely the illegal memory access that's causing the handler to fire as opposed to copying a 16 bit type into a memory space pointed by a pointer to uint8_t (which is knee_angle in this case), since the word length is 32 bits on the Cortex M0. As far as I know no packing is used in the source code.

RE: Erroneous BLE disconnection associated with trivial, unrelated code changes with nRF51822

Edvin — Fri, 09 Aug 2019 06:19:55 GMT

Are you using FreeRTOS in your project?

What does your ble_central_adv_update() look like?

RE: Erroneous BLE disconnection associated with trivial, unrelated code changes with nRF51822

inf_sup_bus — Fri, 09 Aug 2019 05:56:12 GMT

[quote userid="26071" url="~/f/nordic-q-a/50377/erroneous-ble-disconnection-associated-with-trivial-unrelated-code-changes-with-nrf51822/202518"]So does the breakpoint trigger after defining DEBUG in your preprocessor defines?[/quote]

The debugger does not halt the program at L48 in app_error.c. However, I did notice that after stopping the debugger, the 'code pointer' (yellow arrow in uVision) was pointing to line 154 of arm_startup_nrf51.s. This section is pertinent to the HardFault_Handler. The caller code for the HardFault_Handler appears to be an ARM ABI helper-function (page 17 of http://infocenter.arm.com/help/topic/com.arm.doc.ihi0043d/IHI0043D_rtabi.pdf). The assembler code disassembly window shows that it's occurring around SEGGER_RTT_printf() and ble_central_adv_information_update() function calls. I've also attached a snippet of the suspected location where the hard fault is occurring. Doing some research, I found the following resources useful:

http://www.keil.com/appnotes/files/apnt209.pdf pp. 17-18
Susheel Nuguru's first response to Nordic Devzone case 107574

I've attached a screenshot of the debugging view in Keil showing the debugger view. Following the Keil application note advice, the program counter (0x20005E60) contains value 0xB6D70200. Wanting to find out what the next instruction was that caused the fault, I searched the memory to find the value at 0xB6D70200. The result is unusual, as attached: the value here is just question marks. I'm not sure what this means; am I accessing an invalid memory location, or is the value here unknown or undefined?

Following the advice from case 107574, the address at SP+0x14 is 0x20005E5C which has value 0xB7D70200. My project directory doesn't seem to contain a .map file as Susheel was suggesting, so I couldn't attempt to find the function associated with that location. The value at the location 0xB7D70200 was also displayed as question marks.

I did note a discrepancy between the two sources I've consulted: the Keil application note states that the program counter is located at an offset of 0x18 from the main stack pointer, but case 107574 implies that the program counter is offset by 0x14. Which should I use?

RE: Erroneous BLE disconnection associated with trivial, unrelated code changes with nRF51822

Edvin — Tue, 06 Aug 2019 06:51:31 GMT

[quote user="inf_sup_bus"]I redefined the integer type of tibia_dt and femur_dt to uint32_t as the .timestamp field of the struct is defined as uint32_t[/quote]

Ok. This was a shot in the dark, but I have seen something like this before. Writing too long to e.g. an uint8_t causing hard faults, because the area it may overwrite could be in the stack pointer, and then there is no way of knowing what can happen.

[quote user="inf_sup_bus"]Do you suggest that I check the error codes in the other routines outside of update_knee_angle()?[/quote]

Yes. Most definitely. And the easiest way to do this is:

[quote user="Edvin Holmseth"]Have you tried to check if the error handler fires? Try to define "DEBUG" in your preprocessor defines, and disable optimization in the compiler (let me know if you are not sure how to do this), and set a breakpoint on line 48 in app_error.c. Does that breakpoint ever get hit if you are debugging?[/quote]

Setting O0 should be sufficient. Not disabling optimization would still set the breakpoint on this line, but you may not be able to see the values of the variables, telling you where the APP_ERROR_CHECK() that triggered is located. You should be able to see the variable values when you use O0.

So does the breakpoint trigger after defining DEBUG in your preprocessor defines?

BR,

Edvin

RE: Erroneous BLE disconnection associated with trivial, unrelated code changes with nRF51822

inf_sup_bus — Mon, 05 Aug 2019 22:39:58 GMT

Hello Edvin,

Thanks for your response. I redefined the integer type of tibia_dt and femur_dt to uint32_t as the .timestamp field of the struct is defined as uint32_t, but this did not resolve the connection issues. Your suggestion that the application is crashing when it enters update_knee_angle() and consequently causes the connection to timeout seems like the most likely scenario here.

APP_ERROR_CHECK(err_code) invocations are used throughout the application when a SD or nRF API function is called, such as during the general BLE initialisation and transmit/receive routines. However, I do not currently call any API functions in update_knee_angle(). It is my understanding the err_code is a value generally returned from an API function call, so could you elaborate how I could use the error code return value to check what kind of error is being caused in update_knee_angle(), given that I don't have any API function calls in update_knee_angle()? Do you suggest that I check the error codes in the other routines outside of update_knee_angle()?

The minimum level of optimization available in the C/C++ tab of the Project Options to be O0, which doesn't fully disable optimization but provides the minimum level of optimization. Is there a way to fully disable optimization here?

I will be able to do some further debugging once my above queries have been clarified,

Best regards,

RE: Erroneous BLE disconnection associated with trivial, unrelated code changes with nRF51822

Edvin — Tue, 30 Jul 2019 12:32:06 GMT

Hello,

[quote user=""]SDK v11.0.0 or v12.2.0 (here I'm not sure which SDK exactly it is, and I do not know a way of being able to find out)
Keil uVision V5.26.2.0 with MDK-ARM Professional Version: 5.26.2.0
Target DLL: Segger\JL2CM3.dll
Dialog DLL: TARMCM1.DLL
SoftDevice version S130_nRF51_2.0.1[/quote]

If you are using S130 v2.0.1, then you are probably using SDK12.2.0 if SDK11.0.0 and SDK12.2.0 are your only candidates. SDK11.0.0 uses S130 v2.0.0, while SDK 12.X.0 uses S130 v2.0.1.

So, the softdevice will not call sd_ble_gap_evt_disconnect() on it's own. Not without telling you.

My initial guess is that when you change your function, it somehow causes the application to crash, and the other device receives a timeout, because the first device's radio goes silent.

It is hard to say exactly what the issue is. Do you have any APP_ERROR_CHECK(err_code) that is called within the functions that you check? Have you tried to check if the error handler fires? Try to define "DEBUG" in your preprocessor defines, and disable optimization in the compiler (let me know if you are not sure how to do this), and set a breakpoint on line 48 in app_error.c. Does that breakpoint ever get hit if you are debugging?

Another possibility, but this is a shot in the dark:

int tibia_dt = tibia_info.timestamp - prev_tibia_timestamp;

What type of variables are tibia_info.timestamp and prev_tibia_timestamp?

int is not universally defined, so maybe you can try to set it to the same as tibia_info.timestamp and prev_tibia_timestamp, and see if that helps.

But try to see if the error handler is catching something.

Best regards,

Edvin