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>
To register a license for Keil C51, two components are needed - a CID (Computer ID) and PSN (Product Serial #). The CID is different from computer to computer, so you cannot simply copy the license information from one computer to another.
If a computer cannot access the Internet, we can obtain its PSN/CID and register it with another computer that can access the Internet. The CID and PSN can be obtained in one of the following ways:
With both the PSN and CID, register for a license here: https://www.keil.com/license/install.htm. The license (LIC) can be installed under Studio, back in the Licensing Helper ([Help] > [Licensing] > [Keil 8051 ...]), or in Keil uVision under [File] > [License Management].
Electromagnetic compatibility (EMC) optimization is a core competence of Silicon Labs. As well as implementing chip-level circuits to improve performance in a system, we have a very strong understanding of board-level design to ensure best-in-class EMC performance. We have helped many customers optimize PCBs to meet emissions standards and use our EMC lab to help solve our customers' board-level emissions problems.
EMC determines the ability of a product like MCU to coexist in its intended electromagnetic environment without causing or suffering functional degradation or damage to itself or to other devices that may reside in that environment – it neither is susceptible to nor causes Electromagnetic Interference (EMI). Since EMC involves the presence of a source of electromagnetic radiation, a receptor of that electromagnetic radiation and a path for that electromagnetic radiation, it is only necessary to remove two of these to achieve acceptable EMC. In general, it is not practical to completely eliminate electromagnetic radiation from a digital integrated circuit. However, by incorporating many fundamental techniques to control electromagnetic emissions from an integrated circuit and to then incorporate new methodology to reduce “leakage” of these emissions outside of the chip. From the overall system point of view, it is always more cost effective to design a product with suppression at the integrated circuit level as opposed to addressing these issues at the PCB or system level .
By designing our MCUs with EMC optimization in mind, Silicon Labs delivers solutions that reduce system level noise and interference. The following resources will enable designers to better understand system level considerations to reduce EMI, how to measure it and how to ‘design-it-out', of your PCB designs.
Most electronic products require radiated EMI testing to ensure that they don't interfere with other RF systems, such as television and radio broadcast and cell phones. After meeting the required standards, an endorsement from a calibrated and certified EMI test house is issued. A TEM cell allows companies like Silicon Labs (who are in the semiconductor or product business, not the EMI testing business) do "pre-compliance" testing before going to a certified test house. The TEM cell along with an EMI receiver or spectrum analyzer comprise a system capable of making calibrated radiated field strength measurements. The TEM cell acts as a calibrated antenna and shielded enclosure, which both captures the radiated energy and blocks outside signals from the measurement. The spectrum analyzer is the receiver, which, with custom software, measures and displays the frequencies emitted and their strengths.
In the 8-bit SDK, the capsense library has been updated from SDK versions 4.08 to 4.09. This update primarily changed how capsense thresholds are assigned. Previously, threshold values were global - one set of threshold values applied to all capsense inputs. This works fine for situations where all capsense inputs are approximately the same size, but it is incompatible with systems with varying capsense input button sizes, or for situations where different thresholds are needed on a per-button basis.
This change was reflected in Hardware Configurator.
Previously, the global thresholds were located in the Capsense Library peripheral screen:
Now, the individual thresholds are located in each pin's settings, in the Port I/O tab.
The settings that were moved are: Average Touch Delta, Active Threshold, and Inactive Threshold.
What is the width of the pins on the TQFP-48 package on EFM32HG devices? This is not listed as a dimension in tables 4.4 (package specifications).
Firstly, page 59, Figure 5.1 does show the recommended landing patterns for this device's pins as 1.6 x 0.3 mm. So, it's reasonable to expect the pin width to be, at most 0.3 mm.
In table 4.4, we can also derive the pad with by examining the distance between the edges of adjacent pins (0.2 mm, T, U, V, Z) and the pitch width (the distance between the centers of pins (0.5 mm). The pitch width should be equal to (1/2 pin width) * 2 + pin separation. So pin width + 0.2 mm = 0.5 mm, so pin width equals 0.3 mm.
Examining a TQFP-48 device here with a microscope, I observe that the pins indeed do seem larger than the gaps between them, so 0.3 mm should be the correct number for the pin width, and 0.2 mm for the pin gaps.
I am measuring the internal temperature sensor with the ADC. I then use the formula from the appnote (https://www.silabs.com/documents/public/application-notes/AN929.pdf) to calculate the temperature, using the internal temp sensor calibration reading.
((ADC Temp sensor measurement) - (stored Cal value) / 28 = Temperature C
However, I am getting odd results. For example, I measure 0xE84 from the temperature sensor. The cal value stored in flash at 0xFFD4-0xFFD5 reads back 0x10C7A. This results in the following formula.
(0xE84-0x1C7A) / 28 = -127.6 C
This can't be right since the measurement is being performed at room temperature. What is going on here?
The temp sensor cal value is taken with the internal voltage reference at 1.65 V, and the ADC set to 14-bit mode with a PGA gain of 1 (rather than 0.5). The settings for taking a temperature sensor reading must be identical, or the measured value will be on the wrong scale compared to the temperature sensor.
Make sure that the ADC is set to 14-bit mode, 1.65 V internal reference, and PGA gain of 1 (0.5 is the default). As a result, our previous measurement at the same temperature now reads 0x20A9.
The resulting formula is then:
(0x20A9 - 0x1C7A) / 28 = 29.2 C
This is an expected result for a measurement near room temperature.