SH Boot mode questions

subarutech77 · **Joined:** Fri Jul 17, 2009 2:47 am **Posts:** 77

Hello, I need help with my Sh boot mode set-up. Long story short, I updated to ecuflash 1.43.3150, it updated the OP2 to a new firmware. EcuFlash was being real buggy on the machine it was on, so I went back to 1.42. Wrong idea. The new driver for the OP2 is not backward compatible and when you try to flash with the latest firmware on the OP2 with an earlier ecuflash, it will brick your ecu. I now have 2 ecms that have been bricked this way. In the ecuflash log it showed no errors and was able to read the rom on the 2nd ecm before I tried to flash it. I have since reupdated to 1.43.3150 in the hopes not to have it brick the ecm again.

I have a shboot mode set-up wired up with the schematic shown over at the tactrix website. One of my problems is I seem to be getting a lot of electical noise through the ground circuit when the ecu is powered up, I don't have a oscilloscope, but have a usb one on the way for my computer, hopefully it will meet my needs. I've tested the timer circuit with a buzzer from radioshack and the pitch changes when the ground circuit is added to the breadboard that the timer is on. Also with the timer circuit not powered up, but with the ground wire connected I see about .5V on the timer output wire, when I supply 5V to the timer circuit, I see 2.5V at the output pin.

Here is a log of an alternate flash attempt:

Code:

[22:16:12.954] Using interface USB <-> Serial
[22:16:14.839] sending bit rate sync bytes...
[22:16:14.839] received bit rate adjust response
sending boot command
[22:16:15.370] received bit rate adjust response
sending boot command
[22:16:15.900] received bit rate adjust response
sending boot command
[22:16:16.431] received bit rate adjust response
sending boot command
[22:16:16.961] received bit rate adjust response
sending boot command
[22:16:17.491] received bit rate adjust response
sending boot command
[22:16:18.022] received bit rate adjust response
sending boot command
[22:16:18.537] received bit rate adjust response
sending boot command
[22:16:19.051] received bit rate adjust response
sending boot command
[22:16:19.566] received bit rate adjust response
sending boot command
[22:16:20.081] received bit rate adjust response
sending boot command
[22:16:20.596] received bit rate adjust response
sending boot command
[22:16:21.111] received bit rate adjust response
sending boot command
[22:16:21.625] received bit rate adjust response
sending boot command
[22:16:22.140] received bit rate adjust response
sending boot command
[22:16:22.655] received bit rate adjust response
sending boot command
[22:16:23.170] received bit rate adjust response
sending boot command
[22:16:23.685] received bit rate adjust response
sending boot command
[22:16:24.199] no bit rate adjust response
[22:16:24.199] interface close

I get the same message if the timer circuit is connected or not. My next thought is to power the 7058 similar to hmanxx here:

http://forums.openecu.org/viewtopic.php?f=2&t=4310&p=22301#p22301

Some questions I have are:

1. Are the Vcc, PVcc1, and PVcc2 all connected to each other? In the thread above he supplied PVcc1 and PVcc2 with 5v and Vcc with 3.3. Will connecting 5V to one PVcc1 and one PVcc2 pin to supply the voltage work, or will 5V need to be supplied to all the PVcc1 and PVcc2 pins on the chip. Same question applies to the Vcc pin(s).

2. Is there a better way to supply ground so that there is less or no noise coming through the ground circuit? In the schematic on the tactrix website, the grounds look like signal grounds according to the symbols. Should the power supply ground circuit of the ECM and the serial to usb, and the timer circuit share the same ground? Or should they be separate?

Thanks

Sasha_A80 · **Posted:** Sat Apr 16, 2011 3:40 pm

Are you trying to use Power\Gnd from the computer you are using for flashing?
12V battery or non-switching power supply should not give you any ground noise\ground loop voltage drop.

SH7055\7058 based ecu needs Ground, +12V power( probably connected by X-relay or directly to the battery on your car ) AND Igninition pin connected to +12V for operation.

I would not recommend to supply power directly to 5.0V and 3.3V lines.

subarutech77 · **Joined:** Fri Jul 17, 2009 2:47 am **Posts:** 77

