Analysis of C8051Fxxx Program Loss Problem and Preventive Measures

1 Brief introduction of C8051Fxxx microcontroller and Flash structure

The C8051Fxxx series of devices is a high-speed microcontroller series launched by Silicon Labs. This microcontroller is a fully integrated mixed-signal system-on-chip MCU chip with a high-speed, pipelined 8051-compatible CIP51 core; 70% of the instructions are executed in 1 or 2 system clock cycles; there are abundant on-chip peripherals, including ADC, DAC, UART, capture/compare module programmable counter/timer array, SPI, SMBus, etc. depending on the model.

The C8051Fxxx microcontroller has a large capacity Flash memory for program code and non-volatile data storage, which can be programmed in the system. The structure of Flash is organized in sectors (128 KB series uses 1 024 bytes as 1 sector, and 64 KB series uses 512 bytes as 1 sector). Non-volatile Flash can be used to store system parameters, such as software version, production date, etc. Flash can be erased and written using a programmer, or modified using the MOVX instruction in the program, so that the Flash memory has the ability to be reprogrammed in the system, allowing the 8051 firmware program to be updated on site. The write and erase operations of Flash are automatically timed by hardware to ensure that the operation is correct. The Flash of C8051Fxxx saves the downloaded program. After the system is powered on, the microcontroller reads the code data from Flash to RAM, and then the program starts running.

2 The occurrence and causes of program loss problem

In some practical applications, the program may not run properly after the system is powered on again, which is often manifested as "program loss". This is usually caused by the program code being damaged or modified.

There are many reasons for program loss, which can be attributed to one basic reason, that is, the failure to access the Flash causes errors in the code saved in the Flash. For all systems that contain Flash write/erase subroutines, when the CPU works outside the specified VDD, temperature, and system clock frequency range, Flash data errors may occur when writing/erasing the Flash.

2.1 Hardware Causes of Flash Data Errors

The Flash operation of C8051Fxxx microcontrollers is controlled by hardware, so hardware instability may cause Flash operation errors. Hardware reasons are mainly factors that can affect the normal operation of the CPU and factors that can affect the Flash operating environment. These factors include operating voltage, temperature, and external interference pulses, as follows:

① The parameters that can affect the reliability of CPU operation include the system clock source. If the system clock is provided by an external crystal oscillator, external electromagnetic interference causes sharp pulses and couples to the system clock, which will cause unpredictable operations.
② The system has completed reset when the operating voltage of the microcontroller is not stable (VDD rise time is less than the specified 1 ms). Since the code data needs to be read from the Flash when the system is reset, unpredictable errors will occur if the Flash voltage is unstable.
③ During the operation of the Flash, if the temperature and voltage are unstable, Flash data errors may also occur.

2.2 Software Causes of Flash Data Errors

The main reason for program loss is the defect of code design. Because the Flash of the microcontroller is controlled by hardware, the details of the operation cannot be controlled by software. Therefore, the imperfection of the program may cause the access error of Flash, resulting in errors in Flash data. These operations include: When the PSWE bit (PSCTL.0) is set to 1, the CPU executes the MOVX write operation in the interrupt service program. The interrupt service program uses the volatile storage area unit of xdata or pdata, which may cause the data written to the xdata or pdata storage area to be written to the Flash, resulting in problems. In addition, if an external crystal oscillator is used as the system clock, writing to the Flash when the clock is not stable may also cause program loss.

3 Solutions to the program loss problem

In view of the above possible reasons, the program loss problem can be solved from two aspects: software and hardware. In terms of hardware, the main thing is to provide a stable working environment for the system and avoid the influence of external interference on the CPU operating environment; in terms of software, the main thing is to standardize the operation of Flash.

3.1 Preventing program loss from hardware aspects

Note that the following methods are not applicable to all devices. You should choose the corresponding method according to the specific hardware situation:

① Install a VDD monitoring circuit on the RST pin and set the VDD monitoring as a reset source (set RSTSRC.1 to 1). In this way, if the system voltage is unstable, the system will automatically reset, thereby avoiding access to Flash when the voltage is unstable.
② Divide the external crystal clock by 2. A better way is to use the internal oscillator, which can improve the anti-interference ability of the system clock.
③ If an external crystal oscillator is used to provide the system clock, the signal line should be as close to the input end of the microcontroller as possible, and the crystal oscillator shell should be grounded.
④ For systems that use an external crystal oscillator as a clock source, the driving ability of the crystal oscillator should be enhanced as much as possible, which can also prevent program loss to a certain extent.

3.2 Preventing program loss from the software side

The main reason for program loss is program design defects, so reasonable program code design can greatly prevent this problem. There are many ways to prevent Flash data loss in the code:

