I purchased a brand new EFM8 kit and I haven't made any hardware changes to it. The Debug Mode of the Kit Manager is stuck on "Off" and cannot be changed to "MCU". What is happening here?
Answer
During startup, the kit bootloader checks if both push-buttons are pressed, in which case it halts before starting the application. The device should normally be held in reset during this check, but a firmware bug let the target application run during the check. This affects all EFM8 STKs.
The target application programmed on these devices pulls both push-button lines low, which causes the check above to halt during startup.
Possible workarounds include:
Hold the reset button pressed while powering on the kit
Switch off target power (set the power switch to "BAT") during startup
Modify the target application to not pull both push-button lines (P0.2 and P0.3) low early in the program execution
I am using Timer 0/1 in mode x(mode 2) initially and at a certain point I change the mode to y(mode 1, say). I disable the interrupt, turn off the timer and then change the mode. I do not generate an interrupt but poll the TF1 flag. Sometimes, I see TF1 flag being suddenly set when it is not supposed to. This is the code -
ANL IE,#075H ; (2) disable timer interrupts
JNB FLAG,ABORT
CLR RS1 ; (1) select register bank 1
SETB RS0
ANL TCON,#00FH ;
MOV TMOD,#056H ;
MOV TH1,#High(65535-28125) ; (2) initial count for approx. 1/2 sec
SETB TR1 ; (1) start timer 1
..... ; <20-25 simple instruction - no loops, no changes on any registers>
Jnb TF1,Ptd1a ;(2) no fault detected - jump
Jmp Fault_Detected ;(2) go handle fault
Why am I seeing this erratic behavior?
Answer
You are most likely running into a situation where the timer overflow happens at the same time as the instruction where you are stopping the timer, i.e., when ANL TCON, #00FH is executed. That is a read-modify-write instruction, and it takes around 2 or 3 cycles. Most registers with hardware flags, i.e. bits that can be set or cleared by something other than the controlled core, are protected against collisions on read-modify-write instructions. If a collision occurs, the hardware (not the write from the software) wins. This is to avoid the opposite situation where, for example, an interrupt occurs on this clock cycle and it is accidentally cleared when trying to change a different bit. It is not mentioned that the TF1 needs to be cleared before changing modes in the datasheet primarily because, TF1 can be left alone as far as the hardware cares. Changing the mode does not change the flag one way or the other. If it is set, it will stay set and if it is clear, it will stay clear. It is actually the timer overflowing while you are stopping that sets the flag. It is already set before you write to TMOD. If, for example, you did this instead -
This is not really a bug or erratic behavior of the device. This is intentional design on our part to make certain that the device never accidentally misses a hardware interrupt due to execution of a read-modify-write instruction. This is done on any registers where there are multiple flag bits that can be set by hardware.
Defined the ambient temperature range that the part under Bias. The part will not be damaged, however, functionality in the datasheet specification can’t be guaranteed if the temperature exceed the range of Ta.
Ta (Operating Ambient Temperature)
The ambient temperature range that the part under bias, and the part will be guaranteed functional to the datasheet specification.
The backup files in the Silicon Labs IDE can clutter up a large project. Is there a way to move them to a subdirectory, or reduce the number of backup files created?
Answer
You cannot generate backup files in a subdirectory, but you can control the number of backup files created by going to [Options]>[File Backup Setting].
During startup, the kit bootloader checks if both push-buttons are pressed, in which case it halts before starting the application. The device should normally be held in reset during this check, but a firmware bug let the target application run during the check. This affects all EFM8 STKs.
The target application programmed on these devices pulls both push-button lines low, which causes the check above to halt during startup.
Possible workarounds include: