"On a two-or-more-layer printed circuit board (recommended): - The area on the reverse side of the board behind the sensor should be filled with a hatched ground pattern (10% fill). Section “3.2.1. Electric Field Interference” describes the design of shields."
Section 3.2.1 says:
"Electric fields in the environment induce voltage in capacitive sensors and their routing to the CS0 converter. Proper ground shielding is used to reduce its effect. Each sensor must have a ground plane behind it, covering the entire area of the sensor. [...] the ground pattern need only be very lightly hatched: a 10% hatch pattern is not too light."
To connect a debugger to an 8-bit part (C8051 or EFM8) on a custom board, you will need either an EFM8 STK or a USB Debug Adapter (UDA). You will need to connect the signals C2CK, C2D, and ground to the target board. Note that the debugger does not provide power for the target board. A schematic of the EFM8 STK can be found in Simplicity Studio. Here is a schematic and pinout of the UDA.
When designing the target board, you should place bypass capacitors (0.1 µF and 4.7 µF) between VDD and ground. C2CK should have a pull up resistor (no more than 10kOhm, 1kOhm recommended) to VDD. Do not connect any capacitors to C2CK.
For layout, the bypass capacitors should be close to the part, the C2CK and C2D lines shouldn't be routed too close to high frequency signals (such as UART or SPI), and they should go through as few vias as possible. It is also a good idea to have a ground plane on the other side of the part and these signals.
What is the endurance of the EEPROM emulation using AN568?
The endurance will depend on the sector size and flash page size. If there are N sectors in the flash page, each page will be erased every 2*N writes. From this, you can expect the endurance to be 2*N more than the flash endurance, which is listed in the device's datasheet. For the BB1 family, minimum endurance is 20,000 cycles and typical is 100,000 cycles.
Does the DTMF generator in AN218 provide "twist" (different amplitude of the two tones)?
The example does not provide twist and outputs the two tones at the same amplitude. Twist can be implemented by creating two sinusoidal look up tables in the PCA0 ISR in place of the one array (sine_table) in the existing example. Then, adjust the amplitude of each table relative to each other to create the twist.
Can the Universal Bee product with the charger detect built-in detect all battery chargers?
The charge detection is compatible to the USB BC1.2 specification, so it can handle chargers compliant to that standard and provide the interrupt response based on the charger configuration as it passes through the stages of detection.
For chargers that may not be compliant and set their own proprietary voltages on the D+/D- pins, you can use the ADC to monitor those voltages. D+/D- inputs are brought to the ADC input mux internally for this purpose (ADC0.28 and ADC0.29 on EFM8UB1). The voltage reference for the ADC is flexible as well so you can accommodate different ADC input voltage ranges up to VDD of 3.3V.
The charge detect sequencing is controlled via the firmware. For example, once you perform the initial data contact detect, the firmware can enable the next phase or primary detection, and so on. The firmware controls the peripheral settings (enable/disable) and can decouple each scenario. For the chargers that would require the ADC, you can measure D+/D- after VBUS detection before going through the data contact detection sequence.
These guidelines apply for both EFM32 and C8051/EFM8.
There should be a ground plane on side of the board that has sensors (usually the top side). There should be a hatched ground on the opposite side of the sensors (usually the bottom side). Traces between the sensors and pins should be as short as possible, not criss-crossed or running through stitching vias, and not run parallel to high frequency switching signals sucha s SPI or PWM signals.
What is happening when the SDA signal is held low by the MCU? Is there a way to detect and recover?
It is possible for the MCU to get into an erroneous state due to noise that appears as extra transitions on the I2C SCK. There is no hardware equivalent of SCL low timeout for the SDA signal. The failure can be detected in software by checking if the SDA pin is held low for an unreasonable amount of time. When this failure is detected, disabling and re-enabling the SMBus will fix the problem.
Are EFM8 UIDs and UUIDs guaranteed to be unique for all time?
The short answer is no.
EFM8 families have a 32-bit unique identifier (UID) or a 128-bit universally unique identifier (UUID).
The number of unique combinations for a 32-bit number is 2^32 (4,294,967,296). Once Silicon Labs manufactures this quantity of a single MCU part number, the ID will no longer be unique.
The number of unique combinations for a 128-bit number is 2^128 (340,282,366,920,938,463,463,374,607,431,768,211,456). Once Silicon Labs manufactures this quantity of a single MCU part number, the ID will no longer be unique. Although this number is not guaranteed to be unique for all time, this UUID is considered "practically unique" because it is not likely that this quantity of a single MCU part number will ever be manufactured.
The only way to guarantee uniqueness would be to use your own process/serial number.
However, the EFM8 header files (SI_EFM8*_Defs.h and SI_EFM8*_Register_Enums.h) included with Simplicity Studio currently do not support IAR. To add IAR support, si_toolchain.h (included by SI_EFM8*_Defs.h) will need to be modified.
Attached below is a IAR project for the EFM8BB1 blinky example with the modified si_toolchain.h.
How is the current consumption affected in the C8051F36x family when the prefetch engine is disabled?
There are a couple consequences of disabling the prefetch engine in CCH0CN:
Disabling the prefetch engine would likely cause a dramatic number of cache misses and cause the core to stall as instructions are fetched from flash. This would be especially problematic in a loop, which would involve at least a couple branches (more specifically, jumps) per loop iteration on top of the other calculations performed on every iteration.
As a result, the core will likely draw extra power with this setting as a result of significantly more flash accesses and core stalls as instructions are being fetched from memory.
I want to drive the SYSCLK signal to two different pins on the device. SYSCLK is enabled through the crossbar, but can I drive the SYSCLK signal on a second pin?
It is not possible to output the SYSCLK signal on more than one pin. The crossbar does not allow outputs to be duplicated in this manner.
There are a couple of techniques you could use to duplicate the SYSCLK signal if you need more than one instance of it. One option would be to use an external clock buffer so you would be able to replicate this signal as many times as you need. This would require an external component.
Another option would be to use the internal comparator in the device. To do this, you would connect the output of the sysclk signal to the input of the comparator, and set the threshold on the comparator to approximately half of the SYSCLK peak voltage. This would replicate the SYSCLK signal on the output of the comparator.
I'm transitioning from an 8051 processor that does not have on-chip ROM or XRAM to a Silicon Labs C8051 or EFM8 series of MCUs that has on-chip ROM and XRAM. Is the address/data bus for Flash and XRAM separate from the port I/O bus?
In earlier 8051 devices that did not include on-chip flash and XRAM memory, you would typically use I/O ports (such as Port 0 for multiplexed address and data bus and Port 2 as address) to access ROM, XRAM, and other external peripherals. Code was executed from the external code memory.
On Silicon Labs devices, you can access all internal memories without having to access the port I/O, including the RAM mapped to the XRAM space. The XRAM that you used to define for the original 8051 external memories are on-chip for these MCUs. If you choose to use the EMIF, then the MOVX instruction, which is used to access XRAM, will provide the address and data to the port pins based on the configuration settings in the specific SFR registers.
When performing block read or write operations, does the data have to be transferred byte by byte or is it possible to set the length field to 11b and send or receive data as 32-bit values?
The data transfers have to be performed byte by byte. The register length for the C2 devices is 8 bits, so the length field would be reported as 00b. Earlier devices that used different debug interfaces (JTAG) had data register lengths that were larger, hence the length field of 2 bits as shown in the documentation. You can see an example of the data reads and writes when looking at the AN127SW in the C2_utils.c file. Application notes are available here: www.silabs.com/8bit-appnotes.
Why does the src\Interrupts.c file in my EFM8UB1 HID Joystick appear grey and "crossed out" in Project Explorer?
This appearance indicates that this file is excluded from the current build configuration. To edit the Resource Configuration for this file, right click on it in the Project Explorer pane and select [Exclude from Build...]:
This will open the [Exclude from build] dialog, where you can choose to exclude this resource from one/all of the configurations defined for this project.
Clearing the checkbox will remove this build exclusion (and thus include the resource in future builds).
The HID Joystick software example for EFM8UB1 includes this Interrupts.c file with the "exclude" flag checked because:
The example implements USB interrupt handling and management using the EFM8 USB library, specifically in lib\efm8_usb\src\efm8_usbdint.c, so this src\Interrupts.c file is not used.
Configurator will automatically regenerate this src\Interrupts.c file if the project's .hwconf file is edited and saved with certain changes to the Interrupts section.
For these reasons, we've added this unused (i.e. "excluded from build") Interrupts.c file to the software example so that you can use Configurator to explore or modify this example without impacting successful compilation with redundant interrupt management.
In 8051 devices (C8051, EFM8), generally some amount of initialization code is ran before the device begins executing the main function. In some cases, such as disabling the watchdog timer to avoid a reset, it may be necessary to execute code immediately after reset, before this initialization code.
EFM8 projects in Simplicity Studio come automatically populated with an assembly file, SILABS_STARTUP.A51, that provides the beginning of this initialization code for the Keil C51 toolchain. However, it also includes the ability to call into a C function immediately after reset. This allows a user to write reset code in C rather than assembly within the startup file.
In SILABS_STARTUP.A51, you will notice a section of code that performs this call into a pre-defined function called "SiLabs_Startup":
In order to use this feature, you must first define SILABS_STARTUP=1 for the A51 assembler. This can be accomplished through the Project -> Properties -> C/C++ Build -> Settings screen, by adding "SILABS_STARTUP=1" to the Keil 8051 Assembler > Control Symbols:
From here, you will need to add the startup function to any of your compiled .c files with the code that you would like to execute immediately after reset.