flash write problem

RE: flash write problem

Stefan Birnir Sverrisson — Mon, 28 Sep 2015 13:36:27 GMT

Two mistakes in the code.

Variables in dummy_write need to be declared static. With the current implementation where variables only exist locally in the dummy_write function, the flash operation will be pointing to locations in RAM, that actually might be used for something else.
The scheduler apparently needs to be used for softdevice callbacks, i.e. SOFTDEVICE_HANDLER_INIT(NRF_CLOCK_LFCLKSRC_XTAL_20_PPM, true) instead of SOFTDEVICE_HANDLER_INIT(NRF_CLOCK_LFCLKSRC_XTAL_20_PPM, false)

RE: flash write problem

Stefan Birnir Sverrisson — Wed, 23 Sep 2015 12:19:05 GMT

I have not found the root cause yet. I can reproduce the issue with SDK 7.2.0 + S110 7.3.0. I can however not reproduce the issue with SDK 8.0.0 + S110 8.0.0. I cant see in the release notes that the bug has been addressed in SDK 8.0.0, but I have assigned a task to the SDK team to look into the issue. At this point, I can not say when they will finish their investigation.

RE: flash write problem

wim — Tue, 22 Sep 2015 10:47:48 GMT

Hi Stefan, any news on this subject?

RE: flash write problem

Stefan Birnir Sverrisson — Fri, 18 Sep 2015 10:21:15 GMT

I will try to come up with an official fix, but any additional feedback on the problem is most welcome. I will report on this thread with my progress

RE: flash write problem

Stefan Birnir Sverrisson — Fri, 18 Sep 2015 10:18:55 GMT

Hi wim

Yes, I will progress on this and seems that we are not alone with this problem, see this thread. Seems that some customers have found workarounds.

RE: flash write problem

wim — Fri, 18 Sep 2015 10:16:04 GMT

Hi Stefan, That is really strange, I will give it a try, but could you please investigate further and keep me informed of your progress?

RE: flash write problem

RK — Thu, 17 Sep 2015 23:59:21 GMT

What context are you calling dummy_write() from? Main thread context, ie in your main code, or from a handler or some sort, timer, button .. etc?

RE: flash write problem

Stefan Birnir Sverrisson — Thu, 17 Sep 2015 20:43:02 GMT

I saw nothing wrong with your code. I tried to put your code directly into ble_app_template example in SDK 7.2.0, but experienced the same as you, the example_cb_handler was never called. I saw however that the sys_evt_dispatch handler was called. The CPU goes into a hardfault when trying to call example_cb_handler from pstorage.c, but I do not realize at this point why that happens. However, inserting more code into the example_cb_handler seems to fix the problem. If I define it as e.g.

static void example_cb_handler(pstorage_handle_t  * handle,
													 uint8_t              op_code,
													 uint32_t             result,
													 uint8_t            * p_data,
													 uint32_t             data_len)
{
		if(handle->block_id == pstorage_wait_handle) 
		{ 
			 pstorage_wait_flag = 0; 
		} 
		
		switch(op_code)
		{
			case PSTORAGE_LOAD_OP_CODE:
				 if (result == NRF_SUCCESS)
				 {
				 pstorage_wait_flag = 0; 
				 
						 SEGGER_RTT_WriteString(0, "pstorage LOAD callback received \n\n");
						 LEDS_INVERT(BSP_LED_1_MASK);				 
				 }
				 else
				 {
						 SEGGER_RTT_WriteString(0, "pstorage LOAD ERROR callback received \n\n");
						 LEDS_INVERT(BSP_LED_2_MASK);	
				 }
				 break;
			case PSTORAGE_STORE_OP_CODE:
				 if (result == NRF_SUCCESS)
				 {
						 SEGGER_RTT_WriteString(0, "pstorage STORE callback received \n\n");
						 LEDS_INVERT(BSP_LED_1_MASK);	
				 }
				 else
				 {
						 SEGGER_RTT_WriteString(0, "pstorage STORE ERROR callback received \n\n");
						 LEDS_INVERT(BSP_LED_2_MASK);	
				 }
				 break;				 
			case PSTORAGE_UPDATE_OP_CODE:
				 if (result == NRF_SUCCESS)
				 {
						 SEGGER_RTT_WriteString(0, "pstorage UPDATE callback received \n\n");
						 LEDS_INVERT(BSP_LED_1_MASK);	
				 }
				 else
				 {
						 SEGGER_RTT_WriteString(0, "pstorage UPDATE ERROR callback received \n\n");
						 LEDS_INVERT(BSP_LED_2_MASK);	
				 }
				 break;
			case PSTORAGE_CLEAR_OP_CODE:
				 if (result == NRF_SUCCESS)
				 {
						 SEGGER_RTT_WriteString(0, "pstorage CLEAR callback received \n\n");
						 LEDS_INVERT(BSP_LED_1_MASK);	
				 }
				 else
				 {
						 SEGGER_RTT_WriteString(0, "pstorage CLEAR ERROR callback received \n\n");
						 LEDS_INVERT(BSP_LED_2_MASK);	
				 }
				 break;
			case PSTORAGE_ERROR_OP_CODE:
						SEGGER_RTT_WriteString(0, "pstorage ERROR callback received \n\n");
						LEDS_INVERT(BSP_LED_2_MASK);	
				 break;				 
		}	
}

it seems to fix the problem. I will have to investigate further what causes the hardfault.

In this case I use Segger RTT to see when each callback is received.