Hello, Devkit-S12XE includes a bug on the PORT J2. This document shows the correct connection. The pin designation in the schematic, QSG, and pin markings on the board does not correspond to the connection on the board. Schematic: https://www.nxp.com/downloads/en/schematics/DEVKIT-S12XE-SCH.pdf  QSG: https://www.nxp.com/docs/en/quick-reference-guide/DEVKIT-S12XE-QSG.pdf  Pin markings on the board: In particular, these are the following pin numbers of PORT J2 where the bug was found: 16, 17, 18, 19 The real connection is as follows: I hope it helps, Best regards, Diana

How to get device ID and write program once field without programming application to the S12Z device in the CodeWarrior (Eclipse).   Even the datasheet does not present the device ID it can be read at address 0x1FC000. The device ID is size of 8 bytes from 1F_C000 to 1F_C007. The meaning of the field is confidential information. Of course, other "reserved" fields on higher addresses can also be read but their meaning is also confidential. The ID is not presented in the documentation because it has reason for company only. However, some users require unique identification of the device. It is possible to use this number. In order to read the ID, it is enough to create simple project in the CodeWarrior and connect to the device without programming it and run “mem” command in the debug shell window. If you do not want to remember address ranges, then it is better to prepare command file and execute it.   Of course, we can also simply use memory window.   It is a different story if we want also to see program once field. In this case we have to execute a set of commands to get it. As an example of command file which can be executed to get device ID and program the program once field I present two command files. They can be executed in the debugger window – see and test attached project. They are AAA_Read_Device_ID_And_OTPROM.cmd  and AAA_ProgramOnceField.cmd. The project which also presents reading and writing program once field is not relevant but should be created for the device we want to play with. It is not required to be code (simple code, enough to use what is generated by wizard) loaded into the MCU’s memory. However, necessary is the debugger is connected to a memory. Because of this it is enough to set:   …. And press debug   In the debug enable “Debugger Shell”:   Before continuing please modify flash clock setup in both files to value suitable for programming on the basis of the oscclk you use. In the files search for lines    Write into debugger shell command which runs the AAA_Read_Device_ID_And_OTPROM.cmd: source "c:\D\CODING & SW\ECLIPSE\S12ZVMC-FLASH-WRITEONCEFIELD-CW106\AAA_Read_Device_ID_And_OTPROM.cmd" (it is possible you have different path to the file…please change it)   The command will execute and shows: Device ID And Program field phrase 0. If you want to see another phrase you should modify AAA_Read_Device_ID_And_OTPROM.cmd line set PHRASE 1. Change 1 to the phrase you want to see and run the command presented above “source …..” again. It is enough to press arrow up on the keyboard to see and use previous commands.   In order to program selected field use and run command “source” with the file: AAA_ProgramOnceField.cmd source "c:\D\CODING & SW\ECLIPSE\S12ZVMC-FLASH-WRITEONCEFIELD-CW106\AAA_ProgramOnceField.cmd"   The same note as previosly, the path you have could be different so adjust it. The same line as in previous file should be changed to select the phrase you want to program. As a result, you will see programming algorithm and also read back of the field, example of output: %>source "c:\D\CODING & SW\ECLIPSE\S12ZVMC-FLASH-WRITEONC EFIELD-CW106\AAA_ProgramOnceField .cmd" ############################ Programming Field = 2 ############################ cmdwin::mem 0x0386 %x = 0x30 cmdwin::wait 1000 cmdwin::mem 0x0382 %x = 0x05 cmdwin::mem 0x038C %x = 0x07 cmdwin::mem 0x038D %x = 0x00 cmdwin::mem 0x038E %x = 0x00 cmdwin::mem 0x038F %x = 2 cmdwin::mem 0x0390 %x = 0xA2 cmdwin::mem 0x0391 %x = 0xB2 cmdwin::mem 0x0392 %x = 0xC2 cmdwin::mem 0x0393 %x = 0xD2 cmdwin::mem 0x0394 %x = 0xE2 cmdwin::mem 0x0395 %x = 0xF2 cmdwin::mem 0x0396 %x = 0xA3 cmdwin::mem 0x0397 %x = 0xB3 cmdwin::mem 0x0386 %x = 0x80 cmdwin::wait 1000 ############################ Read back Programmed Field = 2 ############################ cmdwin::mem 0x0386 %x = 0x30 cmdwin::wait 1000 cmdwin::mem 0x0382 %x = 0x01 cmdwin::mem 0x038C %x = 0x04 cmdwin::mem 0x038D %x = 0x00 cmdwin::mem 0x038E %x = 0x00 cmdwin::mem 0x038F %x = 2 cmdwin::mem 0x0386 %x = 0x80 cmdwin::wait 1000 cmdwin::mem 0x0390 8      390  $a2 $b2 $c2 $d2 $e2 $f2  $a3 $b3   . . . . . . . .    Now the question, where to find commands to be able to prepare such a command files, can be asked. 1) The first information source is the CodeWarrior help. For example, search for keyword DW and it could find a command list. 2) Tcl Reference Manual  3) http://www.tcl.tk/    Finally, in the attached project can be seen also approach how to write program once field by SW. Of course, mentioned cmd files are also part of the project.

