When could I write the flash???

[jimlin]

Hi,

I know the flash operation, including earse and write, should be excuted when the radio is inactive. So, I put the flash earse and write operation into the function 'ble_flash_on_radio_active_evt' and only do it when the m_radio_active == false. Is it right? It always run to app_error_handler() once the ble_flash_page_erase() called, but when it called, the radio is inactve. Is the earse time too long to prevent the radio re-start? The SDK I used is 4.4.1 while the softdevice is 5.2.1, for the sample in hand could only run on this version.How could I do this correctly under these version?

Thanks.

[Ole Morten]

First, I'd strongly recommend you to upgrade to S110 version 6.0.0. For production you'll most likely end up getting second revision chips anyway, and for these S110 version 6.0.0 is the recommended solution. For development, you can also use 6.0.0 on your first revision chip, as long as you don't go into production with this combination. As explained here, there is (at least) one known assert with this combination.

Doing a flash erase will typically take 21 ms, as specified in the PS, so you need to make sure to do it at a time the softdevice won't need to run anything for (at least) that period. If the connection (or advertising) interval is short, it may not be possible to do while in a connection (or while advertising). In that case, the only time you can do it is while disconnected.

However, if you make sure that the connection (or advertising) interval is long, there should be sufficient time to do it right after a radio event, as you say you do now. If you can't get this working, can you please upload the compelte source code your working with, so I can take a look?

[jimlin]

Hi Morten,

Thanks for your answer.

My application is to store the DPI setting into flash once the DPI button pressed when connecting. As you said, the only way is to do it when disconnected, which is safety for I am not sure how long the connection interval is. But, I do not think it is reasonable for mouse application to disconnect it for flash operation. It is bad experience for user. What's your suggustion?
Do you have any demo on flash operation during connection?

Thanks.

[jimlin]

the parameters I set are: MIN_CONN_INTERVAL = 7.5 MAX_CONN_INTERVAL = 15 SLAVE_LATENCY = 25 CONN_SUP_TIMEOUT = 3000

Does it mean the connection interval is between 7.5 and 15ms? As SPEC described, the CONN_INTERVAL is between 7.5ms to 4s.If want the longer interval, could I set the MAX_CONN_INTERVAL directly?

[jimlin]

I try to find another way: disconnect the link then write the flash, and re-connect as followed: //============================================== // Enter main loop. for (;;) { app_sched_execute(); power_manage(); if(bind_info_clear == true) NVIC_SystemReset(); if(dpi_level_store == true) { if(ble_connected == true) { err_code = sd_ble_gap_disconnect(0, BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION); APP_ERROR_CHECK(err_code); } err_code = ble_flash_page_erase(FLASH_PAGE_DPI); APP_ERROR_CHECK(err_code); m_advertising_mode = BLE_DIRECTED_ADV; m_direct_adv_cnt = APP_DIRECTED_ADV_TIMEOUT; advertising_start(); dpi_level_store = false; } } //============================================== But another question is what the right value of m_conn_handle?Only 0xffff is for invalid.

[Ole Morten]

If you just need to store a single value, one possibility is to just keep writing to a new address while you are in a connection, and then erase the page and write the new value at the bottom of the page when the link is disconnected for some other reason. If you write a single uint32_t, you would be able to change it 256 times before a page is full, and if you use multiple pages, you could make this number much bigger if needed.

It isn't really feasible to use a longer connection interval with a mouse, since that will cause the movement to be noticeably laggy.

Finally, the recommendation to upgrade your softdevice, SDK and chip revision still stands, and will be the definitely easiest way to solve your problem.