061201

Looks like it's working now. A little sleep and some thought and it all makes sense. I was forgetting to give prog.pl a w command so it was just verifying (is that a sensible default action?), which would fail if I hadn't actually programmed a firmware. Manually programming the firmware via the ISPI didn't set the magic bits to tell the bootloader to try to run it. Either way, now it seems to boot and run and if I type Man I get Hello>.

I wish there was an RPM for megatunix... Doesn't matter, it doesn't seem to support genboard. Is the best on Linux going to be [dumb terminal]? Got the dock for my laptop which has a hardware serial port (usb-serial adapter I've been using loses recieved bytes for some reason). Got megatune up and running, time to work on more soldering, will start with sensors so correct functionality can be verified.

----

061130

Got tired of wondering, so I built a dapa cable like [this] but just wires, no resistors. For the config I used the dapa section from the config available [here]. It's the same config as the one built into the config that comes with the avrdude rpm available [here], but without the vcc. Ran into problems because I hooked up to MOSI and MISO, but I was fixed up by [this guy's notes]. Anyway, the AVR chip is live at least, and it's communicating serially and worst case I have a torched max like [him], so I can follow those tests.

Tried to replace the bootloader like [here] and now it looks like I can get into the boot loader with proper responses to S, v, etc. I also am seeing gibberish if I hook up a serial cable with a terminal while uploading, (usb-serial adapter still doesn't work in the same way, but it does show gibberish when uploading an image). I tried uploading newer firmware (1.0.53), no go. now I just get a loop of gibberish. I reflashed to that older version and as I seem to get some sort of serial communication now though, so I tried uploading via RS232, but I get:

<code>

ihex file read and found OK

we say p

AVR in sync

we say S

we say v

we say V

VERIFYING...

error at page 0

255,128,0,0

157,7,192,253error at page 256

0,0,0,128

0,63,52,141error at page 512

0,128,1,0

128,196,135,14error at page 768

1,0,1,128

129,68,135,142error at page 1024

1,128,2,0

5,220,171,88error at page 1280

2,0,2,128

21,137,62,165too many errors, bailing out

Verified(0 1280)

TOTAL serious errors at verify: 6

FAILURE

</code>

Turns out that "gibberish" I saw was the bootloader operating the serial port at 19.2 instead of 9600. Loading the firmware via ISPI results in a non-responsive serial port (assumably overwrote or erased the bootblock), and it cannot be coaxed into bootloader mode by jumpering the two serial port pins. Doesn't work with a later version either.

* I combined the main.hex and vems.hex into one .hex file and flashed it.

** this was a smart thought, but :02F7FE005AA50A line (which is actually 2 bytes: 5A,A5 at position 0x1F7FE, called flagword; ment to prevent booting a half-uploaded firmware that could cause damage easily) must go between, otherwise:

The bootloader wouldn't load the vems code, so I hooked up the serial cable now and tried prog.pl again...and it verified successfully!

To fix the flagword, it's simplest to write again with prog.pl (w option).

----

061128

Hooked up a fuse holder with a 500mA fuse for F1, the "wire" next to it, inductor, and power ground wires to EC36 (hooked into a PC power supply for now). Oops! mixed up the ends of the fuse and the "wire" so the portion of the circuit with the inductor had no power while the circuit on the far side of the "wire" had 12V. Seemed nothing had power going through the startup voltage checks. Hopefully this didn't mess up my board; I'm now seeing power everywhere, but nothing at the serial port, at least according MegaTune or by just typing gibberish at the terminal. Just in case it's my cheap USB-Serial adapter, I tried my desktop (prog.pl on Linux) and it doesn't seem to see anything either. Quadruple checked the serial pinout, it matches [the pinout here] directly wired to SV2. What else to check or try?

*Have you also double checked your serial port speed and settings? 9600-8-N-1 should do the trick. BTW, Minicom works well under Linux, but typing gibberish is a bad idea - start with an 'A' and see if replies with (binary, indecipherable) data.

**I had the right rate in minicom, actually that caused me trouble later as when it wouldn't get passed the bootloader it'd use 19.2kbps. What would gibberish do that'd be bad?

----

061126

More of life conspiring to put this way in the back burner. Got a week off coming up, so working on re-figuring out how to set this up. Main questions are:

* Need to dig into the schematic some more. Which of the manual pages above is correct?

** did you find contradiction ?

*** Maybe it'd help if I put in my issue. I can't remember now, but my best guess is I got confused by the former using the coil_8, etc terminololgy instead of drive_8. I thought it was an actual coil (ie for ignition).

Also, in my OE setup, the Inj+ common isn't available to the PCM.

You must connect EC36pin23 in any case! (FlyBack is a must!) Choose a +12V than, that powers the injectors (likely through a fuse or a fuse and relay). At least the injectors shouldn't get +12V power when this line is 0V

*I read some strong sounding warnings about not having a fuse in this path. I have 2 available power signals. One has power when the engine is on or starting (this will be hooked to EC36-25) and the other is a connection to the battery directly (via a 5A fuse). Would it be appropriate to hook the latter up to EC36-23?

Will you want injector-PWM-ing ? Many finds 6.8Ohm power resistors a good idea for low-Z injectors, or choosing high-Z whenever possible (easier config, less sensitive to injector-opening characteristics variations in the set of injectors).

*The injectors I have are low-Z because that's what the stock setup uses. To start, I figure it'll be easier to change as little as possible between the two. I could switch to high-z later, but that'll be relvant later and most of the hard stuff will be done already.

*I have no particular attraction to PWM though, other than it seems like the better solution. I imagine I'd need approximately 2A through those resistors so they'd have to handle 28W at least? What's a good source for these? I'd rather not drop $25 on resistors and would much rather run an extra wire.

Connect GND and all 4 GND5 at EC36, with max 20cm, strong wires. There must be a solid path to battery- , of course. Examine and measure the OEM harness carefully before deciding about not using a separate wire of your own.

*The OE harness has two non-sensor grounds (in addition to the half dozen sensor grounds). One grounds to the engine right where the battery hooks up, the other grounds to the far side of the engine. I was planning on hooking all the sensor grounds to EC36-26 and splitting the rest up on the two digital grounds in the harness. As far as GND5, I only see 3: EC36-5,21,32. I see some mentions of EC36-22, but this isn't hooked up to anything, so I'd rather use it for an additional output.

----

060412

Finally recovered from the quarter from hell. Goal is to get this thing up and running by the end of May in a more stable form so I can sell my other car.

Turbo has been in for almost a year now. Running only 4psi at the turbo, 2.5psi at the manifold. Fuel control is the stock setup with 25% larger injectors and a 2 bar MAP sensor supplied by 8.5V instead of 5V to bring open loop to stoch (passes emissions with better than it used to). Unfortunately the dumb knock sensing method used by the computer is triggered by loose bearings and piston slap so it's been disabled (replaced with a resistor of appropriate value). The trash engine in there that I wanted to use to get operational has maybe 5K, 10K miles at most left on it before it needs a complete rebuild. Replacement engine is already standing by...gotta get going!

So I can see how the Stilo code should work, although I'm somewhat disenheartened by the apparent failure of using the stock CAS. It should at least get it working better than using the builtin DIS timing.

Ordering parts this week...

-------------------------------------

051207

The DIS module's output gives no indication of which cyllinders are at TDC. Basically this limits me to 1 bank batch until I ditch the DIS and deal with the VR sensor directly or add in the cam sync generator (heard on IRC that the current code doesn't apprecate sync signals in the advance window).

