JP1 Remotes

prelude wrote:Someone mentioned that data section is not protected. so we can still use this to extract data from it..... isn't the case?

I don't think so. If I'm reading the data sheet correctly, only code executing in protected areas can alter any memory or flash location once the security bit is set. Depending on how much of the flash is set to be protected, you might be able to read out the data area, but you could not reprogram it. UEI obviously has some code in the flash that interacts with their JP1.2 hardware, so the next step is to figure that part out.

I have an Atlas DVR/PVR 5-device with the "day" rocker button on the left hand side of the round portion, see the top left unit here.

The 6 pin connector is labelled "JP1.2" so from all that I have read I can do none of the JP1 programming yet. I was in the middle of building my simple JP1 cable when I discovered this so I am disappointed to say the least. I envisioned being able to have the appropriate devices power on and inputs selected when I wanted to watch a DVD and the same scenario for watching a recording from the DVR. It seems that the similar remote with the rocker button labelled "settings" is a JP1 so I might go and swap mine as the day function is not that significant.

What is the latest status on being able to program JP1.2 remotes? I read this thread and it seemed to sputter and die after significant inital enthusiasm.

If and when there's an update to the situation with the JP1.2 remotes, rest assured that we will announce it here in the forums.

Unless somebody makes some kind of breakthrough, we're not going to be able to support these remotes any time soon.

mr_d_p_gumby wrote:

prelude wrote:Someone mentioned that data section is not protected. so we can still use this to extract data from it..... isn't the case?

I don't think so. If I'm reading the data sheet correctly, only code executing in protected areas can alter any memory or flash location once the security bit is set. Depending on how much of the flash is set to be protected, you might be able to read out the data area, but you could not reprogram it. UEI obviously has some code in the flash that interacts with their JP1.2 hardware, so the next step is to figure that part out.

Mike,
So have you read the NVOPT location and confirmed what the KEYEN bit reads?

Do you know how to erase and reprogram the NVOPT location in the FLASH memory?

Go easy on me here, as I am just looking at the data sheet and trying to understand this the best I can for someone who isn't a programmer

Jim

From reading the forums it seems that JP1.2 has not yet been reverse engineered. I have two controllers that seem to use this protocol (URC-8820B00) and naturally I would like to be able to do the same kind of things that the JP1 folks can do.

This isn't just a whine, I'm a qualified electronics engineer, and a skilled software developer. Although I have no prior experience of JP1 I would like to do what I can to try to help decode this more recent protocol.

How do I get involved? I don't want to reinvent the wheel, if progress has already been made.

I wish I knew how to direct you with this, but for now these remotes are an un-crackable nut.

Since you brought the subject up, I'm posting this to bring everyone up to date on where we stand with the JP1.2 remotes. I've been taking a look at them for a while now, but work and family obligations have conspired to prevent me from having the kind of time needed to make as much progress as I'd like. If you (or anyone else) would care to jump in and do some work on this, I'd be happy to answer any questions if I can.

This may get a little technical in places, but I'm assuming my audience is somewhat technically oriented.

I've mostly been investigating the URC-8820 as it seems to be a good representative of this type of remote. I ripped one apart and created this schematic. The CPU used is a Freescale (ex-Motorola) MC9S08RC60FG (data sheet available here), which contains 60K bytes of flash memory and IR generation hardware. I've also looked at an RS 15-2144 (a half-Kameleon type) and found that it uses the same CPU, and I verified that the JP1 connector is wired the same as the URC-8820 (even though it is marked "JP1.1"). In fact, it uses two of the same CPU chips. One is used only to control the Kameleon display.

A normal JP1 remote contains an I2C serial EEPROM chip that is used to hold the settings and upgrades. It is this EEPROM chip that the JP1 interface communicates with via the JP1 connector. The JP1.2 remotes differ in that the settings and upgrades are stored in the processor's internal flash memory, and there is no external serial EEPROM chip. We know that UEI is able to upgrade the JP1.2 remotes utilizing only the connections available on the JP1.2 connector, but we do not know what sort of protocol is involved.

A standard JP1 connector is wired like this: When communicating via the JP1 connector, the RESET line is held low to disable the CPU, and then the SDA & SCL lines are used to talk directly to the serial EEPROM chip using normal I2C techniques. A typical remote would have a 2K-byte EEPROM, such as the 24C16. A glance at a data sheet for these chips will tell you all you need to know about the I2C aspect. Various brands of chips are used, but Atmel or Microchip would be representative.

The JP1.2 connector is wired like this: 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"!

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.

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.

Unlike a current JP1 remote, we won't be able to communicate with it while RESET is held active, since the processor needs to be executing the code used for communication. Given this, and the results of my experimentation, I've come to the conclusion that the remote needs to be placed in some sort of special communcations mode before we can talk to it. I think I may have found this mode.

