Hi Roger,

I believe the 5v connection is mainly there for compatibility with our MCU Starter kits, and isn't actually used to power the device. I Checked over the schematic and the CP2102N USB connection looks to be bus powered, and can route the 5V USB_VBUS to the rest of the device.

The BGX13P looks to be powered by VMCU on the expansion header. 

LED 1 on the BGX13P is powered by VMCU, and is tied to GPIO1 on the BGX device. The behavior of this LED depends on your configuration, as there are many different options for handling the state of GPIO. A common use case is to toggle GPIOs when the device connects or is advertising, but you can change this in configuration.

The full schematic and configuration tools are in Studio, and instructions on how to get to those resources is here. We currently only give access to the schematic files and layout files for the BGX through Studio.

Best,

David

Hi Roger,

I believe the 5v connection is mainly there for compatibility with our MCU Starter kits, and isn't actually used to power the device. I Checked over the schematic and the CP2102N USB connection looks to be bus powered, and can route the 5V USB_VBUS to the rest of the device.

The BGX13P looks to be powered by VMCU on the expansion header. 

LED 1 on the BGX13P is powered by VMCU, and is tied to GPIO1 on the BGX device. The behavior of this LED depends on your configuration, as there are many different options for handling the state of GPIO. A common use case is to toggle GPIOs when the device connects or is advertising, but you can change this in configuration.

The full schematic and configuration tools are in Studio, and instructions on how to get to those resources is here. We currently only give access to the schematic files and layout files for the BGX through Studio.

Best,

David

Hi Roger,

I believe the 5v connection is mainly there for compatibility with our MCU Starter kits, and isn't actually used to power the device. I Checked over the schematic and the CP2102N USB connection looks to be bus powered, and can route the 5V USB_VBUS to the rest of the device via VDD.

The BGX13P looks to be powered by VMCU on the expansion header. 

LED 1 on the BGX13P is powered by VMCU, and is tied to GPIO1 on the BGX device. The behavior of this LED depends on your configuration, as there are many different options for handling the state of GPIO. A common use case is to toggle GPIOs when the device connects or is advertising, but you can change this in configuration.

The full schematic and configuration tools are in Studio, and instructions on how to get to those resources is here. We currently only give access to the schematic files and layout files for the BGX through Studio.

Best,

David

Hi JQ,

BGX can't support the concurrent roles that you mention. Mainly the roles of central and peripheral are considerations during advertising and connection/pairing. Once they are connected the xpress service is bidirectional. Only a single central-peripheral connection can be active at one time, see:

https://docs.silabs.com/gecko-os/1/bgx/latest/ble-services

You could in theory quickly switch between them but the behavior you are describing is dual topology, which is supported by our programmable bluetooth modules (for an example of this, see KBA_BT_0906). However BGX does not currently support this. 

Best,

David

Hi JQ,

BGX can't support the concurrent roles that you mention. Mainly the roles of central and peripheral are considerations during advertising and connection/pairing. Once they are connected the xpress service is bidirectional. Only a single central-peripheral connection can be active at one time, see:

https://docs.silabs.com/gecko-os/1/bgx/latest/ble-services

You could in theory quickly switch between them but the behavior you are describing is dual topology, which is supported by our programmable bluetooth modules (for an example of this, see KBA_BT_0906). However BGX does not currently support this. 

Best,

David

Hi JQ,

BGX can't support the concurrent roles that you mention. Mainly the roles of central and peripheral are considerations during advertising and connection/pairing. Once they are connected the xpress service is bidirectional. Only a single central-peripheral connection can be active at one time, see:

https://docs.silabs.com/gecko-os/1/bgx/latest/ble-services

You could in theory quickly switch between them but the behavior you are describing is more like a mesh network, which BGX does not currently support. 

Best,

David

Hi,

If for your application you only care to interrupt on one edge, the IRISE and IFALL bits can be configured in the ACMPn_CTRL register. This corresponds to the .interruptOnRisingEdge and .interruptOnFallingEdge fields of the initialization struct. From your code it looks like you are only enabling the falling edges, but if you see interrupts on rising edge events it may be the case that the IRISE bit has been set unintentionally. I'd confirm that IRISE is 0 when the ACMP is running.

If you need to process both rising and falling edges, but need to determine the state, you will need to still for both edges and poll the ACMPOUT bit in the ACMPn_STATUS register to determine state. 

Best,

David

Ah my mistake I provided links for the TG11 rather than the series 0 tiny gecko.

For the series 0 github example though the project should have had a TG project file but as you said it is missing. The EFM32G project should be compatible with the Tiny gecko though. You can change the target of the project from EFM32G to EFM32TG by right clicking on the project and selecting the project properties->board/part/sdk tab in Studio. The actual source file, main_s0, should apply to all series 0 MCU's. 

The BGX exp board is not directly compatible with the EFM32TG starter kit, as the expansion header pins 12 and 14 map to PD4 and PD5 on the TG stk, which aren't UART pins. However you could add your own wires to connect one of the optional TG UART pins to the BGX header. Below is a screencap from the EFM32TG datasheet showing the pinout options:

The efm32tg starter kit users guide can be downloaded with the following documentation package:

https://www.silabs.com/documents/public/user-guides/efm32-stk-documentation.zip

Hi,

We do not have a specific library for interfacing with the BGX over UART, but as the BGX UART is a very standard configuration, you can use our generic UART examples as a starting point.

For emlib UART examples with TG11, we have a github example showing generic interrupt driven UART TX/RX.

https://github.com/SiliconLabs/peripheral_examples/blob/master/series1/usart/async_interrupt/src/main_s1_tg11.c

All that is needed to connect the UART with the BGX expansion board is to change the UART pin routing. The expansion header pins on the TG11 board are described in section 4.2 of the users guide:

https://www.silabs.com/documents/public/user-guides/ug303-stk3301.pdf

and the UART pin routing options are described in section 5.15 of the datasheet:

https://www.silabs.com/documents/public/data-sheets/efm32tg11-datasheet.pdf

Once this is done, you just need to send the BGX api commands over the UART channel. 

Another example we have is the GG11's vcom example in the SDK. This shows how to retarget getchar() and printf() to output data on a UART channel. Similarly to the previous example this can be interfaced with the BGX by routing the UART pins to the expansion header.

To ensure the reliability of a device that is drawing power, there is a maximum safe junction temperature (Tj) that should not be exceeded during the lifespan of the part. 

The standard for this maximum temperature is around 150 C, and devices expected to source/sink large amounts of current, or operate in high temperature environments need to have this maximum temperature considered. 

The ability for a device to dissipate heat is characterized by its thermal resistance to difference interfaces. These interfaces are the ambient air (Rth ja), the PCB (Rth jb) and the package or case (Rth jc). These values are measured in degrees celsius per watt (C/W). These values can help understand the limits of safe operation for a device for given conditions.

Our C8051F50x devices do not include this value in the datasheet, but we have characterized these values for the typical case. These are listed below. Note that these values are not guaranteed maximums, and only estimate the values across devices.