-----------------------------------

051205

This car has a GM DIS, see http://www.saturnfans.com/photos/showphoto.php/photo/20073/si/crank for a crank picture or http://www.megasquirt.info/ms2/GM_DIS.htm for more general info.

It's an extra pulse instead of missing and it's just plain weird compared to the rest.

From discussions on IRC, it doesn't sound like anyone's worked on this sort of set up.

Good that you bring it up on wiki, because you must be very lucky to get full-picture answers on IRC. The code written for MembersPage/FiatStilo, which considers the small gap (the shortest gap between two consequtive trigger pulses) as "missing tooth" (should be called indextooth), should be able to drive this wheel too. Config changes:

* trigger_tooth=1..3 # max 2 for 6 cyl

* another_trigger_tooth=03 # 4 cyl

* another_trigger_tooth=02 # 6 cyl

* tooth_wheel=07

However, it should be tested on the table. This wheel is better than MembersPage/FiatStilo's since it allows wasted spark without camsync. I see a small problem: RPM is calculated from the time between tooth 0 and tooth 3 (another_trigger_tooth), which is uneven for this wheel. This results in some perceived RPM fluctuation, which should be fixed (small firmware mod).

Possible/probable roadblocks requiring extra code are:

sync pulse comes 70 ATDC # 4cyl

With 4cyl, 70 degree ATDC = 110degree BTDC. I don't see why this would be a problem, it's outside the ignadv window, even if ALS is used.

------------------------------------

Older:

So, finally time to get going on this, shopping list/plan is as follows (comments appreciated):

genboard

6 fets

1 dpak fet

idle stepper driver

later:

WBO2, harnesss, connector

cam sync generator

egt thermocouple/connectors

COP plugs

4 igbt drivers for COP

Genboard 3.3

no case/connectors

stock computer case and connectors (attempt at plug and play)

Use jumper wires and a stub board to connect from genboard to connectors removed from stock computer

Drivers:

fets:

4 injector drivers (driving 36lb low impedance injectors from a thunderbird)

batch fire 2+2 for now, hopefully sequential later

1 wbo2 heater

1 power steering orifice (pwm to control properly? need to scope, probably add later)

1 boost controller (using an egr solenoid probably low current, use extrafet spot?)

idle stepper driver - for the idle stepper...

TPIC:

egr control (stock solenoid)

canister purge solenoid (stock)

fuel pump (via relay)

fan (via relay)

air conditioning (probably relay, but might need to move to extrafet)

3 - stock check engine, coolant temp, and shift lights

DIS bypass signal (external circuit/igbt channel ?)

bypass an igbt channel and directly drive the est signal to the DIS

Sensors:

stock coolant temp sensor (standard GM type)

stock air temp sensor (same)

stock knock sensor (ditto)

2 bar GM map sensor

crank position signal from DIS module (square wave, hallish? even though sensor is inductive)

cam position signal from cam sync generator http://www.msdignition.com/sci_16.htm

stock throttle position sensor

stock nb O2, upgrade to wbo2 once running

Issues:

Getting the speedometer to work as it's driven by the PCM which takes the speed sensor signal and does the math to accomodate different size tires and then sends it to the speedo. This may be doable with an external part, will worry about this later...

Need a digital input for AC request line.

Reading the crank signal from the DIS should be easy because it's just a square wave. Controlling may be more difficult as it needs high or low so the igbt won't work. Since the ixdn404si can pull high or low, jumpering the igbt pads would do the trick or just connect directly to chip (maybe configure as input?). Cam sync signal is also in the same format, but won't be useful until sequential injection comes into play.

Gameplan:

Wire up injectors, idle stepper, and sensors, get idling with DIS controlling ignition, then get DIS working, then all the other niceys/emissions as time/money allow.