The S12Z devices contain unmaskable machine exception interrupt for severe system problems. The Memory Map Control module (MMC) generates this exception in the case of illegal memory access and uncorrectable ECC errors. The MMCECn register is set to a non-zero value if an S12ZCPU access violation or an uncorrectable ECC error has occurred. At the same time when this register is set to a non-zero value, access information is captured in the MMCPCn (program counter) and MMCCCRn (CCR U, X and I bits) registers. The MMCECn registers are cleared by writing the value 0xFFFF. Unfortunately, the exact address with corrupted data isn’t stored in any user-accessible register and this makes the debugging more difficult.   In the case of reading memory with an uncorrectable ECC error, the MMC causes jump to the address in the Machine Exception vector as soon as the current instruction finishes execution. This may be used in workaround code for detection of the exact address with corrupted data. See attached example code. Note: The code detects only the first address of the phrase with uncorrectable corrupted data. The solution for detecting multiple ECC issues isn't included.     The execution of a machine exception code isn’t straightforward in this case. Please read the simplified procedure: The reading of uncorrectable corrupted data (double bit ECC error) will invoke machine exception. The ma_counter variable is incremented to 1. The MMCEC register is checked for detection of machine exception source. If ECC at EEPROM or P-Flash is detected as a machine exception source, the sequential reading of appropriate memory starts. Note: Since the P-FLASH is protected by 39-Bit ECC Scheme, we should read at leats single word(byte) from every aligned 32bit phrases. The global variable add contains a current reading address. When CPU read the uncorrectable corrupted data again, the MMC causes jump to the address in the Machine Exception vector again. The ma_counter variable is incremented to 2. When ma_counter is 2, we may store add variable address with corrupted data, clear ma_counter and clear pending flags in MMCEC register. Application project-specific user code for machine exception case may be applied (signalization, repair,…) Please be aware that no information is stored on the stack during entering machine exception handler (missing return address). So, default RTI instruction on end of routine cannot be used for returning to the application code. We must end the machine exception routine by MCU reset or jump to some known code entry point or by an endless loop.  This code is only a simple example code and does not cover all conditions. More details regarding simulating ECC issue at EEPROM and P-Flash: S12Z - Simulating ECC errors at EEPROM by cumulative write  https://community.nxp.com/docs/DOC-334327 

This presentation walks you through the features and specs of the most integrated solution for CAN node applications. Details @ http://www.freescale.com/S12magniV

In the ZIP file you can find two CodeWarrior projects, one for S12ZVM and other for S12ZVL device, demonstrating the trimming of Autonomous Clock (ACLK - trimmable internal RC-Oscillator) which can be selected as clock source for some CPMU features. Also the Autonomous Periodical Interrupt feature using the trimmed ACLK as a clock source is demonstrated too in this SW example.