What is the maximum value of the pulse width of spikes for Silicon Labs 8051 MCU SMBus/I2C slave?
For SMBus interface, our 8051 devices have a 2-SYSCLK glitch filter for all digital inputs. The pin needs to be at the new level for at least 2 SYSCLKs before it’s seen internally. Therefore, if there are 50 ns spikes on the SMBus SCL or SDA line, the system clock would need to be no greater than 40 MHz.
Unlike SMBus, the I2C Slave (I2CSLAVE0) interface input filter does not depend on system clock, it can suppress noise spikes up to 50 ns in Standard (up to 100 kbps), Fast (400 kbps) or Fast Plus (1 Mbps) mode.
When using example EFM8UB1_VCPXpress code on a SLSTK2000A EFM8UB1 STK to create a USB-to-UART bridge , COM port on Tera Term could not be connected or was not seen. Why is this happening?
This is a known issue and Silicon Labs is working on updating the library.
When a device enumerates as a CP210x, the host asks the device a string of questions, which are either ACK'ed or NAK'ed (till the information is made available by the device). If the device is NAK-ing, the host will continue to wait for the information from the device and we are in a sense "stuck".
The USB traffic for this particular case shows that there is a command(lock_byte) causing a continuous stream of NAK's from the device. The device was not being recognized as a COM port in teraterm because the device had not fully enumerated in this case. This does not happen in case of a CP210x device, because all the commands are handled in the library source. The VCPXpress is for devices that behave as CP210x, hence parameters such as lock byte, gpio configuration of the CP210x device etc have no meaning. When such information is asked for by the host, the device is supposed to stall the host. The host will then continue to handle other commands sent and the device will be finally enumerated.
There is an error in the VCPXpress library code that was causing this issue. This change needs to be done in a lot of APIs within the library source and will need to undergo testing which is current underway. There is a patch that fixes the issue mentioned above (which is attached to this article). This has to be replaced in the library in the SDK. A point to be kept in mind is that this is a WIP library and we will be rolling out the fixed version soon.
How do I read back the UID, UUID, DEVICEID, DERIVID and REVID for 8-bit MCU?
C8051F85x/C8051F86x/EFM8SB1/EFM8SB2/EF8BB1/EFM8UB2 have a 32-bit unique identifier (UID). After reset, the UID will be filled in the specific address RAM/XRAM, and you can read back the value by reading these RAM/XRAM locations. Be aware that the RAM/XRAM locations may be overwritten by startup code (these RAM locations can then be reused by the user). For more information on the XRAM or RAM locations, see the specific device data sheet or reference manual.
EFM8LB1/EFM8BB2/EFM8BB3/EFM8UB1 have a 128-bit universally unique identifier (UUID), The UUID resides in the read-only area of flash memory, which cannot be erased or written by the end application. The UUID can be read by firmware or through the debug interface at flash locations 0xFFC0-0xFFCF.
In the C8051 8-bit MCU like C8051F340, DEVICEID and DEVID could be only accessed by the C2 interface. For new EFM8 devices (except EFM8UB2 and EFM8SB2) and C8051F85x/F86x devices, there are SFR registers (DERIVID, DEVICEID and REVID), and firmware can access this same information.