Why does the datasheet say the Fast Mode (400 KHz Class) SMBus has a maximum operating frequency of 255 kHz?
The SMBus peripheral is internally clocked at 3 times the target bit rate and generates clock low from 1 clock cycle and clock high from 2 clock cycles.
The SMBus 400 kHz fast speed specifies clock low must be at least 1.3 us. So 1/(3x1.3us) = 256 kHz. If you set the SCL frequency to higher than 256 kHz, then the clock low time will be less than 1.3 us and violate the spec.
In practice, many I2C devices will work fine above 256 kHz, but the device will be in violation of the timing requirements, so full compatibility can't be guaranteed for strict systems.
I am trying to use ADC on the C8051F35x and am having problems figuring out how the offset DAC works.
First of all, I am not sure if the offset DAC is added to or subtracted from the AIN+ and AIN- inputs such that it has the effect of level-shifting, is applied to only one input, or even if its doing the opposite on both inputs (half the value subtracted from AIN+ and half value added to AIN-, which would cancel any offset completely.
Also, application note AN217, which has the same block diagram as the 'F35x datasheet...
...shows that the offset should be applied before the gain, but in my tests it seems to be done afterwards.
From what I can tell, the offset voltage is substracted after the amplification. Is this expected behavior, or am I doing something wrong?
As the customer has noted, there appears to be a notable difference in how the offset DAC behaves relative to the PGA, and, in this case, the customer is correct: the offset DAC operates after the PGA. So, for starters, the block diagram above should be modified as follows:
Furthermore, consistent with the customer's experiments, the ODAC output is subtracted from AIN+ and added to AIN- as a signed value, where bit 7 and bits [6:0] of the ADC0DAC register represent the sign value (0 = positive, 1 = negative) and the magnitude, respectively.
When trying to do isochronous transfers with the USB Peripheral Driver Library, you may notice that the library only supports isochronous transfers on Endpoint 3 even though the device's datasheet says endpoints 1-3 support isochronous transfers.
The device does support isochronous transfers on endpoints 1 through 3, but the library was only designed to support isochronous transfers on endpoint 3 by default. All Silicon Labs designs use endpoint 3 for isochronous transfers, so the library was built around this as well as with the idea of keeping the code simple in mind. The library can be modified to support isochronous on other endpoints, but the library does not support this out of the box.
I am trying to reproduce the current consumption numbers specified in the datasheet of an EFM8 device. How do I make sure that I am using the same settings as the numbers in the datasheet?
Provided with Simplicity Studio is a set of software examples that demonstrate how to use the device's various peripherals. One of these examples is PowerModes and shows how to put the device into its various low power states. In Simplicity Studio, this code is listed under Software Examples when you have your device selected.
While running the TestPanel example which included in the USBXpress 4 SDK v4.0.3 on C8051F340 MCU, the device can be enumerated as a USBXpress Device viewing from the Windows Device Manager, however, it failed to start the Host application TestPanel.exe, what would cause the issue as below?
This is caused by incorrect USBXpress driver version installed on your machine if you are not using the USBXpress driver that is included in the same SDK version.
To solve the issue, uninstall the existing driver of the USBXpress Device, and then re-install the corresponding driver included in the USBXpress SDK where you are running the USBXpress example.
For the USBXpress SDK v4.0.3 mentioned above, the driver version is 22.214.171.124 with driver date of 4/8/2013.
For 8-bit MCU like EFM8UB2, a port pin isavailable on crossbar, do I need to enable crossbar if a port pin work as general purpose GPIO (non peripheral mode)?
For port pin is available on crossbar, if you need to control it's level through the Px.x latch value, you need to enable the crossbar.
Take the EFM8UB2 as example, you could see what port pin was available on crossbar in figure 11.4 on page 83 of the reference manual.
The port I/O cell block diagram shown in figure 11.2 on page 79 of reference manual.From the below diagram, we can know once the crossbar is disabled, the Px.x latch value wont' take effects on port pin.
What is the difference of GPIO structure on Silicon Labs MCU families.
5V tolerance of GPIO pins on Silicon Labs MCU families as followsType A:
Pins are tolerant of the IO power supply voltage plus 2.5V, so they are 5V tolerant with a 3.3V supply. When the pin voltage rises more than 2V above the supply, the leakage currents from the pin to the supply and from the pin to ground will increase with voltage. When the power supply is 0V, the applied pin voltage can be as high as 3.3V at room temperature with moderate leakage; but at that voltage, the leakage can be very high at elevated temperature.
Devices: EFM8UB1, C8051F86x. etc
Pins cannot exceed the IO power supply voltage, which can be up to 5V. The pin includes an ESD protection diode to the power supply, so the pin leakage will increase exponentially if the pin voltage exceeds the power supply voltage by more than 0.5V at room temperature. These pins are 5V tolerant only if the IO supply is 5V..
There is a statement in EFM8LB1 spec that pin leakage current is in the range of [-1.1 4] uA . Does this leakage current affects ADC result of external signal?
Correct, the leakage mainly dominated by the ESD protection circuit for the port structure. It may flow in or out of the device. The leakage current is strongly sensitive to the temperature.
Let us assume 100nA leakage, and output impedance for source signal to be measured is 10k ohm. Then the measurement error caused by the leakage likes an offset error of ADC result. This example gets 100nA*10kOhm = 1mV voltage offset (measured) on the pin.
Under condition that ADC is configured as 2.5V VFS and 12-bit resolution. Then we have 1 LSB equals to be about 2.5V/4096 = 610uV
Then the 10k Ohm resistance of external source signal to be measured would see 1 LSB offset error as 1mV>610uV.
Related KBA: Comparator Input Leakage
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.
This question, and others like it, are frequent arrivals in the applications engineering support queues at Silicon Labs. In nearly every case, they take the form of "Can I run at/with..." where the particular specification only slightly exceeds that which is published in the data sheet.
Sadly, in all cases, the answer is "No."
Consider the question above. This customer uses the C8051F580-IQ, which is specified for -40°C to +125°C operation.
It doesn't seem to be an unreasonable request. After all, there is an entire overclocking movement in the PC world with people using exotic cooling technologies like liquid nitrogen to get x86 processors to run at frequencies well beyond what they are rated by Intel and AMD. Isn't cold a good thing for semiconductors? Could the C8051F580-IQ, in this case, not only boot at -54°C but run faster than its rated 50 MHz?
Alas, this is a generalization. Not everything on a semiconductor device benefits from being kept cool. Intel CPUs, despite their advanced processing capabilities, are actually rather simple digital devices. Granted, they do have a PLL to generate the high frequency clock and high-speed RAMs that provide the different levels of caching, but these devices are primarily high-density collections of purely digital logic, and, as overclockers have figured out, keeping this digital logic cool permits the attainment of higher levels of performance.
Why then, isn't this the case for a C8051 or EFM8 microcontroller?
Unlike an x86 CPU, which is heavily dependent on an external chip set, SPI boot flash, and highly complex PMIC (power management integrated circuit) in order to boot, an 8-bit microcontroller manages this in an entirely self-contained fashion with little external support except for perhaps a voltage regulator.
This particular customer thought he might be able to boot at -54°C because he did not need any analog functionality and only required UART and CAN to be operational. While he thought that he would not be using any analog peripherals, this is emphatically not true. The C8051F580 boots from the internal oscillator in all cases, and this is an analog block. The same also applies if he intended to enable the crystal oscillator immediately after beginning code execution.
Furthermore, while most people don't think of RAM as analog, it is a hard block that is compiled and placed on the chip to facilitate die layout, not operation at a particular temperature. The same also applies to the flash, which comes as pre-built hard blocks in the particular sizes needed. Even to exit reset, the MCU depends on an analog block, a comparator that is part of the power-on reset circuit.
Shouldn't these analog blocks also benefit from being kept cool like digital logic? Maybe, maybe not. All transistors exhibit marginal behavior at temperature extremes. Analog blocks are comprised of transistors that often make use of custom sizing in order to achieve the desired behavior.
Consider, again, the comparator used in a power-on reset circuit, which must go active when a particular voltage threshold is reached. This block has to be simulated to be sure it behaves in the desired fashion over the rated operating temperature and voltage range, and this impacts the parameters of the particular transistors from which it is built. A happy medium must be found for these parameters to guarantee this and provide some extra margin for the inevitable shifts that occur in fabrication as the manufacturing equipment ages and as the photomasks used for each layer of the die deteriorate over their useful lives.
Just as overclockers tend to think that their processors have huge amounts of margin because Intel and AMD offer variants with clock frequencies that might range from 2.0 to 4.4 GHz, some microcontroller users think there is similar margin built into their 8-bit devices. After all, while the C8051F580-IQ has a rated ambient temperature range of -40°C to +125°C, the datasheet specifically lists an "Ambient Temperature under Bias" parameter with a range of -55°C to +135°C in the Absolute Maximum Specifications table. Doesn't this mean the device can operate at these extremes of temperature, if only for a short amount of time?
The answer here is unequivocally "No." As the note in the C8051F580 datasheet makes abundantly clear, "this is a stress rating only and functional operation of the devices at those or any other conditions above those indicated in the operation listings of this specification is not implied. Exposure to maximum rating conditions for extended periods may affect device reliability." In other words, the device can survive transients of temperature, voltage, or current that do not exceed the absolute maximums. There is, however, no guarantee of proper functionality when this happens.
In summary, specifications really are absolute. While a single device or even a particular batch of devices may work fine when exceeding a particular operating parameter, there's no guarantee that this will be the case weeks or years in the future for a device that has been newly purchased or has otherwise been functioning in a system without incident.
EFM8 Factory Bootloader AN945SW contains all EFM8 bootloader images with UART, USB or SMBus interface. The source of the efm8load tool, a python script efm8load.py is also included under /Tools/Source folder. Since Python is a cross-platform language, and therefore the script can run on a Linux system.
However, if run the efm8load.py on Linux directly, it will throw some errors because the current program in hidport.py or smbport.py does not support Linux. It is necessary to make slight modification by loading associated libraries for Linux as below on both scripts
# Load HID shared library using ctypes if sys.platform == 'win32': _DLL = ct.windll.LoadLibrary('SLABHIDDevice.dll') elif sys.platform == 'darwin': _DLL = ct.cdll.LoadLibrary('libSLABHIDDevice.dylib') elif sys.platform.startswith('linux'): _DLL = ct.cdll.LoadLibrary('./libslabhiddevice.so.1.0') else: raise RuntimeError('HidPort: Unsupported OS')
# Load HID shared library using ctypes if sys.platform == 'win32': _DLL = ct.windll.LoadLibrary("SLABHIDtoSMBus.dll") elif sys.platform == 'darwin': _DLL = ct.cdll.LoadLibrary("libSLABHIDtoSMBus.dylib") elif sys.platform.startswith('linux'): _DLL_prev = ct.CDLL("./libslabhiddevice.so.1.0", mode=ct.RTLD_GLOBAL) _DLL = ct.cdll.LoadLibrary('./libslabhidtosmbus.so.1.0') else: raise RuntimeError("HidSmbus: Unsupported OS")
These Linux libraries .so.1.0 files can be found in USBXpressHostSDK for Linux, if you have download and installed it, then you can copy-and-paste them into the same folder of the python scripts in AN945SW.
I have also updated the scripts and provided the Linux libraries in the attachment at the end of this article. With the modification above, you can run the efm8load.py on Linux successfully now. Here take EFM8LB1 STK UART bootloader as an example, the STK JLink CDC serial port appears as /dev/ttyACM0 on Linux. If using with CP210x USB-to-UART bridges, the serial port shows as /dev/ttyUSB0 instead.
To load the application image into the MCU, firstly let the EFM8 device enter UART bootloader mode, then try the following command with specified serial port:
sudo python efm8load.py -p /dev/ttyACM0 filename.efm8