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

Hard fault SD132 with timers and ble rwauth

Hi,

i'm testing an application on nRF52, with nRF5_SDK_11.0.0-2.alpha and SoftDevice 132.

I took the ble_uart example and added a custom service with some characteristics with various permissions. Everything seems to work well, i then decided to add a timer for system tick tracking and i'm stuck in a hard fault i get when performing SD calls.

In main.c i defined a timer for system tick management

APP_TIMER_DEF(system_timer);
volatile uint32_t systemTick;
...
int main(int)
{ 
    ...
    services_init();
    ... 
    err_code = app_timer_create(&system_timer, APP_TIMER_MODE_REPEATED , systemtimer_timeout_callback);
    err_code = app_timer_start(system_timer, APP_TIMER_TICKS(1, 0), NULL);
    ...
    for(;;){
    }
}

void systemtimer_timeout_callback(void *p_context)
{
	systemTick++;
	return;
}

What happens it that, if i perform authorized read on my characteristic, the system crashes without recovering. For example if i do authorized read from nRF Master tool, the system enters BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST, but when i perform sd_ble_gatts_rw_authorize_reply, it doesn't exit from the function. If i debug and pause after that i can see

HardFault_Handler() at 0x24022
<signal handler called>() at 0xfffffff1	
on_rwauth() at ble_myservice.c:575 0x21444	
ble_myservice_on_ble_evt() at ble_myservice.c:672 0x21614
...

on the call stack.

If i comment timer section, everything works. Do you have any idea what could be the issue?

Thank you

EDIT 1:

This is a snippet of the function on_rwauth() i call inside BLE_GATT_RW_AUTHORIZE_REQUEST:

static void on_rwauth(ble_gate_t * p_gate, ble_evt_t * p_ble_evt){
	uint8_t result;
	uint8_t ledstate;
	uint32_t err_code;
	ble_gatts_rw_authorize_reply_params_t    reply_params;
	if (p_ble_evt->evt.gatts_evt.params.authorize_request.type == BLE_GATTS_AUTHORIZE_TYPE_READ){
		//Authorized Read
		if(p_ble_evt->evt.gatts_evt.params.authorize_request.request.read.handle == p_myservice->state_handle.value_handle){
			SEGGER_RTT_WriteString(0, "READ AUTH IN\r\n");
			//retrieve global state of myservice
			result = p_myservice->mysrv_globalstate_handler(p_myservice);
			if(result == INIT_STATE){
				strncpy((char *)user_data, "HELLO", sizeof(user_data) -1);
			}
			else{
				//return state of LED
				ledstate = mysrv_ledstate_handler(p_myservice);
				if(ledstate == LED_ON){
					strncpy((char *)user_data, "ON", sizeof(user_data) -1);
				}
				else if(ledstate == LED_OFF){
					strncpy((char *)user_data, "OFF", sizeof(user_data) -1);
				}
			}

			memset(&reply_params, 0, sizeof(reply_params));

			reply_params.type                       = BLE_GATTS_AUTHORIZE_TYPE_READ;
			reply_params.params.read.p_data 		= (uint8_t *)&user_data[0];
			reply_params.params.read.len        	= strlen((char *)user_data);
			reply_params.params.read.offset 		= 0;
			reply_params.params.read.update 		= 1;

			SEGGER_RTT_WriteString(0, "ENTER SD_BLE_GATTS:....\r\n");
			
			err_code = sd_ble_gatts_rw_authorize_reply(p_ble_evt->evt.gattc_evt.conn_handle, &reply_params);
			APP_ERROR_CHECK(err_code);
			
			SEGGER_RTT_WriteString(0, "READ AUTH OUT\r\n");
		}
	}
Parents
  • This sounds like the data you are providing to rw_authorize_reply() is not valid. Can you check the pointer you are providing? Have you taken a look at the SD migration document, and more specifically the section where it describes how to handle authorized operations since there have been substantial changes since s130 v1.

  • Yes i'm sure and app_error_fault_handler is not hit. Here is something more, this behaviour is seen in Eclipse GCC. I tried to compile with Keils 5 and i don't see HardFault anymore. One thing i noted in GCC is that sd debug info says:

    RAM START ADDR 0x20001F00 should be adjusted to 0x20001E00
    RAM SIZE should be adjusted to 0xE200 
    sd_ble_enable: RAM START at 0x20001F00
    sd_ble_enable: app_ram_base should be adjusted to 0x20001E10
    ram size should be adjusted to 0xE1F0 
    

    I read that this shouldn't bother anyway.

Reply
  • Yes i'm sure and app_error_fault_handler is not hit. Here is something more, this behaviour is seen in Eclipse GCC. I tried to compile with Keils 5 and i don't see HardFault anymore. One thing i noted in GCC is that sd debug info says:

    RAM START ADDR 0x20001F00 should be adjusted to 0x20001E00
    RAM SIZE should be adjusted to 0xE200 
    sd_ble_enable: RAM START at 0x20001F00
    sd_ble_enable: app_ram_base should be adjusted to 0x20001E10
    ram size should be adjusted to 0xE1F0 
    

    I read that this shouldn't bother anyway.

Children
No Data
Related