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

weird behavior of pstorage_update function

Hi,

If I am honest I have encountered a weirdest problem since I have been programming. Here is the code (function void scheduler_mass_history_handler) which is executed every 15s. Everythink works great if pstorage_update(&block_0_handle, m_mass.histroy_last, 80, 76) function is not called, if it is then error 10 is received. I know that error 10 presents NRF_ERROR_INVALID_ADDR but I think that this is not the case. Moreover, sometimes the pstorage_update() does not throw error. This fact depends on location of variable m_mass.histroy_last in struct ble_mass_t, which is defined as:

typedef struct ble_mass_s
{
    ble_mass_eeprom_handler_t               mass_eeprom_write_handler;
	  ble_load_cell_calibration_handler_t     load_cell_calibration_handler;
	  ble_offset_load_cell_handler_t          offset_load_cell_handler;	
    ble_gatts_char_handles_t        				gas_percent_char_handles;                
	  ble_gatts_char_handles_t        				empty_mass_cylinder_char_handles;    				
    ble_gatts_char_handles_t        				max_mass_gas_char_handles; 			            
    ble_gatts_char_handles_t        				calibration_load_cell_char_handles; 			  
	  ble_gatts_char_handles_t        				buzzer_level_gas_char_handles; 			        
	  ble_gatts_char_handles_t        				date_set_char_handles; 			                
		ble_gatts_char_handles_t        				history_char_handles; 
	  ble_gatts_char_handles_t        				error_load_cell_char_handles;
	  ble_gatts_char_handles_t        				offset_load_cell_char_handles; 
	  ble_gatts_char_handles_t        				is_cylinder_full_gas_char_handles; 	  
	  
	  
	  uint16_t                        				service_handle;    
	  uint8_t                         				uuid_type;           					              
    uint16_t                    	  				conn_handle;         					              	  	  
	  uint16_t                         				gas_percent_last;
	  uint16_t                        				empty_mass_cylinder_last;
	  uint16_t                        				max_mass_gas_last;		
	  ble_load_cell_calibration               load_cell_calibration;
	  ble_date_time_t                 				date_cylinder_set;
      
     uint8_t				histroy_last[80];

     uint16_t                                total_num_cycles_error;     		
		uint8_t			error;
		uint8_t			buzzer_level_gas_last;				
		uint8_t			mass_percent_threshold;
		uint8_t			mass_cycles;
		uint16_t                    history_counter;
		uint32_t                     mass_timer_ms;
	  uint8_t                             mass_flag;      
		uint8_t                       is_Enable_Load_Cell;
		uint8_t                       mass_cycles_previous;		
		 
		 
		
		
}ble_mass_t;

If the array histroy_last[80]; is placed in same place such as presented above then the pstorage_update(&block_0_handle, m_mass.histroy_last, 80, 76) does not throw error, otherwise ( if histroy_last[80] is located lower then presented ) then I immediately get error 10. I do not understand why the location of histroy_last has such influence. I will be really grateful for any comments about my concern because I do not see any reasonable explanation about presented problem.

void scheduler_mass_history_handler(void *p_event_data, uint16_t meas_time) // pravi handler
{	
  ...
  ...
   if(m_mass.history_counter < (MAX_MASS_HISTORY_ARRAY	 - 5))
  {
	m_mass.histroy_last[m_mass.history_counter++] = mass[0];
	m_mass.histroy_last[m_mass.history_counter++] = mass[1];
	m_mass.histroy_last[m_mass.history_counter++] = time_encode[0];	
	m_mass.histroy_last[m_mass.history_counter++] = time_encode[1];		
	m_mass.histroy_last[m_mass.history_counter++] = m_infs.temp_last;	
 }
 ...
 ...
 pstorage_wait_flag = 1; 
 retval	=	pstorage_update(&block_0_handle, m_mass.histroy_last, 80, 76);		
	
simple_uart_put(retval);
while(pstorage_wait_flag)
{
  power_manage();
    }	

    APP_ERROR_CHECK(retval);	
	
   // send history array to ble		
   retval = ble_mgs_history_update(&m_mass);
   APP_ERROR_CHECK(retval);

    
    }

Best regards

Samo

Parents
  • Hi Samo

    To start with, I would recommend to update your pstorage module to SDK 9.0.0 or more recent. Pstorage was refactored in SDK 9.0.0. There is a bug in pstorage of SDK 8 and older that can cause race condition and weird behavior. pstorage module is not dependent on any other modules so it should be relatively easy just to copy pstorage.h, pstorage.c and pstorage_platform.h files from SDK 9+ into your current project and start using it.

Reply
  • Hi Samo

    To start with, I would recommend to update your pstorage module to SDK 9.0.0 or more recent. Pstorage was refactored in SDK 9.0.0. There is a bug in pstorage of SDK 8 and older that can cause race condition and weird behavior. pstorage module is not dependent on any other modules so it should be relatively easy just to copy pstorage.h, pstorage.c and pstorage_platform.h files from SDK 9+ into your current project and start using it.

Children
Related