JP1 Remotes

From what I am reading about the chip in the new remotes, it appears as though making it enter active background mode is actually fairly easy.

The "pod" that Moto is referring to is one like the multilink sold for ~$199.00! But it sure seems to me as though that is really nothing more than an interface that provides a known clock and possibly a small set of commands to force a hardware method reset. For example, it may send what I take to be the hardware version of the BACKGROUND command. This is actually
1. Hold BKGD and RESET(NOT) low
2. Release RESET (LOW)
3. Release BKGD

This puts the chip in active background mode.

According to the data sheet, a way to set an interrupt is to do it through ACMP. By writing a 1 to ACIE or a 0 to ACF, an interrupt is generated.

I don't know C, but that is what the Metroworks CodeWarrior seems to be using.

We should be able to generate the active background command through the USB, Serial, or Parallel port.

The SYNC command is supposed to sync the clocks between the CPU and the MCU.

So basically, we should be able to use the CPU clock/timing to replace the clock in the multilink and some C code to communicate through the BDM tool connector and enter active background mode.

Tell me what I missed and where I'm wrong, because I am new to the whole programming thing. I can do hardware, just the software is really beyond me.

There's no "background mode" on the HCS08s. They have a built-in hardware debugger that is accessed through a 1-wire interface. The debugger runs in parallel with the main CPU. If the bit rate is known, communication can be done by generating two different width pulses; timing between pulses is not real critical. I don't imagine that the hardware interface for these remotes will be the difficult part. The hard part is that one of the JP1 experts needs to decipher the storage architecture for keymoves, upgrades, etc. That probably won't happen until one of those experts has one of these remotes to work with.

Deciphering the data won't be a problem, I've got enough experience from having decoded the S3C8, 740 and 6805 formats that I imagine that it will be easy enough to do.

The current problem is still figuring out how to download the data in the first place (ie, the right software and the right interface).

The Robman wrote:The current problem is still figuring out how to download the data in the first place (ie, the right software and the right interface).

I guess for $45.00 you could buy the product I linked to before, the development kit, but it seems rather excessive and certainly like overkill.

I'm sure that someone will correct me on this, but I think the language (software) will be C. I don't know if an expensive compiler will be necessary, if someone knew C. I don't know the first thing about that language, so not me.

The interface should be easy, as I *think* most of the timing and setting will be done in the software, as Mike mentioned.

mr_d_p_gumby wrote:There's no "background mode" on the HCS08s. They have a built-in hardware debugger that is accessed through a 1-wire interface.

Mike, the in the datasheet, section 14.3 talks about an active background mode and how it can be accessed. What are they referring to? They also mention that the built-in hardware debugger (BDC) has two groups of commands: the active background mode commands and the non-intrusive commands. These non-intrusive commands seem to be what you are referring to by running in parallel with the processor?

Jim

I'm starting to scale back the amount of time I spend on remote stuff, so I'm not going to be the one to buy the device and try to figure out how to work it. But, if someone else gets it and manages to do a download, I'd certainly be willing to help figure out the data format.

I have access to a lot of various components and could build an interface in a day, if I had an idea of what to run the BKGD signal to. If someone wanted to experiment with the software and tell me what port we would be using (USB, Parallel, or Serial) and what pins on those jacks to connect to, I could pick up one of those 2144 remotes and try a download. They just came in today at my local store.

I got a look at the manual tonight. It doesn't mention anything at all about upgrading. There are 6 pads in the battery compartment, though.

jherrick wrote:I'm sure that someone will correct me on this, but I think the language (software) will be C. I don't know if an expensive compiler will be necessary, if someone knew C. I don't know the first thing about that language, so not me.

I strongly doubt that it's written in C. UEI would want to devote as much memory to the IR database as possible (without C consuming large chunks of it), and they already have their code written for other processors in machine language. In any case, the part that we're interested in won't be done in any language, as it's just data storage.

jherrick wrote:

mr_d_p_gumby wrote:There's no "background mode" on the HCS08s. They have a built-in hardware debugger that is accessed through a 1-wire interface.

Mike, the in the datasheet, section 14.3 talks about an active background mode and how it can be accessed. What are they referring to? They also mention that the built-in hardware debugger (BDC) has two groups of commands: the active background mode commands and the non-intrusive commands. These non-intrusive commands seem to be what you are referring to by running in parallel with the processor?

I might be wrong, but it appears that you could read & write to the flash memory while the CPU is running (!), so the background mode really wouldn't be needed for JP1 purposes. We'd probably hold the reset line active like we do for the current JP1 remotes, though.

jherrick wrote:I got a look at the manual tonight. It doesn't mention anything at all about upgrading. There are 6 pads in the battery compartment, though.

Sounds like a typical UEI manual.

The Robman wrote:The current problem is still figuring out how to download the data in the first place (ie, the right software and the right interface).

My current problem is not having a remote to download the data from.

mr_d_p_gumby wrote:My current problem is not having a remote to download the data from.

Don't worry, all the new OFA and UEI-RS remotes will have the new chip, so soonenough you'll have plenty to chose from.

One of my UEI contacts was kind enough to download the flash memory from one of the new HCS08 remotes, you can
download it from here.

There's nothing exciting in this file though. The address starts at $EC00 rather than the customary $0000. It appears that the signature if the first 8 bytes, then there's two bytes that might be the checksum, then there are six device button codes. It looks like the VPT bytes might be at $EC18 and $EC19. There is something at $EE00 that I don't recognize. The upgrade section starts at $F000 and is fairly conventional looking.

The raw data changes from $00 to $FF at $F3FF which might imply that this is the beginning of the learning section (if this remote has learning).

In order to provide some ability to program the new remotes, wouldn't it be possible to use the wav import / export function? If a RDF can be created from the flash memory, we should be able to create our own device and protocol files.

We haven't seen a protocol upgrade for one of these remotes yet. I'm assuming that the basic code will be in the 6805 format that we're familiar with, but there's alot of other variables that will be platform specific.

I found this on the Internet over the weekend.

http://www.freegeeks.net/modules.php?na ... cle&sid=52

The schematic makes my head spin and I have no idea how to get a PCB made so I'm not going to try to build it. Perhaps someone with a better hardware background could figure out a way to simplify the interface.

wetalien wrote:I found this on the Internet over the weekend.
http://www.freegeeks.net/modules.php?na ... cle&sid=52
The schematic makes my head spin and I have no idea how to get a PCB made so I'm not going to try to build it. Perhaps someone with a better hardware background could figure out a way to simplify the interface.

Before anyone jumps on this bandwagon, I should mention that it looks like this device (or any other BDM interface) will be of very little use in communicating with the remote for JP1 purposes. (Read an HCS08 data sheet and you'll see that, once security protection is activated, about all you can do via the BDM is erase the entire flash memory.)

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

mr_d_p_gumby wrote:

wetalien wrote:I found this on the Internet over the weekend.
http://www.freegeeks.net/modules.php?na ... cle&sid=52
The schematic makes my head spin and I have no idea how to get a PCB made so I'm not going to try to build it. Perhaps someone with a better hardware background could figure out a way to simplify the interface.

Before anyone jumps on this bandwagon, I should mention that it looks like this device (or any other BDM interface) will be of very little use in communicating with the remote for JP1 purposes. (Read an HCS08 data sheet and you'll see that, once security protection is activated, about all you can do via the BDM is erase the entire flash memory.)