Hi David,

To help isolate the issue, please test the BGX220P board with our BGX Commander Mobile App. You can find instructions in UG440: Wireless Xpress BGX220P SLEXP8031A Kit User's Guide Section 1. Getting Started or on the Getting Started tab on this webpage.

Regards,
Dayoung

Hi Lucas,

These two forum posts should help:

https://www.silabs.com/community/wireless/proprietary/knowledge-base.entry.html/2019/03/18/hfxo_capacitor_bank-7uRt
https://www.silabs.com/community/wireless/bluetooth/forum.topic.html/how_to_set_ctnuein-pgYv

The BSP_CLK_LFXO_CTUNE and BSP_CLK_HFXO_CTUNE values are values that have been specifically calibrated for our reference radio boards, and should not be used if you are using a custom board. If you set the oscillator's CTUNE value incorrectly, it can change the frequency of the oscillator to a point where the BLE doesn't work.

Regards,
Dayoung

Hi Hari,

Every reference to the GG12's USB host indicates that it needs a clock running at 48MHz. It looks like the GG12 has a register called CMU_USBCTRL, which contains the USBCLKSEL bitfield. This bitfield controls which clock is used for the USB, and you can set the it to double the HFXO clock signal. So yes, you should be able to run USB applications using an external 24MHz clock, as long as you set the USBCLKSEL to HFXOX2 (2).

AN0046 was written for our Series 0 devices, although much of it is still relevant for Series 1 USB. This is most likely why the document only states to use an 48MHz crystal, because the Series 0 devices most likely does not have an HFXOX2 setting.

Regards,
Dayoung

Hi Rahul,

Something to note is that our CP210x Linux drivers are a bit more outdated compared to the version developed by the Linux community. Their drivers favor the usb_control_msg function over the ioctl function. We recommend that you look into these drivers, as they are more actively supported by the Linux community, and tends to have better compatibility. You can find more information about it here: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/usb/serial/cp210x.c?h=v5.10.13

Regards,
Dayoung

Hi Eric,

A few things you can look at:

1. The line "SFRPAGE = 0x10" should be located in the very first line of your TIMER16_4_enter_DefaultMode_from_RESET function in order to ensure that you are properly accessing the TMR4CN0 register.
2. Timer4 is using the LFOSC. Did you enable the internal LFOSC? You can enable it using Hardware Configurator, or by adding 

LFO0CN |= LFO0CN_OSCLEN__ENABLED;
while ((LFO0CN & LFO0CN_OSCLRDY__BMASK) != LFO0CN_OSCLRDY__SET);

Regards,
Dayoung

Hi Dawei,

You are correct, in order do to a USART transfer, the device needs to be in EM1 or higher.

Adding 

sl_power_manager_add_em_requirement(SL_POWER_MANAGER_EM1);

before starting the LDMA transfer should work, as long as you have a corresponding

sl_power_manager_add_em_requirement(SL_POWER_MANAGER_EM1);

for when the USART transfer is complete, or your device will never be able to go lower than EM1.

You also need to make sure that for every time you call sl_power_manager_add_em_requirement(SL_POWER_MANAGER_EM1), sl_power_manager_remove_em_requirement(SL_POWER_MANAGER_EM1) is only called once. And for every time you call sl_power_manager_remove_em_requirement(SL_POWER_MANAGER_EM1), sl_power_manager_add_em_requirement(SL_POWER_MANAGER_EM1) must be called once. Calling one of the functions more than the other will either prevent your device from going lower than EM1, or cause an error with Power Manager.

Regards,
Dayoung

Hi Calum,

I looked through the internal source code of the USB_PD library, and found that the CLU3 manually sets one of its inputs to P0.5, expecting the MISO signal. Unfortunately, there is no way to properly reconfigure the CLU3 outside of the library. In order to get the UART bootloader and the USB_PD library to work together would be to modify the bootloader to use UART1 instead of UART0.

Regards,
Dayoung

Hi Calum,

Can you show us the exact code changes you made in order to set the new SPI pins?

Regards,
Dayoung

Hi Saurabh,

I'm not sure what you're asking for. Are you asking how to physically remove the C8051F981 from the development kit? You should be able to desolder the chip by using a hot air gun to blow centralized hot air to the chip. This will melt the solder and you can use tweezers to lift the chip off of the PCB. This video gives you some in-depth information on how to do so. Although the video shows you how to solder using a hot air gun, you should be able to desolder the chip using the same method.

Regards,
Dayoung

Hi Saurabh,

Depending on what you want to do with the RTC, the list of registers to configure varies. One important thing to note is that in order to access the RTC registers, you must unlock the RTC and use the RTC0ADR and RTC0DAT registers to access the internal RTC registers. Instructions on how to do so, along with each register information can be found in Section 20 of the C8051F90 reference manual.

We also have an ample amount of example code in the 8-bit SDK. By default, the example folder path on your PC is C:\SiliconLabs\SimplicityStudio\v5\developer\sdks\8051\v4.1.7\examples\C8051F930DK. The examples that showcase the RTC are the Oscillator_smaRTClock and the SleepMode RTC examples.

Regards,
Dayoung