I think the gecko_sleep_for_ms() has not been designed to work with such long delays. If the upper limit is 131 s (around 2 minutes) then that should be more than enough for 99.99% of applications. 

Have you considered using the blocking API (gecko_wait_event() ) when the device needs to sleep? And then use soft timer with the maximum delay to wake up from sleep. The max delay with soft timer is about 18 hours.

Another idea: since you want to sleep for very long time, what about going to EM4 to get maximal power savings? The downside is of course that you need to come out of EM4 via reset, meaning that your application needs to save and reload its state before/after the sleep period. 

1. Can I rewrite the firmware to log to USB all the time, even when a user is not connected via bluetooth?

2. Can logging of the accelerometer data also be done via USB.

Yes, you can rewrite the firmware to log stuff even without Bluetooth connection. The sample application is available in source code. It may be not that easy to navigate as there are several layers of abstraction. However, if you read through the code you will probably find out that it is quite systematically written.

If you are interested in the accelerometer samples, take a look at the file imus.c and function imuAccelerationStatusChange(). This is the place where the firmware starts a soft timer that is used to trigger accelerometer data sampling. The accelerometer is sampled only if there is a connection and the remote client has enabled it.

To enable continuous accelerometer sampling, you can start the soft timer manually somewhere in the firmware (for example, in the boot event). In other words, add this call somewhere in the init codes:

gecko_cmd_hardware_set_soft_timer(TIMER_MS_2_TIMERTICK(ACCELERATION_MEASUREMENT_PERIOD),
      IMU_SERVICE_ACC_TIMER, false);

Whenever that timer is fired, this function is called: imuAccelerationTimerEvtHandler(). Take a look at the implementation, it is quite straightforward.

One suitable place to do this modification could be the function imuInit() in imus.c.

1. Can I rewrite the firmware to log to USB all the time, even when a user is not connected via bluetooth?

2. Can logging of the accelerometer data also be done via USB.

Yes, you can rewrite the firmware to log stuff even without Bluetooth connection. The sample application is available in source code. It may be not that easy to navigate as there are several layers of abstraction. However, if you read through the code you will probably find out that it is quite systematically written.

If you are interested in the accelerometer samples, take a look at the file imus.c and function imuAccelerationStatusChange(). This is the place where the firmware starts a soft timer that is used to trigger accelerometer data sampling. The accelerometer is sampled only if there is a connection and the remote client has enabled it.

To enable continuous accelerometer sampling, you can start the soft timer manually somewhere in the firmware (for example, in the boot event). In other words, add this call somewhere in the init codes: (for example, see the imuInit() function in imus.c )

gecko_cmd_hardware_set_soft_timer(TIMER_MS_2_TIMERTICK(ACCELERATION_MEASUREMENT_PERIOD),
      IMU_SERVICE_ACC_TIMER, false);

Whenever that timer is fired, this function is called: imuAccelerationTimerEvtHandler(). Take a look at the implementation, it is quite straightforward.

1. Can I rewrite the firmware to log to USB all the time, even when a user is not connected via bluetooth?

2. Can logging of the accelerometer data also be done via USB.

Yes, you can rewrite the firmware to log stuff even without Bluetooth connection. The sample application is available in source code. However, it may be not that easy to navigate as there are several layers of abstraction. However, if you read through the code you will probably find out that it is quite systematically written.

If you are interested in the accelerometer samples, take a look at the file imus.c and function imuAccelerationStatusChange(). This is the place where the firmware starts a soft timer that is used to trigger accelerometer data sampling. The accelerometer is sampled only if there is a connection and the remote client has enabled it.

To enable continuous accelerometer sampling, you can start the soft timer manually somewhere in the firmware (for example, in the boot event). In other words, add this call somewhere in the init codes: (for example, see the imuInit() function in imus.c )

gecko_cmd_hardware_set_soft_timer(TIMER_MS_2_TIMERTICK(ACCELERATION_MEASUREMENT_PERIOD),
      IMU_SERVICE_ACC_TIMER, false);

Whenever that timer is fired, this function is called: imuAccelerationTimerEvtHandler(). Take a look at the implementation, it is quite straightforward.

Maybe I can use the FF Adv data type or 1B le bluetooth device address ?

Using the AD type 0x1B / LE device address is probably the best solution here. Using manufacture specific data (0xFF) would also work, but it is vendor specific (i.e. non standard) and it also requires you to advertise the company ID (two additional bytes) in addition to the device address.

There's no way to advertise a single characteristic. And it's a non-standard way for BLE peripheral to operate so why would you want to go that route, anyway?

Best I can think of is to advertise the Device Information service, UUID 0x180A.  Serial Number char is part of the DI service so this would give a hint to the central that the BT device address is readable via the DI service.

The default BT address is taken from the Unique ID register (64-bit) that is programmed in Silabs production line. It is truly unique, each chip will have a different ID. Therefore you should also not expect to see two EFR32BG chips with same BT address.

For more info, see for example:

https://www.silabs.com/community/wireless/bluetooth/knowledge-base.entry.html/2017/04/28/setting_bluetoothad-ETad

