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>
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.
How to use EFM8LB1/EFM8BB3 I2C slave, it looks quite different from SMBus peripheral.
The EFM8LB1/BB3 contains a I2C slave peripheral, it includes many interesting features which helps on high speed transfer but may cause confusion to the user who was familiar with legacy SMBus operation. Here we make a brief intro of I2C slave, and attach an I2C slave bootloader example code for reference. This code example has been written for EFM8BB3 but can be easily ported to EFM8LB1 if needed.
The I2C peripheral contains 2 bytes FIFO and 1 byte shift register for TX/RX individually. The I2C slave support auto ACK/NACK an I2C master, it is controlled by BUSY bit field of I2C0CN0 register. In default, the BUSY is "1" which the device will not respond to an I2C master. All I2C data sent to the device will be NACKed. We should set this BUSY bit as "0", the device will acknowledge an I2C master. For a case, the master keep sending data to device, the device ACK the master automatically for max 3 ACKs since two bytes in FIFO and 1 byte in shift register. And then the SCL is hold low to indicate device is not capable to receive more data. We should check RXE bit field of I2C0FCN1 register to know if there is data in FIFO, read received data from I2C0DIN register.
The auto ACK feature makes difficulty on flow control, as we mentioned above, the SCL is hold low when the RX FIFO is full, so that device can handle the data. What about the master changes read/write direction? There is another feature can helps on this situation. The FACS bit field of I2C0ADM register. The defaults value is "1" which means FORCE_STRETCH. When this bit is set, clock stretching always occurs after an ACK of the address byte until firmware clears I2C0INT bit. With this clock stretching feature, we are able to hand the flow control during read/write direction changes.
There is an I2C slave bootloader example code which base on AN945, please take a look into it and have a reference on how the I2C slave state machine works. The I2CSlave state machine is described in two Flow Diagrams in the Reference Manual (Fig 17.7 and Fig 17.8) and can be condensed down to this Status Decoding table (Table 17.1 in the Reference Manual - https://www.silabs.com/documents/public/reference-manuals/efm8bb3-rm.pdf)
The I2C Bootloader is designed to work just like the SMBus Bootloader which is described in detail in AN945 - https://www.silabs.com/documents/public/application-notes/an945-efm8-factory-bootloader-user-guide.pdf. The boot_I2C.c file in the attachment shows how the I2CSlave peripheral is being used - one may notice that only three states are defined in the code while the Table shown above describes a lot more. There are a couple of reasons why some states are not included in the Bootloader code -
Why does changing the PGA setting from, say, 8 to 32 increase the current consumption of the circuit?
The PGA on a SigmaDelta ADC like the one on C8051F353 is usually implemented with CMOS switched capacitors. Essentially, there is a capacitor of a certain size that is being switched in and out at a certain frequency. This creates a variable resistor that can be scaled with frequency or capacitor size, relative to another reference capacitor in the design. The variable resistor is how we adjust the gain of the PGA.
For certain gain settings, we scale the capacitor size and the for higher gain settings (over 8x), we adjust the frequency of the switched cap. The extra supply current is probably clock current going to those switched capacitors, and some from the switches themselves, being switched at a higher frequency.