JP1 Remotes

I just joined the forum today, although I have done a little lurking in the past. I don't own a JP1.2 compatible remote, although I am considering purchasing one (URC-10820).

I've taken a quick look at the datasheet, and have posted my comments to some points below. Normally I'm given a clean slate when I'm doing this, I don't have to override the CPU initialization in some way (like with a fancy and expensive JTAG box).

mr_d_p_gumby wrote: The JP1.2 connector is wired like this:

Code: Select all

   V+ 1  2 RESET
  GND 3  4 DATA-IN
 BKGD 5  6 DATA-OUT

As you can see, pin 5 is wired to the BKGD pin of the CPU. This is the "single-wire debugger" interface documented by Freescale for the HC12/HC08/HCS08 series of processors. There was some initial excitement about this being a means of talking to these remotes, but I doubt that it will be of any practical benefit. It seems that once security is enabled in the flash memory, the BKGD functionality is reduced to one operation: erasing the entire flash memory. Why did UEI put this connection on the JP1.2 connector? Probably so that they could do a complete firmware update if they wanted to, but I'm sure that its only an option of last resort. I doubt that the average JP1 user would have a sufficient level of interest, but it certainly means that you could in theory generate your own code from scratch and load it into the remote via the BKGD pin. I think this would qualify as the ultimate "extender"!

I'm wondering if perhaps that is the OFA way of doing code updates? Just erase the whole thing and reprogram it. Granted, EEPROMs have a limited write span, but how often would OFA be reprogramming this things over the life of the unit? Once? Twice? Five times tops I'd figure (and that really depends on the customer).
I would figure that adding new remote codes to the database would require updates to the main code that runs in the CPU anyway, so re-flashing the entire thing doesn't cause any harm (they do mention that they reserve the right to substitute your remote, so they're not really responsible for keeping your Keymover mappings, etc.)
Also, once the flash is erased, then it could be reprogrammed via the BKGD pin - but that doesn't explain the Data In/Out pins. I'll have to read Chapter 14 very carefully, because I didn't see the mention of erasing the flash (not that I doubt it's not there).

mr_d_p_gumby wrote: Activating the RESET pin does pretty much what you'd expect. After a RESET, the remote gives a two-blink A-OK indication on the LED, the same as the reset you get when the batteries are installed.

Yeah, this sounds right... Usually when a RESET is asserted, the CPU jumps to a pre-defined reset vector for initialization (which is your "BootROM"). In the case of this CPU, it does an indirect jump to whatever is at $FFFE:$FFFF. The idea here is that a two-byte address (could be anywhere in the memory space) is stored there (in non-volatile memory, i.e. flash) and that's where the CPU goes on reset. The boot loader or the main appliation probably blinks the LED.

mr_d_p_gumby wrote: So, that leaves us with the two pins which I've labelled DATA-IN (pin 4) and DATA-OUT (pin 6). As you can see from the schematic, these are wired to two of the input pins used by the keyboard matrix. When pulled low, these pins are capable of generating an interrupt that can wake the processor up from sleep mode. I've tried manipulating these lines in various ways while the remote is operational, but about all it seems to accomplish is to stall the keyboard scan routine and/or force a reset.

<huge snip>

Good luck. As always, if you are caught playing around with JP1, the Secretary will disavow any knowledge of your actions.

This could be an OFA backdoor mode, or it might be some issue with the CPU. Could be that Motorola didn't think of that potential electrical combo and and chip just goes crazy (CPU bug).

I'll give the datasheet a thorough reading as time permits and see if I can come up with anything.

-- Joe

I seem to have temporarily misplaced my notes on the subject, but I am very interested in the possiblity of entering one of the "Stop Modes" (perhaps stop2) and seeing where it goes from there. I'm just researching (when time permits) and lurking at present, but hope to be able to contribute something worthwhile soon.
Jim

In order to help this project along, I have picked up some URC-8820 remotes with a view to giving them to anyone who's working on this project. All I ask is that you cover the $4 postage.

Just a reminder that my offer of a free URC-8820 remote to anyone that can use it for the purpose of trying to hack the JP1.2 platform is still good.

So far I haven't received a single request, which isn't very encouraging.

Hi Rob. I recently upgraded to a Kameleon 8206 and was gutted to find out it uses the new chip and wasn't JP1 compatible. I've been browsing the forum for a while and have been really impressed with the effort and help provided by everyone involved. You guys rock! I was excited to see this thread and hope some progress can be made with the new chips. But given things might have stalled I'll be making an effort to read through all the information available to try and work out how I can help. Just wanted you to know that there's people who are keen to see a breakthrough and appreciate all the effort everyone has made so far.

Rob,

What ever happened with them writing a DLL routine that you could call into IR.exe. Have you asked them lately? I know there were limited resources, but a few months have passed.

