Quoted from the API ref:

Command Disallowed (0x020C)

Command requested cannot be executed because the Controller is in a state where it cannot process this command at this time.

The code is 0x020C.

Note that the result is in bytes 4-5, LSB first. The last byte is the connection handle.

You are probably getting error 0x020C because you have not stopped scanning before trying to make a connection.

Did another experiment: I placed the function appHandleEvents() in a separate section that I placed at end of flash. This was done following the instructions in this KBA:

https://www.silabs.com/community/mcu/32-bit/knowledge-base.entry.html/2016/03/07/using_a_linker_scrip-s5bu

The change that I made between two versions of the app is limited to appHandleEvents() function, so I expected that placing that code in a dedicated section should make the diff between two files much smaller.

Comparing sector by sector (2048), there are now 34 sectors that do not match. The number is halved compared to my first trial, but still sounds a bit much. Having to update 34 x 2k = 68 kB of code just to get a minor functional change in my app sounds too much. This requires more sophisticated linker magic...

Just for reference, this is the only part in soc-smartphone app that I touched:

#if DO_SMALL_MOD
static int num_connections = 0;
#endif

  switch (BGLIB_MSG_ID(evt->header)) {
    /* Boot event and connection closed event */
    case gecko_evt_system_boot_id:
    case gecko_evt_le_connection_closed_id:

      /* Initialize app */
      appInit(); /* App initialization */
      htmInit(); /* Health thermometer initialization */
      advSetup(); /* Advertisement initialization */

      /* Enter to DFU OTA mode if needed */
#if DO_SMALL_MOD
      if (boot_to_dfu && (num_connections > 0)) {
        gecko_cmd_system_reset(2);
      }
      else
      {
    	  num_connections++;
      }
#else
      if (boot_to_dfu) {
    	  gecko_cmd_system_reset(2);
      }
#endif

I did a quick test. Wrote a piece of C code that reads in two binary files and compares them against each other. The results is not quite what I expected.

My test is based on two versions of the soc-empty example. I took the original example, built it and got binary #1. Then I made a small functional change in the main loop (just some dummy stuff) and compiled again, to get binary #2. The number of code lines that were changed was 4-5.

The result is that when comparing data in 2048 byte chunks, out of 87 sectors there are 68 that do not match. So 78% of the image was changed (because lots of data was shifted around).

If I do the comparison in 16 byte chunks, then the result is not much better. Out of 11231 chunks, 8724 need to be updated.

So a tiny change in source code will result in massive diff between binary content. The content of the binary should be somehow made more organized, so that changing one part does not cause the rest of the data to be shifted.

One idea could be to split the application code into reasonable size modules that are linked to start at sector boundaries, i.e. multiple of 2048. This would require careful design of the app and also some linker magic. I guess it's doable, but this seems to require more effort than I initially thought.

EDIT: maybe telling compiler to generate position independent code could also help here? Now the problem is that all function calls are jumps to absolute addresses and if you do a minor change in the beginning of image, then all subsequent jumps after that change will have a new destination address, resulting in lots of changes (even if 99% of the source code is identical)

I did a quick test. Wrote a piece of C code that reads in two binary files and compares them against each other. The results is not quite what I expected.

My test is based on two versions of the soc-empty example. I took the original example, built it and got binary #1. Then I made a small functional change in the main loop (just some dummy stuff) and compiled again, to get binary #2. The number of code lines that were changed was 4-5.

The result is that when comparing data in 2048 byte chunks, out of 87 sectors there are 68 that do not match. So 78% of the image was changed (because lots of data was shifted around).

If I do the comparison in 16 byte chunks, then the result is not much better. Out of 11231 chunks, 8724 need to be updated.

So a tiny change in source code will result in massive diff between binary content. The content of the binary should be somehow made more organized, so that changing one part does not cause the rest of the data to be shifted.

One idea could be to split the application code into reasonable size modules that are linked to start at sector boundaries, i.e. multiple of 2048. This would require careful design of the app and also some linker magic. I guess it's doable, but this seems to require more effort than I initially thought.

Anybody know of a lightweight diff-match-patch library for C?

I think most of the intelligence can be handled offline. This assumes that you know exactly what is the firmware installed on the target device. Before applying the update, you compare the new binary against the existing binary and see what sectors (2k each) are different. For minimal changes, it could be that you need to replace only one sector.

Then you define some custom file format that includes the sectors to be updated. For each sector, you need to provide the flash offset. The update logic on the target device would then be straightforward: for each sector in the file, erase the old location and the copy the new data into the erased sector.

I have thought about this many times, but never implemented any code for it. If you for example need to change some connection parameters in your application, then the diff between two firmware versions can be really small, just a few bytes here and there. Having to do a full update to achieve that sounds like overkill.

There has not been any discussion about this topic on the forum AFAIK. 

If the linking is done wisely, so that the code that is likely to remain unchanged is placed in one section and the other more dynamic part is linked elsewhere, it could help in producing small diff files between firmware versions. 

I see several alternative ways to implement this. First would be a self-modifying piece of code that is copied to RAM before execution. Second alternative would be to add some custom functionality into Gecko bootloader (which is partly in open source). A third alternative would be to add a secondary bootloader that is placed somewhere in available flash (for example at top of flash, just before the PS area). This bootloader would be only resposible to apply the diff-file so it can be quite small in size.

In the evaluation board those are mapped to PTI (packet trace interface). I don't see why they could not be used as normal GPIO.

How did you create the project for your custom board? Did you set the target as BGM13P32 module (and not some radio board like brd4306B) ? In that case, the project should not include any PTI configurations by default.

I suggest that you search through the project source files for string "pti", that may reveal something.

I did read that same article that you linked when I was working with this same topic. 

Quoted from the article:

The SoftDevice timeslot API allows a top-level application to request access to the radio hardware in between BLE activity. In this example timeslots are used such that normal BLE activity can be run concurrently with the time synchronization functionality.

If I understood correctly, they are bypassing the BLE stack and accessing the radio directly. Similar tricks can be done with the Silabs parts by using the radio directly through RAIL API. I am not too familiar with RAIL, but I think the solution in the linked article can be implemeted on Silabs devices, too.

But it does indeed seem like ble is not the best technology for synchronizing slaves...

The problem is not that BLE would be too limited. I think the real challenge here is that the BLE stack is not exposing all the details you need to complete the task (such as precise timestamp for each received adv.packet). 99.9% of basic BLE users don't care about such details, so it is understandable why Silabs does not include that info in the BLE stack API.

If you want to give it a try, I think you should try to do the time sync receiver directly on top of RAIL.