Are there any software flashing tools for EFM8/C8051 devices available for Linux (such as the like the flash programming utility for EFM8/C8051Fxx devices)? Are there any C2 or USB Debug Adapter (UDA) Linux driver available?
Additionally, I have attached several files to this article that I hope will help enable programming of the EFM8/C8051 devices from the Linux command line. One is a library file that you can utilize with your own wrapper functions to program the device. This is the file "libslab8051.so." The other is a header file that describes the functions contained therein that should enable you to program the C8051 using the USB Debug Adapter that you already have. This file is "SLAB8051.h." I have also attached the header file "SLAB8051Errors.h" to this article.
Unfortunately, we do not really have additional documentation or examples of the use of "libslab8051.so." The DLL that this was based on, however, is called SiUtil.DLL and while we do not have a linux version of this DLL, we do have an application note (AN117) that may have information that translates over to the functions of "libslab8051.so" and could be helpful to you. You can find this application note here: https://www.silabs.com/Support%20Documents/TechnicalDocs/an117.pdf
Is there a reliable way to distinguish between a power-on reset and a power supply monitor reset using the PORSF bit in the RSTSRC register of a EFM8 device? Can the presence of a signature value written in RAM upon initial cold boot be used to detect if the last reset that caused the PORSF bit to be set was a voltage monitor reset? Finally, can the state of power supply monitor bit (VDM0CN.VDMEN) be used to determine whether the most recent reset was a POR or power supply monitor reset?
Answer:
It is not possible to accurately distinguish between a cold POR and a VMON-induced POR on these devices. Cold power up as well as voltage monitor reset both trigger the same flag (RSTSRC.PORSF), and all other flags are considered indeterminate when PORSF flag is set. Additionally, the contents of any RAM location after a brown out/VMON event is indeterminate (i.e. you can not be sure that RAM contents are unchanged), eliminating the possibility of using a "signature byte" in RAM that is written immediately after initial power on (cold boot) to detect a supply monitor reset.
As for using the VDM0CN.VDMEN bit for detection of a VMON POR as opposed to a power up POR, this will not work because after any POR, the voltage monitor is enabled and selected as a reset source, so this bit will read '1' after either kind of reset. The VDM0CN.VDMEN bit is "sticky" in the sense that after any reset other than a POR of VMON reset, the bit will retain its status, meaning that if you disable the voltage monitor as a reset source or disable the supply monitor (i.e. write '0' to VDMEN or PORSF), the voltage supply monitor will remain disabled or disabled as a reset source across all but cold POR. If you do not ever write to the RSTSRC.PORSF, the voltage monitor will remain enabled and enabled as a reset source, as this is its default state out of any POR: "This monitor is enabled and enabled as a reset source after initial power-on to protect the device until the supply is an adequate and stable voltage." (EFM8BB3 RM, sec. 9.3.3, page 84). Thus, any other reset besides a POR or VMON reset will not alter the enabled state of the VMON or its status as a reset source.
To summarize, the following conditions are true:
1) On true power-up POR (cold boot) OR supply monitor POR, the voltage monitor is enabled and enabled as a wakeup source when the device comes out of reset.
2) The enable state of the supply monitor will persist through all other resets. Thus, if you never disable it, it will always be enabled. If you disable it as a wakeup source or disable it as a wakeup source and disable the supply monitor itself, these conditions will hold across all other resets except cold-boot POR, unless you re-enable supply monitor and/or supply monitor as reset source.
3) In the event that you disable the supply monitor as a reset source and disable the supply monitor, the following applies: "In systems where this reset would be undesirable, a delay should be introduced between enabling the supply monitor and selecting it as a reset source."
The following are two suggestions if you must have additional information about the conditions leading up to the setting of the PORSF flag:
1) Use an external power supply monitor
2) Monitor the supply voltage using the ADC and perform some action after the voltage starts to drop but before the VMON threshold is reached. Although this will not help in determining if the last POR was cold or VMON induced, it could give an early warning prior to a brown out event if the supply voltage were to drop.
8-bit Knowledge Base
Linux flash programming utilities for EFM8/C8051Fxxx
Question:
Are there any software flashing tools for EFM8/C8051 devices available for Linux (such as the like the flash programming utility for EFM8/C8051Fxx devices)? Are there any C2 or USB Debug Adapter (UDA) Linux driver available?
Answer:
The following are links to two discussion threads in the Silicon Labs Community which may be of use in this matter:
http://community.silabs.com/t5/Simplicity-Studio-and-Software/Flashing-Running-from-command-line/m-p/142582/highlight/true#M10052
http://community.silabs.com/t5/8-bit-MCU/Announcing-linux-C2-flash-tool/m-p/134037/highlight/true#M41338
Additionally, I have attached several files to this article that I hope will help enable programming of the EFM8/C8051 devices from the Linux command line. One is a library file that you can utilize with your own wrapper functions to program the device. This is the file "libslab8051.so." The other is a header file that describes the functions contained therein that should enable you to program the C8051 using the USB Debug Adapter that you already have. This file is "SLAB8051.h." I have also attached the header file "SLAB8051Errors.h" to this article.
Unfortunately, we do not really have additional documentation or examples of the use of "libslab8051.so." The DLL that this was based on, however, is called SiUtil.DLL and while we do not have a linux version of this DLL, we do have an application note (AN117) that may have information that translates over to the functions of "libslab8051.so" and could be helpful to you. You can find this application note here:
https://www.silabs.com/Support%20Documents/TechnicalDocs/an117.pdf
EFM8 Power On Reset (POR) vs. Supply Monitor Reset
Questions:
Is there a reliable way to distinguish between a power-on reset and a power supply monitor reset using the PORSF bit in the RSTSRC register of a EFM8 device? Can the presence of a signature value written in RAM upon initial cold boot be used to detect if the last reset that caused the PORSF bit to be set was a voltage monitor reset? Finally, can the state of power supply monitor bit (VDM0CN.VDMEN) be used to determine whether the most recent reset was a POR or power supply monitor reset?
Answer:
It is not possible to accurately distinguish between a cold POR and a VMON-induced POR on these devices. Cold power up as well as voltage monitor reset both trigger the same flag (RSTSRC.PORSF), and all other flags are considered indeterminate when PORSF flag is set. Additionally, the contents of any RAM location after a brown out/VMON event is indeterminate (i.e. you can not be sure that RAM contents are unchanged), eliminating the possibility of using a "signature byte" in RAM that is written immediately after initial power on (cold boot) to detect a supply monitor reset.
As for using the VDM0CN.VDMEN bit for detection of a VMON POR as opposed to a power up POR, this will not work because after any POR, the voltage monitor is enabled and selected as a reset source, so this bit will read '1' after either kind of reset. The VDM0CN.VDMEN bit is "sticky" in the sense that after any reset other than a POR of VMON reset, the bit will retain its status, meaning that if you disable the voltage monitor as a reset source or disable the supply monitor (i.e. write '0' to VDMEN or PORSF), the voltage supply monitor will remain disabled or disabled as a reset source across all but cold POR. If you do not ever write to the RSTSRC.PORSF, the voltage monitor will remain enabled and enabled as a reset source, as this is its default state out of any POR: "This monitor is enabled and enabled as a reset source after initial power-on to protect the device until the supply is an adequate and stable voltage." (EFM8BB3 RM, sec. 9.3.3, page 84). Thus, any other reset besides a POR or VMON reset will not alter the enabled state of the VMON or its status as a reset source.
To summarize, the following conditions are true:
1) On true power-up POR (cold boot) OR supply monitor POR, the voltage monitor is enabled and enabled as a wakeup source when the device comes out of reset.
2) The enable state of the supply monitor will persist through all other resets. Thus, if you never disable it, it will always be enabled. If you disable it as a wakeup source or disable it as a wakeup source and disable the supply monitor itself, these conditions will hold across all other resets except cold-boot POR, unless you re-enable supply monitor and/or supply monitor as reset source.
3) In the event that you disable the supply monitor as a reset source and disable the supply monitor, the following applies: "In systems where this reset would be undesirable, a delay should be introduced between enabling the supply monitor and selecting it as a reset source."
The following are two suggestions if you must have additional information about the conditions leading up to the setting of the PORSF flag:
1) Use an external power supply monitor
2) Monitor the supply voltage using the ADC and perform some action after the voltage starts to drop but before the VMON threshold is reached. Although this will not help in determining if the last POR was cold or VMON induced, it could give an early warning prior to a brown out event if the supply voltage were to drop.