I thought Tommy quit working on the remote stuff? Maybe this will reenergize him. I'd like to see this happen because the lack of remotes available with JP1 (like at Walmart for instance). I haven't seen the 8811w in a long time. I have 8 of them at home and they are wearing.

Harold

jetskier wrote:Rob,

What ever happened with them writing a DLL routine that you could call into IR.exe. Have you asked them lately? I know there were limited resources, but a few months have passed.

More than a few months. I've emailed that contact about this a couple of times since then but haven't heard back yet, so for now I have to assume that we're on our own.

Anyone have a list of HCS08 remotes? I'd like to play with one but I looked here in the UK and the 8820 didn't seem to be available. The 7555 7740 3440 all seem new but I didn't want to buy one just to see if it was JP1.2. None of them are 'slim' like the 8820.
- Andy

AndyJackman wrote:Anyone have a list of HCS08 remotes?

As far as I know, the 7555 has a JP1.2 connector (hence probably HCS08 processor) while the 3440 is a plain JP1 remote (S3C80 processor). I do not know for the 3440.
The 2nd generation european Kameleons (8203, 8204, 8206 and 8210) are also supposed to be HCS08 and at least the 8206 has been reported for having a JP1.2 marked connector. It is not known yet whether the 8203 and 8204 are upgradable, but the 8206 and 8210 certainly are.
The 8820 is an american model, that's why it is hard to find in the UK.
You are probably aware that the JP1 tools do not currently support JP1.2 remotes ?

Thanks aberguerand.

I bought a 7555 and indeed it has JP1.2. I couldn't see any id on the 'chip' but the resonator and pin 5 of JP1.2 are connected to the same relative positions as per Mike E's schematic so I assume that it's the same chip.

BTW, The 7555 takes 4xAAA batteries (6Volts) whereas the schematic shows 2xAAA (3V) in the 8220. However there is 3V between pins 1 & 3 of JP1.2 so obviously this model has some sort of regulator.


Thanks for the heads-up over the JP1 issue, I was just curious about all the JP1.2 issues and wanted to have a look.
- Andy

Just wanted to give you guys a quick update. We have been making some great progress behind the scenes with these JP1.2 remotes, so we should be able to add JP1 support in the not too distant future.

(You will need a new JP1 cable though).

Excellent news Robman!

Best,
jeff

The Robman wrote:Just wanted to give you guys a quick update. We have been making some great progress behind the scenes with these JP1.2 remotes, so we should be able to add JP1 support in the not too distant future.

(You will need a new JP1 cable though).

Has this been a trial and error development or did someone from within the "establishment" provide some valuable information or did the trojan remote make it back? I can't wait to hear the results. The JP1 remotes are becoming more and more difficult to obtain (like my favorite 8810w's at Walmart).

Keep us informed!!!

There was no insider info given on this and we were able to figure things out without needing to use our special "spy remote", though Tommy did put together the hardware so if we ever need it in the future we've already got it.

The main hurdle now is to get our JP1 software modified so that it can talk to these remotes.

The next issue is the fact that this is a new processor. All of our current tools are designed for the Samsung S3C8 processor that's in the current remotes, so all the experts will need to get up to speed with the Motorola HCS08 processor now.

I've got a USB multilink pod and I've used it to look at the MCU Flash. Sure enough it says it is protected. (BTW the 6 pin on the pod is NOT the same as JP1.2 I had to make a 'jumper' cable to arrange the pins right)

I've been performing measurements on the remote prior to erasing it's memory and trying some of my own software and it got me thinking about a DIY remote.

Does anyone else favour the 'ultimate extender' idea originally proposed by Mike (I think)?

To me it makes sense to re-program the whole device with a mini "operating system" that we have control over.

The issues as I see them are:
1) The BKGD interface is too fast for a parallel port type interface. My BDM probe says the URC-7555 is running the BKGD at ~8MHz (which agrees with the datasheet, the only alternative I think is 16Mhz on these chips with a 16MHz xtal)
2) If we re-program the device then we can make Pins 4 & 6 of JP1.2 act as a sort of I2C interface which would allow slower comms using traditional JP1 methods.
3) There is a catch-22 in that if a user hasn't got the HW to re-program via the BKGD then how will he re-program the device so he can program it via the I2C? However our own operating system reduces the problem to the point where the user only has to re-program once and maybe that could be done via a 'rented' programmer or 'programming service'.
4) With our own OS we could abstract the hardware slightly to make future controllers more easy to reverse engineer (because we would only have to figure out the schematic and then how to erase and re-program them).
5) Obvously we lose any 'features' that are built in that we don't then add ourselves. I don't know if anyone would see this as a loss.

If anyone likes this idea then it would be good to list the things we think a remote should do.

- Andy