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).
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).mr_d_p_gumby wrote: 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"!Code: Select all
V+ 1 2 RESET GND 3 4 DATA-IN BKGD 5 6 DATA-OUT
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).
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: 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.
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).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.
I'll give the datasheet a thorough reading as time permits and see if I can come up with anything.
-- Joe
You are probably aware that the JP1 tools do not currently support JP1.2 remotes ?