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.