Start out by asserting the RESET line. This forces most of the processor port pins to an input state. Next, pull the DATA-IN (pin 4) line low. Now release the RESET line. Approximately 45 mS after RESET is released, you can observe that the DATA-OUT (pin 6) line is driven high by the processor. The remote does not give it's normal two-blink A-OK indication on the LED, and does not respond to pressing any buttons. It will remain in this state until a normal RESET is done. The CPU does not enter sleep mode. DATA-IN remains set as an input, and DATA-OUT stays set as an output.

So there you have it; you now know pretty much everything we currently know about the JP1.2 remote hardware. The next step is obviously to figure out what sort of serial communications protocol is used. I've tried a few ideas out, but so far without success. If anyone has any ideas, please feel free to investigate them, or at least mention them here so others can investigate them. This might be a significant challenge becuase you are up against people who are experts in serial communications--remember that UEI has their entire knowledge base of IR protocols to draw from for ideas. If I had to venture a guess/wish, I'd hope they use some sort of self-clocking protocol so that PC latency would not have an impact on the timing.

If you want to play around with this, you'll need to make up a modified JP1 cable. I've been using a modified ultra interface (using a 74HC125) connected to a parallel port. I have not tried a simple interface. The CPU is not rated for 5V, so I'd suggest you use 1K current limiting resistors to cross voltage barriers. First, you'll need to move the RESET from pin 5 over to pin 2, and pick up V+ from pin 1 instead of pin 2. Then, disconnect the existing SCL signal from pin 6. You can leave pin 4 as it is. Finally, you need some way for the PC to read pin 6. I moved the read-back buffer from pin 4 over to pin 6.

I do plan on continuing my investigatation as time permits, and I'll certainly post any new findings, but it would be great if others could join in this effort.

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

I'm curious: has anyone ever contacted UEI (or would it be CT Global, Inc?) regarding technical matters? I have to figure that the JP1 community here has had a positive effect, however minor that might be, on their sales. While I would understand that they might be reluctant to share some types of information for purposes of guarding intellectual property and might worry somewhat about support issues with people hacking into their product, it seems to me that a lot of technical issues regarding the programming protocols, the software environment, etc. they could discuss readily enough without much risk and, if they thought about it reasonably they'd realize that this community is largely relieving them of a lot of support issues -- none of us are contacting them about missing codes or devices. Pretty much, we just make them money.

- Les

I am in contact with both CT Global (the US branch of Computime) and UEI. This isn't something that CTG would know anything about, this is strictly a UEI question.

And yes, I have asked them about this. I have suggested that they write us some DLL type routines that we could call from IE.exe to read and write to just the upgrade area of the flash, leaving the rest of the flash off limits. They had some meetings about this and have agreed in principle, but don't have the available resources to write the routines yet (and who knows when they will).

The Robman wrote: And yes, I have asked them about this. I have suggested that they write us some DLL type routines that we could call from IE.exe to read and write to just the upgrade area of the flash, leaving the rest of the flash off limits. They had some meetings about this and have agreed in principle, but don't have the available resources to write the routines yet (and who knows when they will).

I assume that the reason this is better than simply releasing details of the protocol is so that they can control what we can and cannot get at, and this seems quite reasonable. Unfortunately, I doubt they will ever get around to providing the code, since we are probably pretty low on the priority list.

As a compromise, do you think they may be persuaded release details of the protocol, but under NDA, to just one or two developers, so that they could produce a closed source version of such a driver, the source could be vetted independently to verify that it protects what needs to be protected, and the larger community could just have the binaries... this would seem to mitigate the risks associated with full disclosure.

The short answer is "no, probably not", but even if they were willing, I can't imagine that any of the key players in the JP1 world would be willing to sign such an NDA anyway.

The Robman wrote:The short answer is "no, probably not", but even if they were willing, I can't imagine that any of the key players in the JP1 world would be willing to sign such an NDA anyway.

Yes, good point, I can see that. I guess I'm grasping at straws. However, if they *did* agree to such a thing, then as a non-key player in the JP1 community, I would be prepared to consider both signing the NDA (it would have to be pretty specific), and creating such a DLL. I do have experience of writing protocol handlers for both sync and async and if I thought the long term result would be the possibility to reprogram my device the way one can with JP1, then I suspect it would be worth my while, not to mention the potential for fame and glory! Otherwise, I guess we sit back and hope, since the chances of hitting on the protocol by reverse engineering seem exceedingly slim, given the prior explanations.

Oh well.

I'll pass this onto them to see what they say.

check out the TBDML from www.freegeeks.net I think we can use it to dwonload code and upload code to remote.

prelude wrote:check out the TBDML from www.freegeeks.net I think we can use it to dwonload code and upload code to remote.

Thanks, but as I mentioned above, this would be great if the BKGD debugger interface was going to be of any benefit in this effort. Unfortunately, it probably won't help. Now, if you are going to erase the entire flash and load entirely new code that you've written...