No, I used a AC car charger at first to supply 12V to the ECM. Then used a battery out of the car and saw less noise, but noise none the less. Also tried to connect battery to large piece of exhaust pipe and connect the grounds on other end to see if the pipe would absorb the noise. Have ECM pins for control unit supply, backup power supply and ignition switch (connector B135 pins 5,6,19 and connector B137 pin 15- ignition switch) all powered with 12VDC and the ground connected to GND(power supply) connector B135 pins 1, and 4. To supply the ground for the ECM. Perhaps all of the ground pins of the ECM should be connected to Ground?

Also the vag-com cable that I am using to provide the TX/RX is powered by the battery out of the vehicle, while the timer circuit is being provided 5VDC by a BasicStamp2 board kit. I have all the grounds of all the components connected together, even P413 on the pads of the ECM for shboot mode is connected to the same ground circuit.

I am skeptical about providing 5V directly to 7058 as well, thanks.

Sasha_A80 · **Posted:** Sat Apr 16, 2011 4:47 pm

ECU power consumption should be about 10 ma with Ignition OFF and about 400 ma with Ignition ON.
If everithing is correct with Power\Ground\Ignition you will get SSM2 connection with RR, ecuExlorer and k-line adapter like VagCom.

After that I suppose you are to use Renesas Flash Development Toolkit and your stripped VagCom FTDI chip based adapter for SHbootmode reflash.

FDT is freely available from Renesas site.

subarutech77 · **Joined:** Fri Jul 17, 2009 2:47 am **Posts:** 77

I was able to connect to ECM before I flashed it, even the test write showed no errors as well, when it's bricked it will not communicate with RR, ecuflash or subaru scan tool. I will check the power consumption and look into the fdt tool kit.

Thanks

Sasha_A80 · **Posted:** Sat Apr 16, 2011 8:27 pm

That is my opinion why ecu becomes bricked:

http://forums.openecu.org/viewtopic.php ... 897#p24897

subarutech77 · **Joined:** Fri Jul 17, 2009 2:47 am **Posts:** 77

I think I understand what you are saying there, however it is possible to render an ecm useless with a oem scan tool. I've done it once. If power or communication gets interrupted, or the battery voltage of the car or computer drops too low or spikes, could mean bad news. The oem scan tool will not let you flash an incorrect map (MT map to an AT car) to the target ECU, that's one nice thing about it.

I tested the timer circuit I have built. It measures 125Hz just by itself. However peak voltage is 4.5V.. Is this too high of voltage for TTL levels?

The next thing I suspect is the vag-com cable. I was under the assumption that the circuitry was all there per the tactrix schematic, and all that was needed were the raw TX/RX lines from the vag-com cable to the ECM connected. Without dismantling the vag-com circuit board. More testing is needed to ensure the circuitry is the same as the schematic. Otherwise I have a dlp-usb232m protochip on it's way. That way start from scratch.

Thanks

Sasha_A80 · **Posted:** Tue Apr 19, 2011 6:00 am

VagCom notes:

You are to disconnect UART Rx pin from cable schematics for the reason there is (MC33290, MC33199, optocoupler or something like this) output connected to FTDI Rx pin that shorts the circuit.

