nus_data_handler function timing out

[Seth]

I'm developing bluetooth logging software on the nRF51 DK using SDK 12.3.0. We had been developing for some time in mbed, but were advised to switch over to Keil using the ble_app_uart example as a basis (ble_app_uart_pca10028_s130.uvprojx to be specific). After spending some time to understand the flow of the code, porting to Keil went without too much of a hitch. But, we recently ran into a bit of an issue.

In our code, we read the BLE UART commands through the nus_data_handler function. In this, we decode the commands sent and respond with the necessary response. The problem we’re running into is that the code seems to either crash or timeout if it is in this function for too long. Certain short commands like reading a temperature value enter this function and exit it without problem. However, longer commands like reading the entire log data do not.

I thought this was due to a timer interrupt. But, I’ve tried various things from disabling the timer (periodic_callback_id) to simply extending it to be longer than necessary and the crash still occurs. I tried adding printf statements to see if it was some piece of code that didn’t get ported properly from mbed. But, adding printf statements just changes the location of the error. This is what has lead me to believe that it’s some sort of timeout issue. Granted, it is difficult to read from Keil’s debugger (hence using printf statements instead) given that, when trying to debug, the error sometimes cause the DK to reset and not trigger the debugger at all. So, while it’s possible that it could be something else, the common denominator from what I’ve been seeing seems to be time spent in the nus_data_handler function.

[Susheel Nuguru]

The problem we’re running into is that the code seems to either crash or timeout if it is in this function for too long.

 To answer this, I would first need to understand the nature of the crash. If this is an app_error_fault_handler then this is something that is easily traceable and you will know what kind of assert it is if you start your code in debug mode and put few breakpoints in app_error_weak.c:app_error_fault_handler.

If this is a hardfault, then we need to first figure out the instruction that causes this. If this is inside app code or softdevice code.

Based on the limited information provided, it seems that this could be because of the interrupt priority of the UART, have you changed any priorities inside sdk_config.h? If UART interrupt is masking softdevice activity for too long, this would make the SD assert.

[Seth]

That's the problem I'm having. No error or fault is being raised. That's why I added the print statements to try to find where it was coming from. I looked in app_error_fault_handler, but that function is only 7 lines of code, with a majority of that being for an #ifndef. Where would I put the breakpoint in this function?

No, I have not changed anything in sdk_config.h

[Susheel Nuguru]

Seth,

For app error, if you have enabled DEBUG in your program then set a breakpoint at NVIC_SystemRESET else set it at app_error_save_and_stop

In the above case the call stack after running your program in debug mode should tell you how you reached here.

If this is an hardware related fault, then set a breakpoint in 

components\libraries\hardfault\nrf51\handler\hardfault_handler_XXX.c and start the program in debug mode. Try this post to understand how to debug the hardfault by attempting to know the instruction address that caused the fault.

It pretty much seems to be app specific error, so without getting some debug information on where the crash or fault happened, it is very hard to comeup with a solution for this.

[Seth]

Susheel,

Commenting it like you said helped us find the errors we were running into. Thanks for the help!