jtec pcm read/write eeprom #11
Replies: 6 comments 28 replies
|
Hello Ralf, thank you for your feedback! I'm asking for your patience while these things unfold this week. |
|
Hello Daniel, I attached a photo of the old pcm, perhaps it helps. best regards |
|
As far as I know the 68HC11 MCU you desoldered, which contains EEPROM, can only be reached via the main MCU (68HC16). In this diagnostic framework at least. Bootstrap mode currently does not support JTEC EEPROM read/write, so your only course of action is to use the "Tools / Read/Write memory" menu, in normal startup mode. The BAK and RES buttons are there to read/write the whole 512 bytes in one go. Do you have SCI-bus logs before you took out the EEPROM? I must point out, that the EEPROM layout extracted via normal mode and bootstrap mode is slightly different, but content is the same (example: VIN is at a different physical location). For compatibility reasons JTEC EEPROM features are kept in normal mode. We had the same roller-coaster with SBEC3 and EATX3 bootloaders, thought to be the same but turned out to be different. |
|
thank you, I take the log of the sci-bus from donor pcm with "Tools / Read/Write memory" menu at the evening. best regards |
|
Hello Daniel, now I can read mileage/vin/skim/partnr, but i can't write it back. I can "BAK" the eeprom, but i can't write ist back. best regards Here is the code from reading and writing the mileage: This is the message of status-output of "Memory Read/Write": |
|
o.k., but difference is |
|
Sorry but I don't understand. Could you walk me through step-by-step what you are doing with the mileage (with logs) and what you would expect? It depends on how strict the JTEC firmware is regarding SKIM presence. It's best to disconnect SKIM connector after programming FF to EEPROM 0008. |
|
i write a 13.2 to the mileage km box and push the write button, this should be converted to perhaps this cause the problem: here is the code from session above: |
|
Visual Studio says that the (double) cast is redundant there. If you multiply an integer with a double, the result automatically becomes a double type. From the log it's apparent that the GUI makes the mistake when converting textbox content to a number. What happens if you write integer mileage only? No decimal point. Perhaps a localization issue is at work. There are new GUI and scanner firmware updates available! |
|
You are right. |
|
Hi! |
|
Hi, I replied via email with ideas for testing. |
|
Hello Fausto, I can't find your new comment, but here is a complete Arduino Mega sketch, Python script, and YouTube demo showing how to read and write the JTEC EEPROM: https://gist.github.com/laszlodaniel/eabd1ebcc46992b23f5768d8a386e704 There is a serial command (P) that allows you to write an existing EEPROM file, but first you need to convert it into an Arduino array declaration using the provided Python script. If you have a 640-byte EEPROM dump, the script will automatically map it to the 512-byte format for you. |
|
Hello, Lazlo! And thanks for the answer. I deleted the question because I hate make people waste their time explaining me something that I'm able to find by myself! Lol! I have electronics background, a lot of components flying around my store and a laser machine, so I decided to make your board v1.44. The question was to figure if I can write data into the eeprom on a JTEC ECU of my car using this specific version of scanner, since my original ECU bricked, the HC16 is shorted somehow. I bought a used "new" one and I read the eeprom by pulling it out, but my ECU is one of that embedded in PU resin and I bumped in your github looking for a solution.
Thanks a lot, as soon as I finish assembly and test, I post the pics. |
|
Hi Daniel, First, thank you for this project and for the DRB-III database work — both have been enormously useful. I'd now like to make a read-only backup of my PCM before doing anything else, and I have a few questions about the JTEC path.
Thanks either way — the documentation you've already published saved me weeks. |
|
Hi Rubens, You are very welcome! I'm glad the DRB-III database and the scanner project have been useful to you. Happy to help you get a safe, read-only backup of your JTEC unit. To answer your questions directly: 1. JTEC Bootloader: 2. Voltages for reading only: A note on hardware protection: When applying 12V (VBB) to the SCI-RX pin, your interface hardware needs to be protected, as the PCM's internal circuitry is already tolerant to this, but standard 3.3V/5V microcontrollers are not. In the V2 scanner, I use an N-channel MOSFET as a voltage level shifter between the PCM (5V) and the ESP32 (3.3V). Because of the MOSFET's internal body diode, it natively blocks the 12V/20V programming voltages from flowing backwards into the ESP32's RX pin. It's a highly effective trick for single-wire bi-directional protection, even if you have 5V logic on both sides. 3. Seed/Key Algorithm: The Chrysler Bootstrap Protocol: A Step-by-Step GuideTo save you some more time, here is a detailed, step-by-step breakdown of how the JTEC bootstrap state machine operates, complete with timings and byte-streams. When the PCM is operating in Boot Mode, the standard engine controller logic is completely bypassed. If you do this in the vehicle: the fuel pump will not prime, the ASD relay will not click, and the engine will not fire. Phase 1: Hardware Entry & Baud Synchronization
Phase 2: Security Challenge (Seed & Key)Before you can upload custom code to the RAM, you must pass the security challenge to unlock the memory space. All requests in this phase are verified with a standard 8-bit additive checksum. Request Seed:
Calculate Key: Send Key:
At this exact moment, the PCM's internal RAM is unlocked, and the factory boot ROM is waiting for you to download a custom bootloader. Once you have successfully passed the Seed/Key security challenge (Phase 2), the PCM's memory space is unlocked. You are now communicating directly with the factory ROM's bootstrap listener, which is waiting for you to inject your own code into the microcontroller's RAM. Phase 3: Uploading the Main BootloaderThe current architecture uses a Resident Bootloader (which stays in RAM permanently) and hot-swappable Workers (small applets that do one specific job, like reading Flash, reading EEPROM, or erasing). First, we must upload the Resident Bootloader ( 1. Send Upload Command & Payload:
2. Execute the Bootloader:
Phase 4: Uploading the Flash Read WorkerWith the Resident Bootloader running, you can now upload the specific Worker applet you want to use. Since you want a read-only backup, you will upload the worker compiled and included in The Bootloader uses a simpler protocol than the factory ROM. It locks the worker destination address to
Phase 5: Executing the Worker & Reading FlashYou now have a Flash Read worker sitting in RAM at 1. Start the Worker:
2. The Memory Pointer Logic: Read Request (Example: Bank 0, Offset 0x0000, 512 Bytes):
PCM Response:
3. Loop Until Complete:
4. Exit the Worker:
Let me know if this helps clear up the workflow! The V2 scanner automates this entire dance behind the scenes, but building it yourself is a fantastic way to understand the vintage architecture. |
|
Daniel, This is far more than I asked for — thank you. The complete JTEC and JTEC+ worker sources, the pre-compiled headers, and the toolchain answer everything I was stuck on. Two things stood out immediately. The header comment in jtec_bootloader.asm resolved my voltage question: 12 V applied to SCI-RX with the key off, then removed after key-on. That's a momentary pulse rather than a sustained rail, which makes the hardware far simpler than I had assumed from the V2 API description of VBB/VPP. And the EEPROM gist works in normal mode with no bootstrap at all — I verified your (seed << 2) + 0x9018 key derivation against the log in discussion #11 (seed 768A → 2C 6A 40 D6, checksum D6) and it matches byte for byte. My PCM is a 56041636AE, the ECE calibration for the 2000 XJ 4.0 — Brazil kept the distributor until mid-2000, so it behaves like the earlier US units. Two questions, if you have a moment:
Thanks again. |
|
Rubens, You are definitely on the right track, but Chrysler's internal architecture branches off between JTEC and JTEC+. Here is the breakdown of your questions and a few crucial warnings regarding your specific PCM: 1. JTEC vs. JTEC+
While both generations will likely accept the either bootloader upload, their internal hardware topologies are different. Specifically, the internal 68HC11K4 co-processor (which handles the CCD/PCI bus and houses the EEPROM) communicates differently, and the Flash erase/write algorithms vary. 2. VBB Timing (12V on SCI-RX)
The length of the "pulse" is entirely dependent on how long it takes between applying the voltage and turning the key. The most important rule: You cannot send any data to the PCM until that 12V high voltage is physically cleared from the line. 3. However, you should not use the
4. The Seed/Key Algorithm (Normal Mode vs. Bootstrap Mode)
Regarding the comment that the bootstrap "may be protected": That was a legacy note referring to very early 1995 SBEC3 units. Some of those earliest PCMs shipped with an unprotected Boot ROM (if you asked for a seed, it just echoed your command back with the bits flipped to say "Command Not Supported," and let you upload a bootloader anyway). To summarize your backup path:
Let me know how the hardware interface build goes in a different discussion! |
|
Daniel, This is exactly what I needed — thank you. Three things I had wrong are now fixed: no VPP for reads, VBB held until the BREAK rather than a timed pulse, and above all not using memory_ripper for a backup. I had it earmarked as the read path; good thing I asked. I need to correct something I told you, and it may change your advice. I originally said my PCM was 56041636AE. That was from the model year, before I had read the EEPROM. I have since dumped all 512 bytes in normal mode using your gist protocol, and the part number stored at 0x01E2..0x01EA reads: 01E2: 56 04 15 35 FF FF FF 41 45 -> 56041535AE Three things line up with that being a 1998-spec unit in a 2000 chassis: 56041535 is catalogued in WINFLASH.MDB as AUTOMATIC 4 SPEED ECE (1998 XJ 4.0L), while 56041636 is AUTOMATIC ECE (2000 XJ 4.0L). By your 1996-1998 / 1999+ split, that would make this a JTEC, not a JTEC+ — so jtec_read_st.h rather than jtecplus_read_st.h. Does the part number override the model year here, or is there a more reliable way to tell the two apart before uploading anything? Given your warning that the 68HC11K4 topology and flash algorithms differ, I would rather confirm than guess. One smaller question: you mentioned the "128k+128k" configuration early in this thread. My flash is a 256 kB TMS28F210 and your dump sequence mentions banks 0 through 3. Is the 128k+128k bootloader the right one for this part, or is that a separate variant again? Thanks again — the EEPROM backup is done and verified (odometer read back within 0.03% of the cluster), |
|
Rubens, The part number found in EEPROM is a backup made by a dealer programmer tool before reprogramming the flash chip. This means it was the previous calibration on the chip. I find it strange that you have both types of part numbers for this unit. Perhaps it was a programming mistake due to the unitary difference between them; I can't tell for sure. Given that you have a single 256K chip on a 2000 car, which is characteristic of a JTEC+ unit, I would continue on the JTEC+ path. Both types of workers handle the chips as contiguous 256K, so either way you will be able to back up the flash chip. The EEPROM offset 0x0008 stores the learned status of the SKIM. FF means it is still in learning mode or is not utilized. Matching odometer values this closely between the PCM and BCM is always a good sign that the EEPROM is being updated properly and that there is no communication issue. |
Uh oh!
There was an error while loading. Please reload this page.
dear mr laszlo,
first, thank you for your lots of work on this tool.
i bougth it to bring an old cherokee xj back on the road. the original jtec-pcm (P56041) was damaged, but i could rescue the data of the 68hc11ka04-eeprom. now i have a donor pcm.
i can connect via sci-bus an read diagnostig data of pcm, but the "read/write_memory"-form doesn't work (no read_write of VIN/mileage/skim is possible).
in further i had also no success with the bootstrap tools. it is possible to load the jtec_bootloader, but e.g. the worker for reading the partnumer or the flash_id comes with no success. loading eatx3_128 bootloader plus the worker for read flash_id i can read the correct flash_id, but the ohter worker don't perform.
please may you help on reading/writing the 68hc11ka04-eeprom of a jtec pcm?
thank you foreward and best regards.
ralf pandel
All reactions