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?
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?
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 -
SETB RS0 ANL TCON,#00FH ; ANL TCON,#00FH ; // Change made here MOV TMOD,#056H ; MOV TH1,#High(65535-28125) ; (2) initial count for approx. 1/2 sec SETB TR1 ; (1) start timer 1
that would fix the random setting of TF1.
So would:
SETB RS0 ANL TCON,#00FH ; CLR TF1 ; // Change made here MOV TMOD,#056H ; MOV TH1,#High(65535-28125) ; (2) initial count for approx. 1/2 sec SETB TR1 ; (1) start timer 1
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.
TBIAS (Ambient Temperature Under Bias)
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?
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: