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

FDS write kills softdevice somehow - SDK 13

Hello,

I'm trying to get the FDS to work, but it's giving me a headache. I'm using SDK 13.1 and S132 4.0.2 on a NRF52832.

In the beginning I thought I had that issue where the events simply don't get forwarded to my event handler, but the issue seems to be worse than that.

My writing function looks like this:

ret_code_t my_flash_write(uint16_t file_id, uint16_t record_id, uint32_t * data, uint16_t length) {
	fds_record_t        record;
	fds_record_desc_t   record_desc;
	fds_record_chunk_t  record_chunk;
	fds_find_token_t	ftok = {0};		//Important, make sure you zero init the ftok token
	ret_code_t err_code;

	uint8_t record_exists;

	err_code = fds_record_find(file_id, record_id, &record_desc, &ftok);

	switch (err_code) {
		case FDS_SUCCESS:
			debug_line("Record ID 0x%04X found", record_id);
			record_exists = 1;
			break;
		case FDS_ERR_NOT_FOUND:
			debug_line("Record ID 0x%04X not found, will create new record", record_id);
			record_exists = 0;
			break;
		default:
			debug_error("FDS record find failed with error code 0x%02X", err_code);
			return err_code;
	}

	// Set up data
	record_chunk.p_data			= data;
	record_chunk.length_words	= length;

	// Set up record
	record.file_id				= file_id;
	record.key					= record_id;
	record.data.p_chunks		= &record_chunk;
	record.data.num_chunks		= 1;

	if (record_exists) {
		err_code = fds_record_update(&record_desc, &record);
	} else {
		err_code = fds_record_write(&record_desc, &record);
	}

	switch (err_code) {
		case FDS_SUCCESS:
			debug_line("Writing record ID: 0x%04X", record_id);
			return NRF_SUCCESS;
		case FDS_ERR_NO_SPACE_IN_QUEUES:
			return NRF_ERROR_BUSY;
		case FDS_ERR_NO_SPACE_IN_FLASH:
			run_garbage_collection();
			return NRF_ERROR_BUSY;
		default:
			debug_error("FDS record write failed with error code 0x%02X", err_code);
			return err_code;
	}
}

As soon as I call it, it returns NRF_SUCCESS and the BLE part of the app just stops working. Nevertheless, my app is still working, it's just the BLE part that stops working. It disconnects, it doesn't advertise anymore, it doesn't even forward the BLE_GAP_EVT_DISCONNECTED to my app.

I'm wondering whether I'm accidentally overwriting some reserved area of the softdevice somehow, but I'm just using the FDS library so I guess that shouldn't happen. Besides, if I reset the device, everything works normally again.

Any help with this will be appreciated!

UPDATE: Just to make it clear, I've checked out numerous posts regarding the FDS library and I can confirm that I have registered my event handler with the softdevice using softdevice_sys_evt_handler_set(sys_evt_dispatch); and that I forward the events to the fstorage module using fs_sys_event_handler(sys_evt); inside the system event handler.

UPDATE 2: I disabled the peer manager initialization just to see if there was some conflict between my accesses to flash and the peer manager's, but no luck, issue is still there.

UPDATE 3: I was able to write to flash by passing a constant array like in the examples (data = {0xAAAAAAAA, 0xBBBBBBBB};) but now I'm having this problem. My guess is that I was probably wrongly manipulating the data pointer, but it seems a bit extreme to me that it would make the softdevice crash. If anything, I would expect corrupted data, but not a crash. This is how I was building my data:

void settings_build_name_data(uint32_t * data, uint16_t * length) {
	uint8_t * name_data = (uint8_t *)data;
	for (uint8_t i = 0; i < MAX_NAME_LENGTH; i++) {
		name_data[i] = settings.name[i];
	}
	*length = MAX_NAME_LENGTH / 4;
}

I want to store an array of chars (uint8_t), so I thought it would be clever to just create a pointer to uint8 that pointed to the same location where the uint32s were located, and then just iterate through the array with a for loop, instead of being constantly masking and shifting the uint32s. I realize this may sound like a bad idea, but as I said, I expected my biggest problem to be corrupted data (due to endianness or such things), but a softdevice crash seems too extreme to me.

Related