Hi Eddie,

1) To find the address ranges for the different regions of memory (i.e. code, RAM, etc.), lease refer t the device datasheet.  In this case, for the C8051F387, please refer to the C8051F38x datasheet, Figure 13.2. On-Chip Memory Map for 32 kB Devices (C8051F382/3/6/7), page 94.

2) For using the output "hex" (really a text listing) file in the download tab to reprogram the device, try entering the start address for the upload in the "Target file start address (HEX)" (probably 0x0000).  

I hope this helps.  Let me know if you have any questions.

Regards,

Mitch

Hi James,

1) Your schematic symbol indicates you are using the CP2102N, which requires a voltage divider on the VBUS pin to prevent any over voltage damage.  This is explained in the following knowledge base article:

https://www.silabs.com/community/interface/knowledge-base.entry.html/2018/03/31/cp2102n_requiresav-NFly

2) To reiterate what user luweiguo said, the TVS diodes are recommended on D+, D-, and VBUS.

3) For each power pin (VREGIN, VDD, 0.1 uF and 4.7 uF parallel bypass capacitors are recommended.

4) Typically, the recommended pullup resistor value for the RSTn pin is 1 k ohm.

This information is also contained in the CP2102N datasheet, for your reference:

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

I hope this helps.

Regards,

Mitch

Hi Megumi Saito,

Thank you for your inquiry regarding the free Keil PK51 toolchain for Silicon Labs C8051 and EFM8 devices.  I have a couple suggestions:

1) Simplicity Studio v3 has long been superseded by Simplicity Studio v4.  I recommned that you download and install Simplicity Studio v4:

https://www.silabs.com/products/development-tools/software/simplicity-studio

2) You can install the Keil toolchain as a part of your Simplicity Studio installation or by adding this using the package manager, and then obtain a free Keil PK51 license. 

Silicon Labs offers a free license for use with the Keil PK51 toolchain and Silicon Labs 8-bit MCU devices.  To obtain this license, please go to the following website, fill in your information in the form, and click [Submit]:

https://pages.silabs.com/lp-keil-pk51.html

Then follow the instructions in the following knowledge base article update to license your toolchain installation:

https://www.silabs.com/community/wireless/proprietary/knowledge-base.entry.html/2016/04/06/free_keil_pk51_licen-JhW7

I hope this helps.  Please let me know if you have any questions.

Regards,

Mitch

Hi Lorenzo,

Thank you for your question regarding the CP2102 pinout.  To clarify, the CP2102 and the CP2102N are different parts:

CP2102: https://www.silabs.com/documents/public/data-sheets/CP2102-9.pdf

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

You are correct that on the CP2102, pin 17 is "NC", whereas on the CP2102N-QFN28, pin 17 is GPIO.2 / RS485.  On the CP2102N, this pin can be configured as a general GPIO pin or as a special function output to be used as an RS485 transceiver enable signal.

I hope this helps, and please let us know if you have any questions.

Regards,

Mitch

Hi Lorenzo,

Thank you for your question regarding the CP2102 pinout.  To clarify, the CP2102 and the CP2102N are different parts:

CP2102: https://www.silabs.com/documents/public/data-sheets/CP2102-9.pdf

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

You are correct that on the CP2102, pin 17 is "NC", whereas on the CP2102N-QFN28, pin 17 is GPIO.2 / RS485.  On the CP2102N, this pin can be configured as a general GPIO pin or as a special function output to be used as an RS485 transciever enable signal.

I hope this helps, and please let us know if you have any questions.

Regards,

Mitch

Introduction

EFR32 devices allow the JTAG TDI/TDO pins to be used for other functions when not needed for JTAG debugging. Under certain circumstances, such as an unexpected reset during debug, control of these pins can unexpectedly be transferred to the debug peripheral. On Series 2 devices this happens more frequently due to changes in the reset topology. In such cases, the device must be reset again to regain normal control over the pins.

Background

JTAG and SWD

