XC16x Application Note, V 0.1, Sep. 2003 AP16081 How to generate a successful ROM mask for XC16x microcontrollers Microcontrollers Never stop thinking.
XC16x Revision History: 2003-09 V 0.1 Previous Version: - Page Subjects (major changes since last revision) Controller Area Network (CAN): License of Robert Bosch GmbH We Listen to Your Comments Any information within this document that you feel is wrong, unclear or missing at all? Your feedback will help us to continuously improve the quality of this document. Please send your proposal (including a reference to this document) to: mcdocu.comments@infineon.com
Introduction Table of Contents Page 1 Introduction... 4 2 Verification Process... 5 3 Single Chip Reset mode... 6 4 Potential sources of error... 7 5 Differences between errata of different versions... 8 6 Further items to be checked... 9 6.1 Differences between XC16x and C16x derivatives... 9 6.2 Chip select signals... 9 6.3 Differences regarding Identification Registers... 9 6.4 Trap routines...10 6.5 Interrupt Service Nodes...10 6.6 How to fill up unused code sections...11 6.7 Check of oscillator-inverter characteristics of the specific microcontroller type and step...11 7 Transfer of ROM code to Infineon...12 8 Available Documents...13 9 Application form for ROM code transfer...14 Application Note 3 V 0.1, 2003-09
Introduction 1 Introduction During the different phases of an application development users often have to deal with different derivatives of a product. Usually, during the development phase, a microcontroller with flash memory or an incircuit emulator is used and for series production the corresponding ROM device will be used instead. Furthermore, due to the continuous improvement and innovation process at Infineon, there might be newer development steps of the same derivative with improved or enhanced features. These device specific differences have to be taken into account during the development process. This application note shall provide hints on items to be considered when at the end of the development phase a ROM code for a new ROM mask derivative has to be generated. Note: This application note cannot cover all relevant topics. It can only give hints for a successful ROM mask generation. The intention of this document is to give a structured guideline on how to handle the process of a ROM mask generation and should help to avoid general mistakes. Application Note 4 V 0.1, 2003-09
Verification Process 2 Verification Process The flow chart shows the major steps needed to check the relevant items for a successful ROM mask generation in correlation with the chapters of this document. Figure 1 Flow chart for ROM mask generation Application Note 5 V 0.1, 2003-09
Single Chip Reset mode 3 Single Chip Reset mode Single chip reset mode is a functionality already known from the newer members of the C16x family. This mode is available on all XC16x derivatives. The idea of single chip reset mode is to have a default configuration to define the startup behavior of the XC16x. Single chip reset mode is enabled by applying a high level to the signal EA# during reset. If single chip reset mode is used care should be taken about the following items: There are internal configuration pull-ups on RD#, WR#, EA#, PORT0 and a pulldown on ALE that are active during reset only. They will be switched off again at the end of the internal reset sequence after the corresponding logic levels have been latched. Bootstrap loader, start mode (internal or external start, definition of start address) and control of the Reset out signal are activated via EA#, WR#, RD# and ALE pins. Information about the dimensioning of the necessary pull-downs and pull-ups can be found in a dedicated application note [1]. Adapt mode can not be set in single chip reset mode (if an emulator with press-on adapter is used the soldered device has to be in the adapt mode. This is only possible if EA# = 0 and P0L.1 = 0). The reset value of register RSTCFG depends on the values latched from PORT0 in case of an external reset. After a single-chip reset (EA# = 1) register RSTCFG is loaded with the default value 0DFFh. The user can change the reset configurations at any time via the dedicated configuration registers, for example with the EBCMOD0/1 registers or with the PLLCON register. By doing this clock generation mode configuration, segment address line select, chip select line select etc. can be changed after startup. Please note that configuration registers like EBCMOD0/1 or PLLCON are protected by a special register security mechanism and dedicated command sequences are necessary to change them (see Register Security Mechanism chapter in corresponding User s Manual System Units). Application Note 6 V 0.1, 2003-09
Potential sources of error 4 Potential sources of error Note: All documents like datasheets, user s manuals or addendums for the selected device should be crosschecked in all aspects regarding new functions or deviations to former versions and the latest documents should always be used. The latest XC16x related documents can be found by the following link: http://www.infineon.com/cgi/ecrm.dll/ecrm/scripts/prod_cat.jsp?oid=-8137. In case for any reason this link does not work you can find such information by the links: Infineon home page: http://www.infineon.com Infineon microcontroller home page: http://www.infineon.com/microcontrollers Application Note 7 V 0.1, 2003-09
Differences between errata of different versions 5 Differences between errata of different versions First of all it should be checked if the errors documented in the errata sheets (which might be different for flash and ROM versions of the same derivative) are of any relevance for the respective application. In the table below an example can be found how to crosscheck the different errata. A similar table might be created for the individual ROM mask. When moving from one step to another or from a flash version to a mask version the errata of the corresponding versions have to be compared. It should be checked if there are different errata or same errata and what the possible implication on the software implementation is. Table 1 Comparison of different errata regarding the different devices XC164CS-16RF AA Step V 0.1 XC164CS-16FF AD Step V 0.1 Ext. Bus Controller EBC_X.003 EBC_X.003 CPU_X.002 CPU_X.002 CAPCOM6 CC6_X.002 CC6_X.002 OCDS OCDS_X.001 OCDS_X.001 OCDS_X.002 OCDS_X.002 OCE OCE_X.001 OCE_X.001 ADC ADCC_X_FBC.15 Application Note 8 V 0.1, 2003-09
Further items to be checked 6 Further items to be checked Many possible pitfalls can be avoided by checking the software in a Flash version first before ordering a ROM mask. This is the usual approach anyway. In addition the following chapters give a couple of hints and further points of special attention. 6.1 Differences between XC16x and C16x derivatives Customers who are already experienced users of C16x derivatives and are planning to develop a new or upgraded application based on the new XC16x architecture should take care about the differences between those two families which are documented in [2]. 6.2 Chip select signals Sometimes it is necessary to clarify the level of the chip select signals during and after reset. That could be essential if external devices should have a clear logic level on their chip select inputs in case the microcontroller is reset, because usually the level of the port pins of an XC16x microcontroller during reset are high impedance. In contrast to that the potential chip select outputs are driven high by internal weak pull-up devices during reset on all XC16X derivatives. After reset the state of the chip select lines depends on the state of the #EA signal during reset: In case of #EA = 1 (single chip reset mode, see chapter 3) chip select lines will not be activated. The normal port function will be active instead (switched to input after reset). In case of #EA = 0 the state of the chip select signals is defined by the levels on Port0 during reset which are latched into register RSTCFG. 6.3 Differences regarding Identification Registers In case the user s application accesses identification registers Infineon should always be contacted for details regarding the contents of the identification registers. There are some registers which enable users to read out the manufacturer, device description, step etc., and the contents may differ between different steps of different program memory versions. Some examples can be found in the table below. Application Note 9 V 0.1, 2003-09
Further items to be checked Table 2 Example identification registers for the XC16x Family (all values are hexadecimals) Device Steps ID Byte (returned in BSL start sequence) IDMANUF (F07Eh) IDCHIP (F07Ch) IDMEM (F07Ah) IDPROG (F078h) IDMEM2 (F076h) XC164CS- 16FF ES-AA D5 1820 2302 3020 4040 0000 XC164CS- 16FF ES-AB D5 1820 2302 3020 4040 0000 XC164CS- 16FF ES-AC D5 1820 2303 3020 4040 0000 XC164CS- 16FF ES-AD D5 1820 2303 3020 4040 0000 XC164CS- 16RF ES-AA D5 1820 2301 1020 0000 0000 6.4 Trap routines All vector locations for used and unused class A and class B traps should be filled up with suitable jump instructions to enable a defined program flow behavior in case of the occurrence of a hardware trap. It should be assured that the target address for such a jump instruction contains some reasonable trap handling code. The trap routines can easily be tested by a flash version of the microcontroller family that has been chosen for the ROM mask. 6.5 Interrupt Service Nodes All interrupt vector jump addresses should be terminated with a defined code sequence. Some compilers already offer such features. Application Note 10 V 0.1, 2003-09
Further items to be checked 6.6 How to fill up unused code sections The format of the Hex-files for the ROM Mask has to be Intel H86 format. Unused ROM cells should be filled up with 95h which is an undefined opcode and will generate an undefined opcode trap in case of execution. In case the PC (program counter) will jump into an unused code area, a trap will occur and the trap routine (written by the user) will handle this error. Please be aware that the opcode C3h which was often recommended to be used as fill pattern for the C16x microcontrollers cannot be used any longer with the XC16x microcontrollers since C3h is a defined opcode for XC16x: it will be decoded as the instruction CoSTORE. 6.7 Check of oscillator-inverter characteristics of the specific microcontroller type and step The characteristics of the oscillator-inverters used in the different derivatives and steps of the XC16x family members might be slightly different. Therefore it is strongly recommended to check the start-up and oscillation reliability, also when switching from a flash to a ROM derivative of the same microcontroller type. Often crystal suppliers can already give recommendations for the microcontroller derivative that is planned to be used. Although focused on the C16x microcontroller family members a lot of useful hints regarding oscillator circuit design can be found in [4]. All qualified crystal and ceramic resonator suppliers provide the service of checking the oscillation startup and oscillation reliability in the final application. Please contact the crystal or resonator supplier for checking the application circuit with both devices, Flash and ROM version. Application Note 11 V 0.1, 2003-09
7 Transfer of ROM code to Infineon AP16081 Transfer of ROM code to Infineon Hopefully all main pitfalls have now been examined and the ROM code of the device that has been chosen has been thoroughly tested with a JTAG debugger or emulator and with the corresponding flash derivative. Now the ROM code has to be transferred to Infineon to enable Infineon to produce the corresponding ROM mask derivative. For the ROM code transfer Infineon offers an Internet tool. To be able to use it please apply for an account first. The application form is found in chapter 9. Please send the completed form to the given fax number. Within one working day an e-mail with account name and a URL for the ROM code transfer server will be sent out. A password for the account will be sent out by fax. In the following figure the process for the actual ROM code transfer, review and order can be found. Action Customer Infineon Customer uploads ROM code Support engineer reviews code Support engineer uploads adapted code Customer reviews adapted code Customer signs the order Support engineer closes case Figure 2 ROM code transfer process for microcontrollers A detailed description about the handling of the Internet application for exchange and verification of your ROM code can be found in [3]. Application Note 12 V 0.1, 2003-09
Available Documents 8 Available Documents [1] Application Note no. ap16037, Reset and System Startup Configuration via PORT0 or Register RSTCON, http://www.infineon.com/cgi/ecrm.dll/ecrm/scripts/public_download.jsp?oid=10051& parent_oid=-8137 [2] Application Note no. ap16031, Migration from C161/C164/C167 Microcontrollers to the XC161/XC164/XC167, available from your local Infineon representative [3] Extranet Application Manual, October 1999, available from your local Infineon representative [4] Application Note no. ap242005, Crystal Oscillator of the C500 and C166 Microcontroller Families, http://www.infineon.com/cgi/ecrm.dll/ecrm/scripts/public_download.jsp?oid=9746&p arent_oid=-8137 Application Note 13 V 0.1, 2003-09
Application form for ROM code transfer 9 Application form for ROM code transfer Application Note 14 V 0.1, 2003-09
http://www.infineon.com Published by Infineon Technologies AG