Check the polarity of Tx\Rx pins of FTDI and invert ( http://www.ftdichip.com/Support/Utilities.htm ) if necessary. Correct UART level is high at idle.

Timer tricks:

Timer\PB15 SH7058(7055) pin should be open drain(open collector) driven. ECU circuitry has it's own pullup resistor to +5V.

Ecu's watchdog circuitry provides hardware reset ( driven Renesas Reset pin low for about 10 ms by open drain) if there is no activity for about 20-40 ms at Renesas PB15 pin. When ecu's software is running PB15 is periodically (8 ms) driven low in order to reset ecu's watchdog otherwise the watchdog will reset the SH processor.
...this is the house that Jack built...

When your flashing software is loaded the same PB15 behavior should be provided - by (tricking) external timer or flashing software itself.
Look at SH reset pin ( CN1 pin7 ). If your timer satisfies watchdog there will be high level 4-5V voltage. Otherwise you will see periodical SH reset (40 ms high\ 10 ms low level).

Wishing you the best success...

subarutech77 · **Joined:** Fri Jul 17, 2009 2:47 am **Posts:** 77

SUCCESS!!

here is a sample of a successful shboot, much too long to post whole thing.

Code:

[22:08:57.646] EcuFlash Version 1.43.3150
[22:08:57.646] OS Version Windows 7
[22:08:57.646] Qt Version 4.6.2
[22:08:57.677] 62 memory models read.
[22:08:57.692] scanning for metadata models in C:/Program Files/OpenECU/EcuFlash/rommetadata
[22:08:58.909] 354 ROM metadata models scanned.
[22:08:58.909] checksum module "subarudbw" loaded.
[22:08:58.909] checksum module "mitsucan" loaded.
[22:08:58.909] checksum module "mitsuh8" loaded.
[22:08:58.909] patch module "Subaru CAN Enhanced RAM Parameter Logging" loaded.
[22:08:58.909] patch module "Mitsu CAN RAM Parameter Logging" loaded.
[22:08:58.909] flashing tool "wrx02" loaded.
[22:08:58.909] flashing tool "wrx04" loaded.
[22:08:58.909] flashing tool "sti04" loaded.
[22:08:58.909] flashing tool "sti05" loaded.
[22:08:58.909] flashing tool "mitsukernel" loaded.
[22:08:58.909] flashing tool "mitsukernelocp" loaded.
[22:08:58.909] flashing tool "mitsubootloader" loaded.
[22:08:58.909] flashing tool "shbootmode" loaded.
[22:08:58.940] flashing tool "shaudmode" loaded.
[22:08:58.940] flashing tool "subarucan" loaded.
[22:08:58.940] flashing tool "mitsucan" loaded.
[22:09:11.233] A2WC410D (272 tables) inheriting 32BITBASE (661 tables)
[22:09:11.327] 1048576 byte image read.
[22:17:35.317] Using interface USB <-> Serial
[22:17:37.367] sending bit rate sync bytes...
[22:17:37.476] received bit rate adjust response
sending boot command
[22:17:37.991] got boot response
[22:17:38.131] 1 supported device(s):
[22:17:38.131]    0601 HD64F7058
[22:17:38.131] selecting device 0601
[22:17:38.365] 0 supported clock mode(s):
[22:17:38.365] selecting clock mode 0
[22:17:38.615] 2 supported clock type(s):
[22:17:38.615] 1 ratios for clock type 1
[22:17:38.615] 1 ratios for clock type 2
[22:17:38.724] 2 supported clock frequency range(s):
[22:17:38.724] 1 20000000-40000000
[22:17:38.724] 2 10000000-20000000
[22:17:38.724] setting baud rate to 62500
[22:17:39.114] 1 user boot MAT area(s):
[22:17:39.114] 1 00000000-00001fff
[22:17:39.239] 2 user MAT area(s):
[22:17:39.239] 1 00000000-0007ffff
[22:17:39.239] 2 00080000-000fffff
[22:17:39.363] programming unit is 128
[22:17:39.488] one MAT programming supported at 00000000
[22:17:39.488] entering prog/erase state
[22:17:49.035] writing 128 bytes to 00000000
[22:17:49.176] writing 128 bytes to 00000080
[22:17:49.316] writing 128 bytes to 00000100
[22:17:49.457] writing 128 bytes to 00000180
[22:17:49.613] writing 128 bytes to 00000200
[22:17:49.753] writing 128 bytes to 00000280
[22:17:49.893] writing 128 bytes to 00000300
[22:17:50.034] writing 128 bytes to 00000380
[22:17:50.174] writing 128 bytes to 00000400
[22:17:50.315] writing 128 bytes to 00000480
[22:17:50.455] writing 128 bytes to 00000500
[22:17:50.595] writing 128 bytes to 00000580
[22:17:50.736] writing 128 bytes to 00000600
[22:17:50.876] writing 128 bytes to 00000680
[22:17:51.017] writing 128 bytes to 00000700
[22:17:51.157] writing 128 bytes to 00000780
[22:17:51.297] writing 128 bytes to 00000800
[22:17:51.438] writing 128 bytes to 00000880
[22:17:51.578] writing 128 bytes to 00000900
[22:17:51.719] writing 128 bytes to 00000980
[22:17:51.859] writing 128 bytes to 00000A00
[22:17:51.999] writing 128 bytes to 00000A80
[22:17:52.140] writing 128 bytes to 00000B00
[22:17:52.280] writing 128 bytes to 00000B80
[22:17:52.421] writing 128 bytes to 00000C00
[22:17:52.561] writing 128 bytes to 00000C80
[22:17:52.701] writing 128 bytes to 00000D00
[22:17:52.857] writing 128 bytes to 00000D80
[22:17:52.998] writing 128 bytes to 00000E00
[22:17:53.138] skipping 128 bytes at 00000E80
[22:17:53.138] skipping 128 bytes at 00000F00
[22:17:53.138] writing 128 bytes to 00000F80
[22:17:53.279] writing 128 bytes to 00001000


[22:28:45.703] skipping 128 bytes at 000E8E00

[22:28:45.719] skipping 128 bytes at 000FFA00
[22:28:45.719] writing 128 bytes to 000FFA80
[22:28:45.859] skipping 128 bytes at 000FFB00
[22:28:45.859] writing 128 bytes to 000FFB80
[22:28:46.015] writing 128 bytes to 000FFC00
[22:28:46.155] writing 128 bytes to 000FFC80
[22:28:46.296] writing 128 bytes to 000FFD00
[22:28:46.436] writing 128 bytes to 000FFD80
[22:28:46.577] writing 128 bytes to 000FFE00
[22:28:46.717] writing 128 bytes to 000FFE80
[22:28:46.857] writing 128 bytes to 000FFF00
[22:28:46.998] writing 128 bytes to 000FFF80
[22:28:47.138] ending programming
[22:28:47.263] programming complete
[22:28:47.279] data checksum is FD210726
[22:28:47.653] user MAT checksum is 0A3C2977
[22:28:47.653] interface close

Thank you very much, Sasha. You have been very helpful.

I made sure I was seeing the timer signal at PB15, and isolated the TX/RX pins of the FTDI chip in the vag-com cable, worked first try.

Used boot mode to flash to stock map, just to be sure it worked. Vehicle went into test mode, flashed latest revision, bricked ECU :cry:

It turns out, several of my rom files had been corrupted or became incomplete when I had my laptop repaired (another part of the long story). It was not EcuFlash or the drivers I believe. Have used SH Boot mode 4 times trying to find a good map. Vehicle starts now.

Thanks again

dschultz · **Posted:** Wed Apr 20, 2011 1:57 pm

Glad you finally got it working. I never thought about the additional circuitry in the VAG-COM loading the TX/RX pins of the FTDI chip. That's good to know when I get around to making my setup.

Corrupt ROMs, that's not good.
Maybe an MD5 checksum could be run against the ROMs and recorded. Then if you need to check at a later date you can run it again and validate the files have not changed. Then you can recalculate on any modified ROM you make.

I think I may start to do that and post them with the stock ROMs.
Here's a Windows MD5 calculator I often use.
For example, CAL ID A2WC522S, MD5 sum = 788a8ebcaf239ec24e5c934e34ec24a4

subarutech77 · **Joined:** Fri Jul 17, 2009 2:47 am **Posts:** 77

Thank you too, dschultz. You've always been willing to answer any questions I may have.

I pretty much just pulled the TX/RX pins up at the chip and soldered the wires directly to there. Also I left the12V power and ground circuit of the ECM connected to the B connectors(front end) separate from the timer and P pads 5V power and ground circuit. No electrical noise that way. The vag-com cable I had to power with 12V at the OBD connector and shared the ground with the ECM.

I'll try to post a picture later this evening, it looks like a bunch of spaghetti though. With the protochip I should have tonight, I think I may try to build a dedicated board, be uncluttered that way.

Should I use the ansi, or unicode md5 program?

lol, so much to learn, very little understanding of any of it.

Thanks

dschultz · **Posted:** Wed Apr 20, 2011 8:12 pm

For Windows XP an newer I think it's the unicode one, if not you know the answer to that...

subarutech77 · **Joined:** Fri Jul 17, 2009 2:47 am **Posts:** 77

A bit of a mess yet, I'm working on that still. Here are some pics though.

Double Phister · **Posted:** Fri Apr 22, 2011 8:49 pm

That's cool. Maybe a diagram would be better.

Does the stock ROM a factory loading mechanism use a checksum to keep a corrupted ROM from bricking the ECU?

dschultz · **Posted:** Fri Apr 22, 2011 9:40 pm

The description and diagram can be found on the Tactrix site here.

RomRaider

Forum rules

SH Boot mode questions

Who is online