https://www.silabs.com/community/mcu/32-bit/knowledge-base.entry.html/2017/11/01/efm32_and_efr32_seri-uVaX

The BT device address is 6 bytes and it consists of two parts: first 3 bytes are OUI (organizationally unique identifier) and the second half is basically a running number. For example, many Silicon labs Bluetooth devices will have address 00:0B:57:xx:xx:xx.  The prefix 00:0B:57 is registered for Silicon Labs (https://hwaddress.com/oui-iab/00-0B-57/ )

The sample code that you copied above uses two least significant bytes of the address as unique ID. With that approach, you can have up to 65536 unique IDs. If you have 10...15 devices that use an ID generated like this, the probability of having two same IDs is quite low. However, it is not 100% safe. For example, following two addresses would give the same 16-bit ID:

00:0b:57:00:12:34

00:0b:57:11:12:34

If you take the 3 least significant bytes to generate the ID, then the number of possible IDs is 2^24 = about 16 million. Probability of having two same IDs would then be really low.

3. Since the btAddr is Bluetooth public address,  is it secured enough to use the 5 bytes from the btAddr  and assign the device name?

Define what is "secure enough"? It depends on your application. I don't think you need to use 5 bytes, because using 3 LSBs of the unique ID will give you 16M possible ID values.

The default BT address is taken from the Unique ID register (64-bit) that is programmed in Silabs production line. It is truly unique, each chip will have a different ID. Therefore you should also not expect to see two EFR32BG chips with same BT address.

For more info, see for example:

https://www.silabs.com/community/wireless/bluetooth/knowledge-base.entry.html/2017/04/28/setting_bluetoothad-ETad

https://www.silabs.com/community/mcu/32-bit/knowledge-base.entry.html/2017/11/01/efm32_and_efr32_seri-uVaX

The BT device address is 6 bytes and it consists of two parts: first 3 bytes are OUI (organizationally unique identifier) and the second half is basically a running number. For example, many Silicon labs Bluetooth devices will have address 00:0B:57:xx:xx:xx.  The prefix 00:0B:57 is registered for Silicon Labs (https://hwaddress.com/oui-iab/00-0B-57/ )

The sample code that you copied above uses two least significant bits of the address as unique ID. With that approach, you can have up to 65536 unique IDs. If you have 10...15 devices that use an ID generated like this, the probability of having two same IDs is quite low. However, it is not 100% safe. For example, following two addresses would give the same 16-bit ID:

00:0b:57:00:12:34

00:0b:57:11:12:34

If you take the 3 least significant bytes to generate the ID, then the number of possible IDs is 2^24 = about 16 million. Probability of having two same IDs would then be really low.

3. Since the btAddr is Bluetooth public address,  is it secured enough to use the 5 bytes from the btAddr  and assign the device name?

Define what is "secure enough"? It depends on your application. I don't think you need to use 5 bytes, because using 3 LSBs of the unique ID will give you 16M possible ID values.

I think this answers the question: https://stackoverflow.com/questions/8458084/align-in-linker-scripts

AFAIK, the purpose of that line is to make sure that bss begins at word-aligned address.

what happens if I use a handle that is not included in my code? 

I don't get what you mean by this. 

A BLE application based on the Silabs BLE stack will be based on a loop that pops events from the stack and then processes them, typically in a large case statement (see e.g. the soc-empty example ).

If you start a soft timer, you  define three parameters:

1. the number of ticks until the timer is fired
2. handle (or ID) for the timer => this allows having multiple timers running simultaneously
3. the last parameter defines if the timer is one-shot or repeating (= auto-reload)

Regardless of what combination of parameters you use, there will be one or more events generated (of type evt_hardware_soft_timer). Your application main loop will read the events that the stack is producing. If you use any timers in your app, then you probably have a handler for the evt_hardware_soft_timer event. Otherwise, what would be the point of starting any timer in the first place?

In the code that handles evt_hardware_soft_timer, you can check the handle of the timer that expired and do any processing required. For example, you could have one periodic timer that fires every 100ms and another that fires every 5 seconds. If you want to assign handles 0 and 1 for these timers, then you would start them by calling:

gecko_cmd_hardware_set_soft_timer(32768/10, 0, 0); // 100ms timer, handle = 0
gecko_cmd_hardware_set_soft_timer(5*32768, 1, 0); // 5s timer, handle = 1

If you compare to other platforms, it is typical that for each time there is a callback function (or a handler function) that will be invoked when a timer expires. And in those other platforms, there is typically a dedicated callback function for each timer. 

The Silabs BLE stack uses a different approach. There is one common event that is fired when any of the timers expires. Then you need to check based on the handle (it's just an integer value) what is the purpose of that timer. You can easily write your own callback mechanism that will call a function that is specific the timer that just fired.

Something like this:

case gecko_evt_hardware_soft_timer_id:

  switch (evt->data.evt_hardware_soft_timer.handle) {
    case 0:
      periodic_100ms();
      break;
    case 1:
      periodic_5sec();
      break;
    default:
      // this branch is taken if a timer with "unknown handle" is fired. Should not happen
      // unless you are doing something weird
      break;

break;

Hope this clears it up.