HC16 module for IDA Pro 4.7.0.830

[Kha0S]

Yeah... just figured out the reset vector at the head of the ROM...

0000: 0220 -> unused/ZK/SK/PK initial values
0002: 0220 -> reset vector (PC, PK+PC)
0004: 08F6 -> stack pointer (SP, SK+SP)
0006: 0000 -> page pointer (IZ, ZK+IZ)

After finding a valid entry point, I'm finding that the processor type is getting set incorrectly somewhere... blah.

Back to trying to get this module to build with the 4.8 SDK.

[Kha0S]

Booya!

Got it.

I'm going to post a binary copy of the HC16 module built for IDA Pro 4.8 later on.

[Kha0S]

Here's a version of Colby's HC16 module built against the IDA Pro 4.8 SDK.

Installation instructions are the same as he posted at the top of this thread.

.... and now, on to debugging.

To find the entry point for your particular ROM, look at the first eight bytes of the file ROM.

0000: 0220
0002: 0220
0004: 08F6
0006: 0000

(above is from an A4SG900C)

This is the HC16 reset vector. The format of the reset vector is:

0000: xx ZK SK PK
0002: PC PC PC PC
0004: SP SP SP SP
0006: IZ IZ IZ IZ


So, to get the entry point, you really want (PK << 4) + PC... PK is the extension register for PC (ie, it's the most significant nibble of the 5 nibble total counter).

So, in the above example, the PK nibble is 0, and the PC bytes are 0220. Therefore, the final destination of the reset vector is 00220.

After that, sit back and wait for the rest of the file to cascade apart.

All of the logic for actually running the ECU appears to be in the lower EEPROM segment (0x00000 - 0x1FFFF). Obviously, all of the variables live in the RAM segment (0x20000 - 0x27FFF).

There doesn't appear to be any executable code in the upper EEPROM segment (0x27FFF - 0x2FFFF)... just maps. I've successfully found the code in my A4SG900C that manages high/low detonation fuel map switching, which points quite obviously at the IAM in memory, and has divulged the location of the map threshold (0x2934D).

Something to keep in mind here is that all of the memory references (ie, anything using effective addressing) uses the K-register offsets. The result is that IDA, with Colby's module, currently generates some very confusing output.

For instance... the high/low det logic:

ROM:00011456 sub_11456: ; CODE XREF: sub_11400p
ROM:00011456 LDAA loc_124, Z
ROM:0001145A CMPA loc_934C+1
ROM:0001145E BCS loc_11496
...
ROM:0001148A LDY #9358h
ROM:00011496 loc_11496: ; CODE XREF: sub_11456+8j
...
ROM:000114C0 LDY #94CEh

Basically, this loads the IAM out of RAM (0x20124) into A, compares it against the low/high det threshold value (0x2934D). If the IAM is less than the threshold, branch to the code that ends with setting Y to point at the high det map (0x294CE). If it's greater than the threshold, do some stuff, then set Y to point at the low det map (0x29358).

Essentially, since IDA is only looking at the addresses in the instructions, and isn't tracking the value of XK, YK, and ZK extension registers, the addresses are all wonky. Doh!

Colby -- any idea on how we might address the issue?

/Andrew

(PS ... the pun above was inadvertent. )

[cboles]

I don't know how to fix the segment problem. I had posted to here for advice on that before. Apparently IDA can support you creating code segments where registers (e.g. the _K registers) have predefined values. I thought I had implemented this correctly in my module, but I can't seem to get it to work. You could recompile the module to always compute addresses with ZK=2, but that is kinda sloppy.

[Kha0S]

I don't know how to fix the segment problem. I had posted to here for advice on that before. Apparently IDA can support you creating code segments where registers (e.g. the _K registers) have predefined values. I thought I had implemented this correctly in my module, but I can't seem to get it to work. You could recompile the module to always compute addresses with ZK=2, but that is kinda sloppy.

Especially in those lower EEPROM code segments where ZK might realistically be 1.

I might try rebuilding with a forced ZK and seeing how much more readable it is... any pointers to where in the module source I'd need to edit? I'm sure I can find it, but you likely know offhand.

Still, I have to say, you did a heck of a job on this module... the fact that I can disassemble this ROM at all is testament to your work.

/Andrew

edit:

Actually, thinking about it, I don't think that ZK will ever be set to 1 in this particular application. It looks like the Denso engineers purposely placed all of their data in the upper EEPROM segment so it would be addressable contiguously with the RAM segment. Hmmm....

[cboles]

ZK=2 all of the time, from what I have seen in these ROMS...

[Kha0S]

ZK=2 all of the time, from what I have seen in these ROMS...

Yeah... I just skimmed for all TBZK instructions, and they're all preceded by an LDAB #2h. Looks like a safe assumption to me.

Just surprises me that they don't set ZK=2 in the reset vector. Ahwell.

I think I'll try the ZK=2 hack... it should clear things up a lot.

[JonnyM]

You will get the correct address if you add a user defined offset of 20000h (Ctrl-R) to all nn,Z operands.
It's not very difficult to write a .idc scripts that does it automagically..

The nn,Y has to be done manually since Y is not static.

Here's an example of how it looks:

ROM:00011502 loc_11502: ; CODE XREF: sub_114DA+10
ROM:00011502 2A 20 00 52 00 0C brclr (byte_20052 - 20000), Z, #20h, loc_11514
ROM:00011508 2B 08 17 EE 00 06 brset (byte_217EE - 20000), Z, #8, loc_11514
ROM:0001150E
ROM:0001150E loc_1150E: ; CODE XREF: sub_114DA:loc_114F0R
ROM:0001150E ; sub_114DA+1Cj
ROM:0001150E ; sub_114DA+22j
ROM:0001150E 37 BD 93 5E ldy #(byte_2935E - 20000h)
ROM:00011512 B0 36 bra loc_1154E

[ev8siv3]

Does anyone have this module available for IDA Pro 4.9.863? I have the 4.9 SDK and the original source from this post but I cannot get it to compile. Help??

[ev8siv3]

I also have Visual Studio 10.. When I load the unmodified files from here I get an output of 172kb which then dissapears from IDA's list when I try to select it.

I tried updating the files with the new ones from the SDK and got all kinds of errors. Any one have experience with recompiling for 4.9?

[LGT-3-6]

Does anyone have this module available for IDA Pro 4.9.863? I have the 4.9 SDK and the original source from this post but I cannot get it to compile. Help??

I will probably want to do this soon enough, let us know your results

The IDA page says that IDA Pro 5.x support the 68HC16? hmmm

[cboles]

IDA Pro has had support the HC16 for a while. I just didn't want to pay the extra money for it, so I wrote the HC16 module. Since then I have broken down and purchased the full version since I am dealing with so many new processors...

Does anyone have this module available for IDA Pro 4.9.863? I have the 4.9 SDK and the original source from this post but I cannot get it to compile. Help??

I will probably want to do this soon enough, let us know your results

The IDA page says that IDA Pro 5.x support the 68HC16? hmmm

[ev8siv3]

IDA Pro has had support the HC16 for a while. I just didn't want to pay the extra money for it, so I wrote the HC16 module. Since then I have broken down and purchased the full version since I am dealing with so many new processors...

Does anyone have this module available for IDA Pro 4.9.863? I have the 4.9 SDK and the original source from this post but I cannot get it to compile. Help??

I will probably want to do this soon enough, let us know your results

The IDA page says that IDA Pro 5.x support the 68HC16? hmmm

d'oh I just realized it's listed as 6816 and uses 68HC16Z

[LGT-3-6]

To find the entry point for your particular ROM, look at the first eight bytes of the file ROM.

0000: 0220
0002: 0220
0004: 08F6
0006: 0000

(above is from an A4SG900C)

This is the HC16 reset vector. The format of the reset vector is:

0000: xx ZK SK PK
0002: PC PC PC PC
0004: SP SP SP SP
0006: IZ IZ IZ IZ


So, to get the entry point, you really want (PK << 4) + PC... PK is the extension register for PC (ie, it's the most significant nibble of the 5 nibble total counter).

So, in the above example, the PK nibble is 0, and the PC bytes are 0220. Therefore, the final destination of the reset vector is 00220.

I don't believe this is completely correct. This doesn't appear to work the the 05 LGT roms I'm trying.. They point to AAC, and there lies garbage. Also I'm not sure what you're doing with PK, it makes perfect sense for it the be the LSN, it's the first 4 bits of a 20bit address, PC is the lower 16 bits.. No? I just started thumbing through the architecture :/

[JonnyM]

I don't believe this is completely correct. This doesn't appear to work the the 05 LGT roms I'm trying.. They point to AAC, and there lies garbage. Also I'm not sure what you're doing with PK, it makes perfect sense for it the be the LSN, it's the first 4 bits of a 20bit address, PC is the lower 16 bits.. No? I just started thumbing through the architecture :/

Well, this thread is for Motorola HC16 - a cpu which the 05 LGT doesn't have..
I think you'd better read the forum a bit more before starting to work on the roms