2392796_en-US

Yes

MPC5644A core test

I am attempting to perform a core test on the MPC5644A chipset.

My current environment is Eclipse and Wind River.

I downloaded the manufacturer's library, e200Zx_ICST_RTMC_3.0.0, which contains several assembly source (.s) files.

Of these, vle compiles successfully.

However, book_e and spe fail to compile.

During compilation, errors occurred in various assembly instructions such as bc, bcl, bclr, xoris, bclrl, and bcctrl. I opened the properties of the book_e and spe assembly files and added -tPPCE200Z4NEG:simple to C/C++ Build --> Settings --> Diab Assembler --> Other --> Other options and flags, and successfully completed the compilation. However, during the debugging process, I reach just before `Fsl_call_test_execution_icst` in `fsl_self_test_icst.c`, which actually executes the core test. If I proceed to the next step, I fall into an infinite loop.

Checking with Eclipse's disassembly, I found that when I step into address 0x51518 (immediately after the start of `SPE_ICST_int_logical_test`), it jumps immediately to 0x3f2b90 (an empty space).

What should I do? I don't know where to start.

Re: MPC5644A core test

Hello,

SCST supports only following devices from MPC56xx family:

MPC560xP
MPC564xB-C

Since MPC5644A and MPC564xB share the same e200z4 CPU core, the CPU-focused portions of an SCST library may be adaptable. However, all integration aspects must be reviewed:

Exception vector addresses
Memory maps
Clock initialization
Peripheral dependencies
Linker script assumptions

The actual CPU test algorithms should be largely portable because they target the same e200z4 architecture.

NXP does not provide an official SCST library for the legacy MPC5644A device. However, since MPC5644A uses the same e200z4 core as the MPC564xB family, it may be possible to adapt CPU-focused self-test routines from MPC564xB solutions after reviewing device-specific integration details. Alternatively, a custom startup diagnostic implementation can be developed using the MCU's built-in safety mechanisms (ECC, CRC, watchdog, MPU, exception handling) to satisfy project-specific functional safety requirements.

What should I do? I don't know where to start.

If the code enters SPE_ICST_int_logical_test() at 0x51518 and then immediately branches to 0x3F2B90, which appears to be empty memory, my first suspicion would not be a CPU failure but rather a linker / library integration issue.
For an SCST library, this usually means one of the following:

1. Function pointer or branch table not linked correctly

2. Missing library object

3. Wrong memory model / VLE mismatch

4. SCST library built for another device

5. MMU/TLB translation issue

best regards,

Peter