EFR32 supports debugging through either the JTAG or the SWD protocol. The JTAG protocol is an industrial standard for testing and verifying PCBs that utilizes 4 pins; TCK, TMS, TDI and TDO. SWD is an ARM proprietary protocol that is interoperable with a JTAG test environment, but utilizing only two pins, the TCK and TMS pins.

Debug Port

The Serial Wire/JTAG Debug Port (SWJ-DP) is responsible for implementing both the JTAG and the SWD interface. The SWJ-DP also facilitates for switching between the two protocols on demand.

The SWJ-DP allows a designer to allocate the JTAG TDI and TDO pins to other functionality, such as GPIO, when only using the SWD interface. 

On startup the SWJ-DP will, for compatibility reasons, default to JTAG mode. In order to switch to SWD mode, a debugger will have to transmit a specific initialization sequence on the TCK and TMS pins. This initialization sequence is designed such that it will not affect any JTAG devices on the same bus.

JTAG-on-demand

JTAG-on-demand is an EFR32-specific feature that allows an EFR32 device to appear as defaulting to SWD mode. This means that the TDI and TDO pins are allocated as normal GPIO at startup instead of being allocated to the debug interface.

JTAG-on-demand will reallocate the TDI and TDO pin to the debug interface when the SWJ-DP is in JTAG mode and detects JTAG traffic. Once JTAG-on-demand has been activated, it will not be deactivated until the next full reset of the chip (and debug interface).

JTAG-on-demand can be overridden by writing to the GPIO.DBGROUTEPEN register. Attempting to write the relevant bits while the debug circuitry is active will cause a BusFault on Series 2 devices.

Series 2 reset topology

EFR32 Series 2 devices have a different reset topology than EFR32 Series 1 devices. The most notable change is that in Series 2 devices the debug interface is reset on assertion of the RESETn pin.

Error Conditions

If anything except the full SWD initialization sequence is received by the EFR32 on the debug interface while the SWJ-DP is in JTAG-mode, JTAG-on-demand will activate and transfer control of the TDI and TDO pins to the SWJ-DP.

When control of the pins has been transferred, the pins cannot be used in any other function, including normal GPIO, SWO or ETM Trace.

There are two scenarios in which loss of control over TDI and TDO is likely to occur:

• If the EFR32 is reset in a way that causes the debug interface to be reset while there is an active SWD debug session. For Series 2 device, this includes reset via the RESETn pin. The debug adapter will be unable to detect this reset in all circumstances, causing the debug adapter to continue communicating over SWD, activating the JTAG-on-demand feature.
• If the debug adapter attempts to initialize the SWD connection before the EFR32 has fully exited reset so that the SWD initialization sequence is not registered. This causes JTAG-on-demand to activate when verifying the connection as required by ARM.

While it is possible for this to occur on EFR32 Series 1 devices, it is a lot easier to trigger on Series 2 devices due to the change in reset topology. It is also not possible to override the JTAG-on-demand feature on Series 2 devices, contrary to Series 1 devices where this is possible.

Consequences

When JTAG-on-demand is activated on an EFR32 Series 2 device, the following will happen

• SWO will stop working
• ETM Trace will stop working
• Loss of control over GPIO pins PA3/PA4

For Silicon Labs development kits, the following are features that can be affected depending on what is connected to PA3/PA4:

• VUART
• Simplicity Studio Code Correlation
• External SPI Flash
• VCOM Flow Control (CTS always high)
• Button stuck high

Workaround

Once the condition occurs, the only known workaround is to disconnect all active debug sessions, reset the target through the RESETn pin or toggling power.

Glossary

Introduction

EFR32 devices allow the JTAG TDI/TDO pins to be used for other functions when not needed for JTAG debugging. Under certain circumstances, such as an unexpected reset during debug, control of these pins can unexpectedly be transferred to the debug peripheral. On Series 2 devices this happens more frequently due to changes in the reset topology. In such cases, the device must be reset again to regain normal control over the pins.

