Orphaned controllers on HC11P2

[CustomSarge_bas]

 Looking to readout/copy a P2 controllers' EEROM. OEM shut its' doors & refuses to return calls. System uses external EPROM for main body of code, but "probably" uses EEROM to configure onboard resources And its' external memory mapping. This may be impossible, but I need to explore all options.

 This is to repair existing units that blow the micros due to inadaquate serial port pin protection, not to make new units. We have a new design/build, but customers are understandably irate at being forced into a full retrofit/upgrade. We have access to working units, but are scared to do much testing as it looks like it can erase the EEROM, making another dead unit. We're not savvy on HC11s, went to Freescale from Zilog in the 908 era, and now using 9S08s.

 We'd appreciate any & all methods, or are we just "sadly out of luck"?

[CustomSarge_bas]

Howdy, Thanks, a great, straightforward idea/answer. When I read it, I was a little chagrinned. Been writing ass'y since 1978 (Z80) and didn't see it. I have a bus tracer, it could be as simple as a loop that loads Acc from the EEROM space. Loop length=trace buffer depth; run, change address & repeat for all EEROM area.

[celsoken]

Dear CS,

If this operation is legal according to the laws of US, I could provide you the EEROM contents.

I kept all legacy tools in order to provide my customers support for their (legacy) products.

Cheers,

Celso

[rocco]

Hi Sarge,

Welcome to the forum.

The EEROM data would be accessible to any program running within the HC11. Since your system is running from an external EPROM, that code can be unplugged, and maintenance code could be plugged in place.

It should not be hard to write an HC11 maintenance program that reads out the EEROM. That is if you have someone who can write HC11 code. The issue may be how that maintenance program reports the data to you, all dependent on the peripherals that are available to you.

[tonyp]

Legality issues aside (each one is responsible for their own actions), just looking at this from a purely technical view point (as what would one do with the P2 to make unauthorized copying practically impossible):

All the previous suggestions assume that the ROMON bit in CONFIG is either off (throwing off 32K of code space and the related security they offer), or that the internal memory is mapped at the lower 32K ($0000-$7FFF, possible for the P2 using the ROMAD bit in CONFIG) which again would compromise security.  I think if I were to choose a secure version of this device (indicated by the fact EEPROM is erased while trying to enter bootstrap mode) I'm serious about security so I would not allow for any backdoors either (unless I didn't know any better), such as let someone replace my external memory chips with their own with code to copy both my CONFIG & EEPROM, and the internal ROM mapped necessarily in the lower 32K.

With the internal (EP)ROM enabled and mapped at the upper 32K, the program always starts from the internal vectors (even in expanded mode, so checking the state of my MODB/MODA pins during reset would not help), not the external memory, as the internal resources have priority over external ones.  So, it's going to be (next to) impossible to even get a program started from external memory (without entering boot modes that would erase EEPROM).

In my hypothetical design I use the external memory to hold some extra code and data, but certainly not my vectors and startup code.

So, I think my potential cloner would be out of luck.  What do you think?

[celsoken]

Dear Tony,

I assumed it was a low volume controller by the given description, possibly using all app in external memory, no security at all. (That was very common in those days) So no bootstrap mode operation would be necessary and all you have to do is to add a "serial dump utility" in eprom.

Cheers,

Celso

[CustomSarge_bas]

 Thanks for the responses. It sure looks like we could spend a Lot of time to no avail. Legality aside, it's the customers who are getting the short end. It's our system that will replace this unit as a retrofit/upgrade, so we were just trying not to force the customers' hand. Also, just because the OEM closed up & won't respond, Doesn't mean they won't resurface and get all legal if we're successful.

 So netsum, I had to explore this and I appreciate the responses. But, the customers are going to have to bite down hard, this path isn't worth pursuing. There are fewer than 1k units total, so we'll just be a little busier overall.