HCS12 / HC12 CALL Instruction issue

[Zephurah]

Describe the bug For Motorola Processors in the HC12 / HCS12 family, CALL instructions are not correctly decoded in the Listing window. For processor HC12, opcode 4a is not registered as a CALL instruction to begin with in newest development build as of 7/25/22. For HCS12, PPAGE immediate values are not included in the addressing. Example:

      008004 4a  80  59  00    CALL       0x8059 , 0x0 =>LAB_000057+2

This instruction should point to a function at memory location 0x8059.

Example 2:

      01a4c5 4a  a5  38  01    CALL       0xa538 , 0x1 =>LAB_00a4c9

This instruction should point to a function at 0x1a538

To Reproduce Steps to reproduce the behavior:

1. Load given binary
2. Apply either HCS12 or HC12 processor languages
3. Go to memory location 0x8004
4. See error

Expected behavior CALL Instructions should have the IMM PPAGE value loaded into the function address.

Screenshots

Example File Example issue.zip

Environment (please complete t he following information):

• OS: Windows 10
• Java Version: "18.0.2" 2022-07-19
• Ghidra Version: 10.1.4 , 10.2 DEV_BUILD
• Ghidra Origin: Github, BUILT

[emteere]

Agree the mapping is suspect in your example. We have no raw firmware examples, other than sample project .elf and hex format for this and the manual is rather vague as to where the pages are actually laid out in physical memory. Was hoping someone would come up with a real world example. Is your example produced from GCC or from CodeWarrior. We based the mapping on CodeWarrior.

Previously the HC12 processor only supported the HCS-12X variant. They needed to be separated into the HC-12, HCS-12, and HCS-12X variants because the paging is different on each one. There is actually a very complicated page mapping going on in the HCS-12X with many paged areas and somewhat in the HCS-12 with PPAGE. They just aren't mapping to the values you expect, so we need to take a look at it and understand why.

This document goes into alot more detail on the HCS-12 and HCS-12X paging schemes. https://www.nxp.com/docs/en/application-note/AN3784.pdf

In particular, from the document:

• In the HCS12 Family, pages are chosen in sequential order in such a way that the last page of
memory is given the number 0x3F.
 For example: If your S12 device has 32 kB of Flash, the Flash will be conceptually divided into
two 16kB pages with numbers 0x3E and 0x3F. If it has 48 kB of Flash, 3 Flash pages will be
defined, with numbers 0x3D, 0x3E and 0x3F,

 In the HCS12X (typo?) Family, pages are chosen in sequential order in such a way that the last page of
memory is given the number 0xFF.
 For example: If your S12 device has 8 kB of RAM, the RAM will be conceptually divided into
two 4kB pages with numbers 0xFE and 0xFF. If it has 16 kB of RAM, 4 RAM pages will be
defined, with numbers 0xFC,0xFD,0xFE and 0xFF

I don't believe the CALL with the page instruction is supported on the HC-12. Nor is bkgnd. We could support this call variant even in the HC-12 and just remove the paging, or have it act as a simple flat memory.

[Zephurah]

The target MCU that the example flash was pulled off of is defined by this datasheet:

https://www.nxp.com/docs/en/data-sheet/MC68HC912DG128.pdf with an IC Mask of 0K50E

I have no idea how it was programmed, only the flash that was pulled off of it by an XPROG unit. It is an HC12 chip, not HCS12 or HCS12X

The paged memory in the flash pulled from the IC is located in offsets of 0x018000, 0x028000, etc, corresponding to memory pages 1, 2 etc. The following page from the above listed datasheet describes how I believe this flash is laid out.

Supporting the CALL instruction with paging would be fantastic for HC12 variants. I'm not entirely sure the best way to then load the Memory Map so that the CALL instruction with paging will correctly point to the right memory section, as currently in the newest development build only only files up to 0xFFFF can be loaded, whereas the target MCUs flash extended to 0x7FFFF.

I was loading the flash into various segments, however that was not effective.