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

FDS Problems in SDK12.1

Hi All,

I've integrated the flash routines from this example: github.com/.../nRF52-fds-example into my project, and am having problems figuring out the architecture.

I'm using: Keil uVision v5.22.0.0, SDK 12.1.0.0, Softdevice 3.0, and nRF52832.

The problem happens when writing to flash.

The first step in the write process happens properly. It's this function: record_header_write_begin()

However, that's the only thing that gets written.

If I understand correctly, the write operation is added to the queue, and it's executed when the queue_process() function calls write_execute(). The switch statement in that function stops on the case FDS_OP_WRITE_HEADER_BEGIN, and record_header_write_begin() is called. In that function, fs_store() is called and the correct data is written to the correct location in flash. Upon returning from fs_store(), p_op->write.step is updated to the next write operation, which would be FDS_OP_WRITE_RECORD_ID.

That's where the code derails, and my understanding along with it. Nothing more is written to flash, and I don't see how it would be. My understanding of the queue architecture is weak, so I don't know how to troubleshoot that. The program goes along its merry way without crashing or issuing any errors that I can see.

As I step through the code using the debugger, the processor encounters a fatal error any time an fs_store() is executed. So, I can't really see what has happened. I'm sending some data out through the UART, but it's pretty limited.

I'm happy to supply more information, including code, but thought this would be enough for someone who knows the FDS architecture to reach out with a helping hand.

Thanks, robin

  • Hi Robin,

    I'm not quite sure what the problem you are having ?

    Were you able to queue any write after fds_test_write(); ? Note that you need to wait for the callback (in this case my_fds_evt_handler() ) to be sure that the data is written to flash.

    If you step through the code, it will crash at any Softdevice API call, because the softdevice stops working when you stepping in the code.

  • There's a comment at the end of the write_execute() function that says there won't be a callback. I don't know why there isn't a callback, and I don't know how the other members of the switch statement would ever execute without it.

    // An operation has either completed or failed. It may have failed because fstorage
    // ran out of memory, or because the user tried to delete a record which did not exist.
    if (ret != FDS_OP_EXECUTING)
    {
        // There won't be another callback for this operation, so update the page offset now.
        page_offsets_update(p_page, p_op->write.header.tl.length_words);
    }
    
    return ret;
    

    }

    Perhaps p_op remains in the queue, but with its .step value incremented? Can you help me understand this part?

  • I was able to see the header being written only by commenting out the wait that appeared after the call to the write function (as shown below):

        		err_code = fds_test_write();
    		APP_ERROR_CHECK(err_code);
    		NRF_LOG_INFO("fds_test_write() err_code = %ld\r\n", err_code);	
    		//wait until the write is finished. 
    //		while (write_flag==0)
    //		{
    //			write_flag = 1;
    //		}
    

    With the while commented out, the error codes returned by the following are all zero:

    	err_code = fds_test_init();
    	err_code = fds_test_find_and_delete();
    	err_code = fds_test_write();
    	err_code = fds_read();
    

    When uncommented and allowed to run, the while loop is infinite. The fds_evt_t named p_fds_evt passed to my_fds_evt_handler() contains an id of FDS_EVT_WRITE the first time through. The second time through, it contains FDS_EVT_GC. There are no more calls to it after that, so the write flag never gets set.

  • Hi Robin,

    The loop to wait for the write_flag to be set is needed. Note that the write_flag should only be set inside the callback handler you registered, in this case my_fds_evt_handler().

    Also make sure this fs_sys_event_handler(sys_evt); is called inside sys_evt_dispatch() so that fstorage can track the callback from the softdevice.

    I attached here a project that I write to 2 records instead of one. It worked fine (SDKv12.1).

    ble_app_proximity - TestFDS.zip

  • OK, Hung Bui, you solved it. sys_evt_dispatch() wasn't calling fs_sys_event_handler(sys_evt). Once I added that, it started working. Thanks for your valuable help.

Related