APPLICATION NOTE Safety Management for Space Environment Application ATmegaS128 Introduction The aim of this document is to highlight the key parameters of the ATmegaS128 that should be handled with care by any hardware and/or software developer in order to develop space safe applications. This document focuses on features that could be sensitive to radiation environment and that must be considered at application level. In addition, some tips to improve the safety of the global application are proposed.
1 FLASH/EEPROM Memory Management 1.1 Avoiding Flash Memory Content Loss The AtmegaS128 has lock bits to lock the content of the flash memory. We recommend to use the lock bits to prevent any loss of content of the flash memory. If no re-programming functionality is needed, we recommend locking the part using BLB0x and BLB1x lock bit (without using LBx bits). If the bootloader functionality is used we recommend locking the bootloader using BLB1x fuse bits (without using LBx bits). See the bootloader chapter of this document for complete understanding of risks related to programing in-flight. 1.2 Avoiding EEPROM Memory Content Loss The AtmegaS128 has lock bits to lock the content of the eeprom memory. We recommend to use the lock bits to prevent any loss of content of the eeprom memory. 1.3 In-Flight Reprogramming Considerations The global application of an ATmegaS128 relies on a bootloader that shall fit in the Bootloader of the Flash memory and on a user application in the application area of the memory. Bootloader 0x1FFFF Application 0x0000 We highly recommend to lock the flash memory content according to the Avoiding Flash Memory Content Loss procedure and to avoid in-flight flash memory reprogramming 2
When the memory is fully locked, both the bootloader and the application are protected against any write operation, thus preventing unexpected data loss. Data retention is also guaranteed. Application being locked, no application reprogramming is possible. Whereas we recommend not to use flash reprogramming during flight, it is possible to use the capability to reprogram the device. If end-user wants to use such in-flight flash programming, he can rely on one of the two possible setup proposed here after. 1.3.1 Application re-programming from the Boot. The reference configuration hypothesis for this use case are the following: Bootloader is locked - refer to Avoiding Flash Memory Content Loss procedure Application is not locked When the Boot is locked to avoid any corruption in the critical area of the software, the ATmegaS128 still allows to reprogram the application from the boot. 0x1FFFF Bootloader Program by UART, SPI, TWI.. Application 0x0000 The bootloader is always protected against unexpected lost. Data retention of bootloader is guaranteed. Application is not protected against unexpected data loss. Data retention of application after in flight programming have to be re-assessed with respect to the post write TID characterization results presented in the ATmegaS128 radiation report. 1.3.2 Application re-programming from ISP interface. The reference configuration hypothesis for this use case are the following: Bootloader is locked - refer to Avoiding Flash Memory Content Loss procedure Application is locked - refer to Avoiding Flash Memory Content Loss procedure 3
When both the boot and the application are locked, it is not possible anymore to reprogram the application through the bootloader, the only way to reprogram the application is to perform reprogramming through the external ISP Bootloader 0x1FFFF External re-programming is possible using ISP (SPI) Application 0x0000 Bootloader and application are always protected against unexpected data loss. Retention the two s after in flight programming have to be re-assessed with respect to the post write TID characterization results presented in the ATmegaS128 radiation report. 1.4 Fuse Bits Considerations The ATmegaS128 embeds a full set of fuse bits for configuration of the device parameters. As for the flash memory array itself, the fuse bits are SEU immune. The applicative effect of the fuses is only effective once at power-on they have been latched into volatile memory cells. Those volatile cells can be affected by SEU. If an error is induced in this cell by a heavy ion, the only way to recover from the faulty state is to apply a poweroff/power-on sequence to the device. The fuse bits loss will not be recovered by the internal watchdog as fuse bits are sampled at power-on only. Some fuse bits functionalities are critical for the application as the clock selection, the BOD level or the boot reset. To avoid dead lock of the device, we recommend to implement an external mechanism to cycle power-off then power-on the device when application does not answer anymore. Occurrence of such event is very low. For more details, refer to the ATmegaS128 radiation report. Whereas not related to radiation considerations, wrong configuration of the fuse bits may lead to a dead lock of the device without any possibility to recover on board. Please take care of the HW/SW alignment prior to any configuration of the fuse bits. 4
2 Bootloader Considerations The ATmegaS128 bootloader is intended for reprogramming of the application all along the life of the device. If the end-user needs to reprogram its application during his mission (in-flight write to flash) through the bootloader, he shall consider the following tips carefully. To avoid any corruption on the bootloader area (critical software for reprogramming), as mentioned in the before, the boot code shall be locked - refer to Avoiding Flash Memory Content Loss procedure. The following startup sequence shall be privileged to secure the correct user application execution Reset into the boot and check if bootloader activation is requested a. If the bootloader is requested, Run the bootloader, b. If the bootloader is not requested (application start requested), Check the application content (CRC or checksum) If the result is correct (application content not modified), then run the application by jumping at address 0x0000. If application check is incorrect, run the bootloader to download a correct application Take care of the watchdog behavior especially if the WDTON bit is programmed during startup sequence refer to Watchdog here after for details on recommendations over Watchdog behavior 3 Watchdog Considerations The ATmegaS128 embeds watchdog features that user must take care of in his software design to avoid unexpected time-out of his application. When WDTON (Watchdog enable On) is programmed, the watchdog is running directly after reset (with a default configuration of 16K clock cycles before it expires). To ensure a correct behavior of the application without spurious time-out, we recommend to clear the watchdog and set the watchdog to the value fitting the application requirement in the application startup file, this before any other applicative task. We remind user that watchdog excursion in temperature must be taken into account with enough margins. Refer to the datasheet for details on watchdog excursion. 5
4 Internal Oscillator Considerations The OSCCAL value is copied at reset from signature row into OSCCAL register. In case of use of OSCCAL register in the application, we recommend to make copies of this parameter in the RAM memory to be able to control its integrity all along the life of the application. The RAM being sensitive to SEU events, three locations should be used as copy of the OSCCAL parameter to allow efficient checking. In any case a reset will reconfigure the OSCCAL register with the default factory value. 5 ADC Considerations As SEU can affect ADC conversion results we recommend to execute multiple conversion and treatment before taking the converted value into account. 6 I/O Considerations The registers used for configuration of the IOs can be affected by SEU by modifying the PIN/PORT direction registers and I/O values. An optimized IO configuration process is recommended for each IO access. 6.1 Reading PIN/PORT registers Systematically configure the PIN/PORT in input before any port reading. Execute multiple PIN/PORT read to get the value. 6.2 Writing PIN/PORT registers Systematically configure the PIN/PORT in output before any port writing. 6.3 IO Conflict Management In case of SEU affecting the PORT direction, conflict on the IO lines could appear (risk of multiple drivers on the same line). To avoid such conflict, we recommend to Add a line resistor on all input pin to avoid conflict in case of SEU changing I/O direction to output Refresh port direction on a fast time basis to avoid long term switch to the faulty direction 6
7 Communication Links Considerations 7.1 USART As SEU can affect USART communication, we recommend to implement data integrity check mechanisms at application level. In case of error, the transmitter shall be warned of the error and shall take the decision to resend (or not) the data/frame to the receiver. 7.2 SPI At hardware level, on the USART, byte control can be activated use of the parity bits inside the USART configuration. At application level, frame control with CRC, checksum, security check, can be instantiated. As SEU can affect SPI communication, we recommend to implement data integrity check mechanisms at application level. In case of error, the transmitter shall be warned of the error and shall take the decision to retry (or not) the data/frame to the receiver. At application level, frame control with CRC, checksum, security check, can be instantiated 7.3 TWI In case of SPI use for memory access, we recommend to execute several reading of the required memory cell to ensure correct data reading As SEU can affect TWI communication, we recommend to implement data integrity check mechanisms at application level. In case of error, the transmitter shall be warned of the error and shall take the decision to retry (or not) the data/frame to the receiver. At application level, frame control with CRC, checksum, security check, can be instantiated. In case of TWI use for memory access, we recommend to execute several reading of the required memory cell to ensure correct data reading 7
8 General Considerations 8.1 Code behavior and Code limits 8.1.1 Default State of the Flash Memory In case of unexpected loss of PC or SP, the application can fetch anywhere in the flash memory. By default, in flash memory, un-programmed bytes are set to 0xFF. 0xFFFF (16 bit instruction code) corresponds to a valid opcode in the ATmegaS128 instruction set: sbrs r31,7 (Skip if Bit 7 in Register R31 is Set) In case of loss of the PC, if the PC is going above the end of your program, it will continue to fetch and execute all the flash memory up to rollover to 0x0000. We recommend to fill unused bytes of the flash memory with an opcode allowing infinite loop and let the watchdog expire. The opcode 0xFCFF rjump @PC is the infinite loop opcode. The PC is always aligned by words (2 bytes). It means that if all unused code memory is filled with 0xFCFF, the processor will never fetch 0xFFFC. 8.1.2 Unknown opcodes Due to SEU event, data may be corrupted while fetching the operations to be executed. In case of fetch of unexpected opcode opcode that is not allowed in the ATmegaS128 instruction set, the core executes a NOP. 8.2 Interrupts In case of unexpected interrupt (for example interrupt from an unused peripheral), user software can just jump in and out of the interrupt subroutine without doing anything inside this routine. User software can also decide to enter in an endless loop waiting for the watchdog to reset the part. 8.3 SFR/Register Regular Update We recommend initializing all the interrupt vectors, even if they are not used. We recommend the user to periodically refresh all the SFRs to their wanted values to correct all SEU effect on SFRs. 8.4 FMEA at System Level At system level, the end-user shall think about the criticality of the different signals/events managed by the ATmegaS128 to elaborate an adequate mitigation between the consecutive refreshes of the application. Key points to be answered are What happens if a signal is missing for a short period of time What happens if a signal is wrong for a short period of time 8
9 Revision History Doc Rev. Date Comments A 05/2016 Initial document release. 9
SAFETY-CRITICAL, MILITARY, AND AUTOMOTIVE APPLICATIONS DISCLAIMER: Atmel products are not designed for and will not be used in connection with any applications where the failure of such products would reasonably be expected to result in significant personal injury or death ( Safety -Critical Applications ) without an Atmel officer's specific written consent. Safety-Critical Applications include, without limitation, life support devices and systems, equipment or systems for the operation o f nuclear facilities and weapons systems. Atmel products are ATmegaS128 not designed nor intended Safety for use for in military Space or aerospace Application applications [APPLICATION or environments unless NOTE] specifically designated by Atmel as military-grade. Atmel products are not designed nor Atmel-41086A-AERO- intended for use in Safety_Management_for_Space_Environment_Application-ApplicationNote_05/2016 automotive applications unless specifically designated by Atmel as automotive-grade. 10 Atmel Corporation 1600 Technology Drive, San Jose, CA 95110 USA T: (+1)(408) 441.0311 F: (+1)(408) 436.4200 www.atmel.com 2016 Atmel Corporation. / Rev.:. Atmel Confidential: For Release Only Under Non-Disclosure Agreement (NDA) Atmel, Atmel logo and combinations thereof, Enabling Unlimited Possibilities, and others are registered trademarks or trademarks of Atmel Corporation in U.S. and other countries. ARM, ARM Connected logo, and others are the registered trademarks or trademarks of ARM Ltd. Other terms and product names may be trademarks of others. DISCLAIMER: The information in this document is provided in connection with Atmel products. No license, express or implied, by estoppel or otherwise, to any intellectual property right is granted by this document or in connection with the sale of Atmel products. EXCEPT AS SET FORT H IN THE ATMEL TERMS AND CONDITIONS OF SALES LOCATED ON THE ATMEL WEBSITE, ATMEL ASSUMES NO LIABILITY WHATSOEVER AND DISCLAIMS ANY EXPRESS, IMPLIED OR STATUTORY WARRANTY RELATING TO ITS PRODUCTS INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. IN NO EVENT SHALL ATMEL BE LIABLE FOR ANY DIRECT, INDIRECT, CONSEQUENTIAL, PUNITIVE, SPECIAL OR INCIDENTAL DAMAGES (INCLUDING, WITHOUT LI MITATION, DAMAGES FOR LOSS AND PROFITS, BUSINESS INTERRUPTION, OR LOSS OF INFORMATION) ARISING OUT OF THE USE OR INABILITY TO USE THIS DOCUMENT, EVEN IF ATMEL HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Atmel makes no representations or warranties with respect to the accurac y or completeness of the contents of this document and reserves the right to make changes to specifications and products descriptions at any time without notice. Atmel does not make any commitment to update the information contained herein. Unless specifically provided otherwise, Atmel products are not suitable for, and shall not be used in, automotive applications. Atmel products are not intended, authorized, or warranted for use as components in applications intended to support or sustain life.