this is because you are using a 8 bit cpu

so a 16 bit int will be incremented / decremented in multiple cpu cycles.

So if the interrupt fires when cnt_pressed_time = 0x100  and the while loop has checked the low byte of cnt_pressed_time for 0 (witch is true)

then the interrupt decreses the cnt_pressed_time value to 0xFF.

Then the while function continues on checking the high byte witch is 0 at this time and so for the while loop both bytes are 0 zo the while can break.

Simple.

You can implement an IF statement in your interrupt service routine to set a flag used in the main loop for turning on/off an LED to avoid handling an interrupt in the middle of main loop processing a 16-bit (2-byte) compare.

You can implement an IF statement in your interrupt service routine to set a flag used in the main loop for turning on/off an LED to avoid handling an interrupt in the middle of main loop processing a 16-bit (2-byte) compare.

The "Simple Transport Firmware" block diagram references in AN945 are meant as an high-level software block to be implemented on an embedded host. We currently do not have an example UART bootloader loading application or source code in either in C or C++ Languages, only the Python-based version available in the software associated with this application note. Section 7. Bootloader Protocol of AN945 goes into detail regarding UART formatting and the bootloader command protocol so that developers can implement their own "Simple Transport Firmware" block, such as this implementation developed to run on a Linux machine - https://gglabs.us/node/2085

With regards to the UART connections, the UART transmit pin of the host should connect to the UART receive pin of your EFM8SB2 and the UART receive pin of the host should connect to the UART transmit pin of the EFM8SB2. For the EFM8SB2, UART0 TX0 and RX0 are routed to port pins P0.4 and P0.5 respectively. Bootmode entry pin is routed to P2.7. See section 5.3.1 Entering Bootload Mode of AN945 for more details regarding the various ways to enter bootlaoder mode.

Is it possible to coonect BGX13S22 to BlueTooth COM port of a PC (Win64)?

No. The WT12 is a Bluetooth Classic device and BGX is Bluetooth Low Energy. The serial port profile is only supported on Bluetooth classic, there is no equivalent GATT profile or service on Bluetooth Low Energy.

Have you considered the BT121 instead?

https://www.silabs.com/wireless/bluetooth/bluegiga-classic-legacy-modules/device.bt121-a

What device are you currently developing on? IADC suggests to me you are using a Series 2 device.

The DMADRV was originally written for our Series 0, and has quite a bit of overhead (callbacks, for example) compared to using the emlib structure and function calls. I would recommend taking a look at our IADC peripheral examples available on GitHub, specifically our IADC with LDMA example available here: https://github.com/SiliconLabs/peripheral_examples/tree/master/series2/iadc/iadc_scan_ldma

1 EFM8LB1_UART0_Interrupt.

2 EFM8LB1_UART1_Lib_Autobaud_Buffer

demo can not work

How you determine that EFM8LB1_UART0_Interrupt can not work?

on my side it works fine.

and  EFM8LB1_UART_Lib_Buffer ,which can only work at br 115200,when I modified the code to set another br value，it can not work well.

the CDC UART (VCOM) only support 115200. I think that is the reason you see the failure.

https://www.silabs.com/community/mcu/8-bit/knowledge-base.entry.html/2016/07/18/no_effect_to_change-en32

What do you mean by "in simulator mode in  simplicity studio"?

If you are trying to simulate to run code without a device connected, I don't think that (all features) was supported.

You are correct. The convert and gbl create commands do not support .gbl files as inputs. I apologize for the confusion.

The last commander setup you list is correct:

commander gbl create app_btl_update.gbl --app application.s37 --bootloader bootloader.s37 --compress lzma

As I mentioned before, the bootloader and metadata are never compressed. The bootloader is supposed to be relatively small, therefore there is not a significant space savings in compressing this portion. Also by doing so, this allows for a bootloader upgrade to one that supports compression. You're observation that the .gbl files are the same size when creating just the bootloader .gbl with or without compression is expected.

Only the application upgrade data is compressed, and this data stays compressed while being transferred to the device and stored in the upgrade area. A CRC check by the main bootloader verifies the update image with the CRC provided in the GBL end tag. I'm not sure what you mean that "the gbl will be recognized as non valid". Only after rebooting into the new bootloader will the application image get decompressed as part of the upgrade process. The verification step occurs on the upgrade image prior to reboot and attempted application upgrade.

Sections 4.2 Bootloader Upgrade on Application Bootloaders With Storage and 7.2 Compressed Upgrade Images of UG266: Silicon Labs Bootloader User's Guide go into more detail.

This is expected behavior as the example is using the LEUART using the single data-link configuration described in the reference manual. This means that half-duplex uses only one wire to communicate between LEUARTs, the LEUART both receives and transmits data on the same pin. This is enabled by setting LOOPBK in LEUARTn_CTRL, which connects the receiver to the transmitter output.

Because they are both connected to the same line, it is important that the LEUART transmitter does not drive the line when receiving data, as this would corrupt the data on the line. When communicating over a single data-link, the transmitter must therefore be tri-stated whenever not transmitting data. In this example, the AUTOTRI in LEUARTn_CTRL is set, thus the LEUART automatically tristates LEUn_TX whenever the transmitter is inactive, which is causing the voltage droop observed after transmitting each character. Section 19.3.7.1 Single Data-Link in the EFM32WG Reference Manual goes into more detail about the single data-link configuration and alternative options of ensuring the pin is tri-stated when not transmitting data.