What is SMBus free timeout? What is the behavior of SMBus after the free timeout occurs?
The SMBus specification stipulates that if the SCL and SDA lines remain high for more that 50 µs, the bus is designated as free.
The SMBus Free Timeout detection on 8-bit MCUs can be enabled by setting the SMBFTE (or SMBnFTE) bit. When this bit is set to logic 1, the bus will be considered free if SCL and SDA remain high for more than 10 SMBus clock source periods. A clock source which is determined by the SMBus clock setting (the SMBCS bit field in SMB0CF ) is required for free timeout detection, even in a slave-only implementation.
When a Free Timeout is detected, the interface will respond as if a STOP was detected. For a matched slave address, the Free Timeout sets STO flag and generates an interrupt, the interrupt must be cleared by firmware.
If the Free Timeout condition happens after STOP detection but before servicing the STOP status flag, then STOP bit gets cleared by the Free Timeout, but the SI interrupt flag is not affected.
If the Free Timeout condition happens after STOP detection and servicing, then the STOP status flag will not be set by the Free Timeout condition.
In the legacy 8-bit MCU IDE, there is an option to upload the contents of the memory to a text file. This can be useful to record the firmware image on a device:
However, the format that is produced is non-standard - every byte of flash is recorded in text, separated with a new line, e.g.:
00 00 82 20 81 02 41 03 00 80 00 20 c0 02 40 09 00 00 02 20 80 00 00 02 02 80 12 ... etc.
It may be useful to convert this format into a binary format. Attached to this case is an executable, as well as its python script source, that performs this function. The usage for this executable is:
MemoryUpload2Bin.exe -m <path to memory upload txt> -b <path to binary to be created>
Binary files can be generated from several toolsets, or even by uploading the memory contents of a device using Simplicity Studio. However, it may be useful to convert these .bin files into a .hex file. An executable, as well as its python script source, has been attached to this article to perform this task.
The usage of this file is:
Bin2Hex.exe -b <path to binary file> -o <path to hex to be created>
How to understand ESD information of EFM8LB1 in Qual report?
Get EFM8LB1x_AEC_Qual_Report.pdf from RoHS Information web page.
The classification in the last column listed are the AEC classification for which voltage level passed. Silicon Labs standard was to list the classifications, not the passing voltages.
ESD-HBM refer to the test condition listed which is AEC-Q100-002. In section 3.0 on page 5 of this document it points to JS-001. That means the JEDEC document should apply here. From the classification level table as below, the Class 3A is a rated 4000 to < 8000V.
For ESD-CDM the reference document is AEC-Q100-011. Class C6 is rated ≥1000V (section 5 on page 12).
The Derivative ID in the read-only register DERIVID can be used by firmware to identify which device in the product family the code is executing on, also the debugger can get the Derivative ID information through the C2 debug interface.
Below is the list of the Derivative IDs of EFM8LB1xFxxES1.
What is the maximum value to use for a GPIO pull-up resistor on EFM8SB1 under 3.3V VDD?
Maximum pull-up resistor value for EFM8SB1 is: 570k ohms
Use of an external pull-up resistor instead of the internal pull-up on an EFM8SB1 GPIO provides an opportunity for reduced current draw in certain applications, particularly in battery powered designs. The reason for this is the maximum value resistance that works as a pull-up for an EFM8SB1 GPIO pin is larger than the internal pull-up resistance listed in the EFM8SB1 datasheets (around 165k ohms), which equates to significant power savings in which one or more pull-up or pull-down resistors are frequently drawing current. The typical 165k ohm internal pull-up resistance was calculated based on the IPU data in table 4.15 of the datasheet.
R_PULL_UP = 3.3V /2 0uA = 165k ohms.
For example, a battery operated open / closed sensor switch may be required to have a pull-up on the switch circuit. The firmware may be monitoring for a high level on the switch / GPIO circuit. In the case of a normally closed switch, when the switch is engaged, the resulting circuit to ground through the switch is detected by the firmware and acted upon. Depending upon how often or how long the switch is activated, the resulting power drain through the pull-up could shorten the overall lifespan of the battery. In this type of situation, use a large value external resistor instead of the internal pull-up configuration of the GPIO pin in order to reduce the current draw and extend battery life.
To arrive at 570k ohms conclusion as the maximum safe resistor pull-up value, we first determine the GPIO maximum input leakage current. Characterization testing of Engineering IC test lots have revealed an upper limit of 1 uA for EFM8SB1 devices.
Refer to the datasheet table 4.15 for Input leakage current (ILK), Input high voltage (VIH).
Having determined the leakage current, we could then get the minimum input high voltage for the GPIO in table 4.15 under VDD operating voltage 3.3V, the value is VDD-0.6. This indicate the allowable voltage drop across the external pull-up is 0.6V. By using Ohm’s Law to divide the voltage drop of the external pull-up by the threshold leakage current value and multiplying the result by 0.95, we safely determine the appropriate pull-up resistor value with a 5% margin.
0.6 V / 0.000001 A * 0.95 = 570k ohms
Is it possible to detect a break condition on the UART RX line when using the EFM8 UART0? If so, is there a software example that demonstrates this?
While the EFM8 UART0 module itself does not support break detection, and we do not have any software examples that demonstrate this exact application, it should be fairly straightforward to modify one of our existing examples for the pulse counter array (PCA) to detect a break condition.
By externally routing the RX data line to a separate MCU pin (on your PCB) and using the crossbar to select that pin as a PCA input, you can use the input capture mode of the PCA to detect the break condition on the line. A good starting point for this application would be out firmware example "EFM8SB1 PCA0 Capture Input," which you can access through Simplicity Studio under the EFM8SB1 software examples.
Can the BLDC example be applied to a synchronous reluctance motor? https://www.silabs.com/products/development-tools/mcu/8-bit/sensorless-bldc-motor-reference-design
The design of synchronous reluctance motors is significantly different from brushless DC motors, so the reference design will not be useful for this application.
How can I generate a PWM waveform that has variable frequency (between 9 kHz and 12 kHz with at least 200 steps in between) using the CLU? Can I use timer 0 for this purpose? How do I control the Duty Cycle of the PWM waveform?
To start off, it is not possible to use Timer 0 reload values to vary the frequency by 200 steps between 9 kHz and 12 kHz since it is a 8-bit timer and cannot provide that level of resolution. The D flip-flop can be used to create a one-bit counter which can be output to a pin. This can in-turn be used to run the PCA through ECI. Timer 2 can be used with the CLU to generate the 9 kHz frequency pulse. The reload value of this timer can be changed to change the frequency.
The CLU can be programmed in the Configurator to generate a 9 kHz bit counter.
This setting would result in a D flip-flop as shown below -
The PCA settings should be changed to use the ECI for PWM generation
Now, the duty cycle can be altered by changing the capture compare value of the PCA channel. The only constraint is that one GPIO pin should be available (depending on the CLU output) for the PWM counter to work. The code example attached shows how CLU, PCA+ECI can be used to generate PWM signals. By adding a push button, the user can change the frequency by changing the reload value of Timer 2.
What is the minimum code size for the EFM8 capacitive sensing library (cslib)?
The minimum code size for cslib is approximately 4 kB with the UART Profiler Output disabled. The UART Profiler Output is typically only used during development and can be removed in the release build of a project. Devices with 8 kB flash are recommended for applications using cslib.