Background

JTAG and SWD

EFR32 supports debugging through either the JTAG or the SWD protocol. The JTAG protocol is an industrial standard for testing and verifying PCBs that utilizes 4 pins; TCK, TMS, TDI and TDO. SWD is an ARM proprietary protocol that is interoperable with a JTAG test environment, but utilizing only two pins, the TCK and TMS pins.

Debug Port

The Serial Wire/JTAG Debug Port (SWJ-DP) is responsible for implementing both the JTAG and the SWD interface. The SWJ-DP also facilitates for switching between the two protocols on demand.

The SWJ-DP allows a designer to allocate the JTAG TDI and TDO pins to other functionality, such as GPIO, when only using the SWD interface. 

On startup the SWJ-DP will, for compatibility reasons, default to JTAG mode. In order to switch to SWD mode, a debugger will have to transmit a specific initialization sequence on the TCK and TMS pins. This initialization sequence is designed such that it will not affect any JTAG devices on the same bus.

JTAG-on-demand

JTAG-on-demand is an EFR32-specific feature that allows an EFR32 device to appear as defaulting to SWD mode. This means that the TDI and TDO pins are allocated as normal GPIO at startup instead of being allocated to the debug interface.

JTAG-on-demand will reallocate the TDI and TDO pin to the debug interface when the SWJ-DP is in JTAG mode and detects JTAG traffic. Once JTAG-on-demand has been activated, it will not be deactivated until the next full reset of the chip (and debug interface).

JTAG-on-demand can be overridden by writing to the GPIO.DBGROUTEPEN register. Attempting to write the relevant bits while the debug circuitry is active will cause a BusFault on Series 2 devices.

Series 2 reset topology

EFR32 Series 2 devices have a different reset topology than EFR32 Series 1 devices. The most notable change is that in Series 2 devices the debug interface is reset on assertion of the RESETn pin.

Error Conditions

If anything except the full SWD initialization sequence is received by the EFR32 on the debug interface while the SWJ-DP is in JTAG-mode, JTAG-on-demand will activate and transfer control of the TDI and TDO pins to the SWJ-DP.

When control of the pins has been transferred, the pins cannot be used in any other function, including normal GPIO, SWO or ETM Trace.

There are two scenarios in which loss of control over TDI and TDO is likely to occur:

• If the EFR32 is reset in a way that causes the debug interface to be reset while there is an active SWD debug session. For Series 2 device, this includes reset via the RESETn pin. The debug adapter will be unable to detect this reset in all circumstances, causing the debug adapter to continue communicating over SWD, activating the JTAG-on-demand feature.
• If the debug adapter attempts to initialize the SWD connection before the EFR32 has fully exited reset so that the SWD initialization sequence is not registered. This causes JTAG-on-demand to activate when verifying the connection as required by ARM.

While it is possible for this to occur on EFR32 Series 1 devices, it is a lot easier to trigger on Series 2 devices due to the change in reset topology. It is also not possible to override the JTAG-on-demand feature on Series 2 devices, contrary to Series 1 devices where this is possible.

Consequences

When JTAG-on-demand is activated on an EFR32 Series 2 device, the following will happen

• SWO will stop working
• ETM Trace will stop working
• Loss of control over GPIO pins PA3/PA4

For Silicon Labs development kits designed by the Hardware Tools Team, the following are features that can be affected depending on what is connected to PA3/PA4:

• VUART
• Simplicity Studio Code Correlation
• External SPI Flash
• VCOM Flow Control (CTS always high)
• Button stuck high

Workaround

Once the condition occurs, the only known workaround is to disconnect all active debug sessions, reset the target through the RESETn pin or toggling power.

Glossary

Hi Fran,