① Disable interrupts when PSWE=1, so that the MOVX write instruction in the program is to Flash instead of XRAM.
② Access variables as little as possible when PSWE=1. Perform address decoding operations when PSWE=0, and perform MOVX write operations using indirect addressing. For example, to write multiple bytes to Flash, the indirect addressing and PSWE writing process is as follows:

unsigned char xdata * idata pwrite; //Use idata pointer to point to Flash
unsigned char *source;
unsigned char mydata;
for (addr = 0; addr < 100; addr++) {
//Get the data to be written when PSWE = 0
mydata = *source++;
//Modify the target address of the written data when PSWE = 0
pwrite = (unsigned char xdata *) addr;
PSCTL = 0x01; //PSWE=1
//Write data by assignment, and do not perform the modification operation of the target address at this time
*pwrite = mydata;
PSCTL = 0x00; //PSWE=0
}

In the above code, only the write Flash operation (*pwrite = mydata) is executed when PSWE = 1; other operations, such as modifying the value of addr, obtaining the source data and destination address, are executed when PSWE = 0.

[page]

③ Point the Flash write/erase pointer to the data or idata area.
④ Reduce the number of instructions that set PSWE to 1. Ideally, there are only two operations that set PSWE to 1, namely writing 1 Flash byte and erasing 1 Flash byte.
⑤ In the Flash write/erase function, enable VDD monitoring and set the reset source. The enable and set operations must be completed before the actual write operation occurs and after setting PSWE=1.
⑥ All write operations to RSTSRC in the code are completed by direct assignment (such as RSTSRC = 0x02), and cannot be completed by read/write instructions (such as ORL or ANL). For example, the code "RSTSRC |= 0x02" is illegal.
⑦ For devices that can use the PORSF bit to set VDD as the reset source, ensure that PORSF=1 is set when writing RSTSRC, that is, enable VDD as the reset source first, and then enable the operations of other reset sources, such as missing clock detector, comparison unit, and software reset.

4 A practical application solution

In some applications, due to the need for faster execution speed, the internal clock of the microcontroller cannot be used as the system clock source, so an external crystal oscillator is used to provide the clock. In this case, first of all, it is necessary to ensure that the system working parameters are normal in hardware.

In terms of software, since the most common cause of Flash loss is program problems, a variety of methods can be used in the code to prevent Flash data loss. First, when initializing the microcontroller, enable VDD detection and set VDD and clock loss as reset sources. If there is code to write/erase Flash in the program, switch the system clock before the write/erase operation, switch the system clock to the internal clock or divide the external clock by 2; after the write/erase operation is completed, restore the system clock, and achieve system stability by increasing the time overhead of the Flash modification operation [2]. The following is a program list for system clock switching, taking C8051F126 as an example:

void SYSCLKAdjust(unsigned char select) {
EA_Save=EA;
SFRPAGE=0x0f;
switch(select) {
case 0x01:
OSCICN_Save = OSCICN;
CLKSEL_Save = CLKSEL;
OSCICN = 0xc3;//Internal clock, no frequency division
CLKSEL = 0x00;
break;
case 0x02:
OSCXCN_Save = OSCXCN;
OSCXCN |= 0x70;//External clock divided by 2
break;
default://Select internal clock
OSCICN_Save = OSCICN;
CLKSEL_Save = CLKSEL;
OSCICN = 0xc3;
CLKSEL = 0x00;
break;
}
}

To restore the system clock to the state before the Flash operation, just write CLKSEL_Save, OSCICN_Save, OSCXCN_Save back to CLKSEL, OSCIN, OSCXCN.

The system clock (SYSCLK) of C8051F126 can switch freely between internal clock and external clock. The operation requirements during switching are as follows:

① During the switching process, first set the properties of the selected clock, and then use CLKSEL to set it to SYSCLK.
② During the restoration process, first use CLKSEL to select the clock source, and then set its properties.
③ If the external crystal oscillator is turned off during the switching process, to restore the external clock, wait at least 1 ms after startup, and then read XTLVLD (OSCXCN.7) to determine whether the crystal oscillator clock is stable. Otherwise, an incorrect value may be read.
④ After the external clock runs stably, divide it again without inserting a waiting cycle.
⑤ During the switching process, the external clock can be kept running, so that there is no need to wait for the external clock to stabilize during the restoration process, thereby saving time overhead, but at the cost of increased system power consumption.

5 Conclusion

Program loss can lead to various adverse consequences. In the worst case, the program cannot run normally, causing the entire system to crash and causing trouble for product applications. In the process of hardware design and code writing of the system, by paying attention to the above issues, the program loss problem can be effectively prevented. In addition, since the switching of the system clock only occurs during the writing/erasing process of the Flash, it will be restored to the original setting after the operation is completed, so the impact on the system running speed is very small, thus ensuring the realization of other functions of the system.