Device connects then disconnects immediately

[apdobaj]

This behavior only occurs when connecting to the phone using the native connection procedure, it does not disconnect when using the nRF Connect app on the phone (Android Pixel 3a). Wireshark and the packet sniffer didn't shed much light, I've played with the connection interval settings, slave latency, update count etc. when I play with the max connection interval and the MTU settings I get a hardware fault.

[Hung Bui]

Please capture and send us a sniffer trace. 

Also please check the disconnect reason when you receive the BLE_GAP_EVT_DISCONNECTED event

[apdobaj]

the code never reaches that case in the ble_evt_handler

static void ble_evt_handler(ble_evt_t const * p_ble_evt, void * p_context)
{
    ret_code_t err_code;

    switch (p_ble_evt->header.evt_id)
    {
        case BLE_GAP_EVT_CONNECTED:
            NRF_LOG_INFO("Connected");
            err_code = bsp_indication_set(BSP_INDICATE_CONNECTED);
            APP_ERROR_CHECK(err_code);
            m_conn_handle = p_ble_evt->evt.gap_evt.conn_handle;
            err_code = nrf_ble_qwr_conn_handle_assign(&m_qwr, m_conn_handle);
            APP_ERROR_CHECK(err_code);
            break;

        case BLE_GAP_EVT_DISCONNECTED:
            NRF_LOG_INFO("Disconnected");
            
            // Dequeue all keys without transmission.
            (void) buffer_dequeue(false);

            m_conn_handle = BLE_CONN_HANDLE_INVALID;

[apdobaj]

Perhaps but in it's native form it doesn't fit into the 192k of flash on the nrf52811, and I had to disable and exclude from the build certain elements such as the sensor simulator. As I mentioned above, the pca10056e example that i modified to fit does exactly the same thing as my code. I'm willing to concede that the issue I'm having is related to the Taiyo Yuden hardware specifically (EYSNSNZWW) but I kind of doubt that's the case. It sure would be nice to know I'm starting with source that's been verified by the manufacturer of the SOC, in this case, Nordic. I followed all the guidelines in the transferring emulated project guide. So to answer your question, no, that's not "exactly" what the pca10056e example is for because that code doesn't fit into 192k of flash without modification. Does my request make more sense now? Let me rephrase - please send me a project that is known to work on the nrf52811 itself, not on an emulated nrf52811. Thanks!

[apdobaj]

Hello, can you run this down? seems a simple request, thanks.

[Hung Bui]

Hi, 
Sorry for the late response, we had the 1st May as a holiday in Norway. 

Could you let me know which compiler are you using ? Do you use any optimization when compiling ? When using optimization level 3 on KEIL I can see the size of the application is about 70kB plus the softdevice size of 100kB it's 170kB total. 

Of course when you compile with debug on and no optimization you will exceed the 192kB of flash. Then you need to choose to remove the logging, some functionalities or run on a nRF52840 emulation. 

[apdobaj]

I am using SES. Optimizing for size doesn't significantly change the flash requirement at all. You say "you need to choose to remove the logging, some functionalities..." , my gosh, this is exactly what I'm referring to. Please specify in detail what those elements are that I need to remove to make it fit into the 192k but without breaking the bluetooth functionality. Aside from that all I need is the keyboard functionality.

[apdobaj]

I have disabled the nrf_log capability, sensor simulator, battery timer, and am still at 134k for the app itself. What else should I disable/remove that won't impact the bluetooth stack?

[Hung Bui]

How do you find your firmware image size ? Please be aware that in our SES project we included the softdevice, so the flash size you see at the build screen is the total flash size, not just the application. 

You can find the actual application flash size using arm-none-eabi-size.exe tool. 

Have a look at this screenshot: 

https://imgshare.io/image/zfWhF