Yes, it appears that the SmaRTClock input to the PCA was a mistake in the version of the datasheet you referenced and is now corrected in the public version.  I think one solution I can see to this may be that you have to choose SmartClock Osc as the source oscillator for SYSCLK and route SYSCLK to pin.  If you must do that, is may be possible that you can still use the UART at 9600 bps or some lower baud rate even with a 32.768 kHz SYSCLK.  Perhaps this is a workable solution if this is a one-time calibration and not something you need incorporated into your user application.  

I hope this helps.

Regards,

Mitch

Hello,

Thank you for your inquiry about using the RTCDRV module with EFM32GG11 and porting your solution from EFM32WG (Series 0) to EFM32GG11 (Series 1).  RTCDRV is designed to make the underlying hardware timer used by the module (i.e. RTC vs. RTCC) transparent to the user, and this selection will generally be handled automatically behind the scenes based on project configurations, which are in turn based on the specific device target and the peripherals that target has available.  Thus, rather than being a configuration option available to the user, the selection of RTC vs. RTCC is determined by the software module based on which series you are targeting.  Note that the user-configurable options can be found in the module file 'rtcdrv_config.h.'

Although I will not list every instance in the RTCDRV code that is affected by the use of RTC vs RTCC, I can point out that the reason simply changing the defines "RTCDRV_USE_RTC" vs "RTCDRV_USE_RTCC" does not work is that there are architectural differences in the RTC peripheral between Series 0 and Series 1 EFM32 devices.  For instance, the EFM32WG RTC has 2 compare channels, whereas the EFM32GG11 RTC has 6, which explains the specific COMP0 IF compile issue that you mention. 

Similarly, as you mention, when the module is directed to use RTCC by project defines based on having a Series 1 target, the module will configure the LFECLK (used by RTCC), which does not exist on Series 0 devices.  On both Series 0 and Series 1 targets, the RTC runs on the LFACLK.

I recommend reviewing the EFM32WG Reference Manual (chapter 21, page 721) and EFM32GG11 Reference Manual (chapter 13, page 517) for a comparison of the two RTC peripherals.  

In your EFM32GG11 port, can you use the RTCC for RTCDRV (as the module wants to do by default) and instead use the RTC for your FreeRTOS tickless mode?

I hope this helps, and please let me know if you have any questions.

Regards,

Mitch

Hello,

Thank you for your inquiry about using the RTCDRV module with EFM32GG11 and porting your solution from EFM32WG (Series 0) to EFM32GG11 (Series 1).  RTCDRV is designed to make the underlying hardware timer used by the module (i.e. RTC vs. RTCC) transparent to the user, and this selection will generally be handled automatically behind the scenes based on project configurations, which are in turn based on the specific device target and the peripherals that target has available.  Thus, rather than being a configuration option available to the user, the selection of RTC vs. RTCC is determined by the software module based on which series you are targeting.  Note that the user-configurable options can be found in the module file 'rtcdrv_config.h.'

Although I will not list every instance in the RTCDRV code that is affected by the use of RTC vs RTCC, I can point out that the reason simply changing the defines "RTCDRV_USE_RTC" vs "RTCDRV_USE_RTCC" does not work is that there are architectural differences in the RTC peripheral between Series 0 and Series EFM32 devices.  For instance, the EFM32WG RTC has 2 compare channels, whereas the EFM32GG11 RTC has 6, which explains the specific COMP0 IF compile issue that you mention. 

Similarly, as you mention, when the module is directed to use RTCC by project defines based on having a Series 1 target, the module will configure the LFECLK (used by RTCC), which does not exist on Series 0 devices.  On both Series 0 and Series 1 targets, the RTC runs on the LFACLK.

I recommend reviewing the EFM32WG Reference Manual (chapter 21, page 721) and EFM32GG11 Reference Manual (chapter 13, page 517) for a comparison of the two RTC peripherals.  

In your EFM32GG11 port, can you use the RTCC for RTCDRV (as the module wants to do by default) and instead use the RTC for your FreeRTOS tickless mode?

I hope this helps, and please let me know if you have any questions.

Regards,

Mitch