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

Issues with writting/reading data and flash writing

Hello! I am useing nRF52832 with custom-made board.

SD 5.0.0 and 14.0 SDK

I am using modificated example of "ble_app_template", i added simple custom service from example "ble_cus" and try to communicate with android application. I can't share all code, but i have some problems and i need help.

1. When i receive data from phone I need to process, verifie it in the on_cus_evt hundler (BLE_CUS_EVT_WRITE). How much time can I spent in this hundler? Is there are any suggestions, based on the communication duration, or other details? Code:

static void on_cus_evt(ble_cus_t     * p_cus_service, ble_cus_evt_t * p_evt)
{
    ret_code_t err_code;

    switch(p_evt->evt_type)
    {
        case BLE_CUS_EVT_NOTIFICATION_ENABLED:
            uart_send_string(1, "BLE_CUS_EVT_NOTIFICATION_ENABLED");
            err_code = app_timer_start(m_notification_timer_id, NOTIFICATION_INTERVAL, NULL);
            APP_ERROR_CHECK(err_code);
            break;

        case BLE_CUS_EVT_NOTIFICATION_DISABLED:
            uart_send_string(1, "BLE_CUS_EVT_NOTIFICATION_DISABLED");
            err_code = app_timer_stop(m_notification_timer_id);
            APP_ERROR_CHECK(err_code);
            break;

        case BLE_CUS_EVT_CONNECTED:
            break;

        case BLE_CUS_EVT_DISCONNECTED:
            User_disconnect();
            uart_send_string(1, "BLE_CUS_EVT_NOTIFICATION_DISABLED");
            err_code = app_timer_stop(m_notification_timer_id);
            APP_ERROR_CHECK(err_code);
            break;

        case BLE_CUS_EVT_WRITE:
            {
              memset(TX_buffer, 0x00, sizeof(TX_buffer));
              uint32_t duration = (RX_buffer[1]<<16)+(RX_buffer[2]<<8)+RX_buffer[3];
              
              switch(Verification)
              {
                case 0://ID verification
                {
                ....

2. I receive data from phone, process them, wait 100ms delay and then send answer - is it ok? I found that it is not good to answer right after processing in the handler function (on_cus_evt).

3. I am using "just work" pairing (it's sad that android can't work without pairing), and i see that bonding information is saved in the penultimate page of the memory - is it normal? Because i need to use the last page to save some information and i need one more page, but when i tried to use penultimate page i had error and couldn't connect with phone one more time because of missing bonding information (i erase it when try to save information on the penultimate page).

4. I am using flash write and erase functions with delay 200ms between erasing and writing page, and sometimes i see page writing reboots my chip. Can someone check my code?

static void FLASH_WRITE(uint32_t page, uint32_t * const flash_from, uint32_t * flash_to, uint32_t size)
{
  //erase flash page
  flash_error = sd_flash_page_erase(page);
  uart_send_string(1, "Flash has been erased");

  //delay between erase and flash
  flash_delay=1;
  app_timer_start(m_flash_id, FLASH_WRITE_INTERVAL, NULL);
  while(flash_delay==1)

  //write data to flash
  flash_error = sd_flash_write(flash_to, flash_from, size);
  uart_send_string(1, "Flash has been written");
}

Thank you!

  • Hello,

    1. There is no max delay, but I recommend to keep it lower than the connection interval.

    2. There should be no need to wait for 100ms, if data is ready send it immediately.

    3. I recommend to implement peer manager (and fds) which will handle security procedures and storing of bonds. Typically the security procedure will depend on the read and write permissions you set when init services, it should be possible to replace all instances of BLE_GAP_CONN_SEC_MODE_SET_ENC_NO_MITM and BLE_GAP_CONN_SEC_MODE_SET_ENC_WITH_MITM with BLE_GAP_CONN_SEC_MODE_SET_OPEN to avoid bonding.

    4. You may have assert, if you define DEBUG you can typically find where the assert occurs from app_error_fault_handler().

    Best regards,
    Kenneth

     

Related