$EE Flash tool progress

[kur4o]

vpp is hardwire shorted between 2 chips and when it`s turn on, it` on for both chips.

You might try tside only to see if the problem persist.

[steveo]

vpp is hardwire shorted between 2 chips and when it`s turn on, it` on for both chips.

i was kind of afraid of that.

first this does mean that the other side, even if you don't want to program it, has vpp applied to it for the entire programming duration. i don't think that has any negative effects, but im unsure at this point, it definitely does decrease the safety margin a tiny bit?

so the question for the day is, does sending high vpp to an eeprom of this type for a few minutes have any negative effects, if you don't write anything to it during that time?

it's very possible (and now seems likely) that the t-side supplies vpp for both sides. since vpp must be applied during erase, i can only assume that the t-side erase code is when VPP is turned on; so to program e-side only will require hacking the erase routine for t-side to remove the part that actually erases it.

i'll do more research

it also might be possible that single-sided flash is more trouble than it's worth

[kur4o]

vpp is the voltage that erase and program chip. It must be above 6.5v for any of this to happen.
If it is applied and not used, It is not harmful because software execute the process.

Also I measured vpp during read cycle and it is also applied, even it is not needed. My eeprom programmer only applies during erase and write.

[fbody_Brian]

i was kind of afraid of that.

so the question for the day is, does sending high vpp to an eeprom of this type for a few minutes have any negative effects, if you don't write anything to it during that time?

I don't think so,
From the data sheet:
Or, the system designer may choose to ‘‘hardwire’’ VPP , making the high voltage supply constantly available. In this case, all Command Register functions are inhibited whenever VCC is below the write lockout voltage VLK0
The 28F512 is designed to accommodate either design practice, and to encourage optimization of the processor-memory interface

[steveo]

From the data sheet:
Or, the system designer may choose to ‘‘hardwire’’ VPP , making the high voltage supply constantly available. In this case, all Command Register functions are inhibited whenever VCC is below the write lockout voltage VLK0

ok, i assumed as much. that's good news.

Also I measured vpp during read cycle and it is also applied

that's actually really helpful since it narrows down where the code is that applies the voltage. i assumed it would just be part of the erase code that toggles it.

with that in mind, there's something that's run on t-side that isn't run on e-side

it used to be run during a read operation, but i tried removing it and it still read successfully, so i left it out in the latest beta versions.

have you tried the latest beta of eehack to see if read still applies VPP voltage? my hunch is that it doesn't anymore, due to lack of this routine, executed at offset 0x0200 on t-side:

b6 10 02 84 f8 b7 10 02 86 07 b7 10 30 05 3d 3d 3d b6 10 31 81 66 25 04 81 a1 23 05 cc 06 02 20 3e b6 18 00 8a 80 b7 18 00 9d 17 9d 23 9d 17 9d 23 b6 10 02 84 f8 8a 05 b7 10 02 86 07 b7 10 30 05 3d 3d 3d b6 10 31 81 bc 25 04 81 e9 23 0d b6 18 00 84 7f b7 18 00 cc 06 03 20 03 cc 06 aa 3c 30 ed 00 c6 02 9d 14 38 39

i just checked and it's not run during an e-side flash, that might be my bug!

i just thought of one other thing. what turns VPP off after, is a reset procedure at the end (i'll try and find that too). if you lose flow control and the main loader loop at 0x0000 stops executing, you can't run the reset routine and turn VPP off. this creates an operating state where vpp is permanently on until ecm reset, but the ecm is locked up so should be safe.

attached is the last beta; can someone check for VPP during READ in this version?

[kur4o]

I am almost sure this turns vpp

ldaa 1800
bset $80

At reset or
ldaa 1800
bclr $80

is cleared.

Address 1800 is processor relay control
bit $80 is internally wired on board with vpp voltage.
Not sure which processor turns it on, or both can.

[steveo]

i'm glad you understand the hardware end of this board. that does look viable

i can't get ida working for these segments due to offsets, disassemblers hate me, so here's my hand disassembly:

b6 18 00  : LDAA 0x1800    ; A=0x1800
8a 80     : ORAA $0x80     ; A=A~$0X80 (set bit 0x80 of 0x1800 on)
b7 18 00  : STAA 0x1800    ; 0x1800=A
9d 17     : JSR 0x17       ; execute subroutine 23 bytes ahead, SUB:A

here's a good one for you kur4o, what are the hardware bits for the fans or CCP solenoid? i'd love to find where the diagnostic routine at 0x0000 actuates them, i find the constant CCP clicking and fan noise to be annoying when flashing.

[steveo]

i think i found the vpp disable routine too:

b6 18 00 : LDAA 0x1800 (should be 10000000)
84 7f : ANDA $0x7F (0x7f is 01111111, so only disables our VPP bit)
b7 18 00 : STAA 0x1800

[steveo]

anyone care to try my latest attempt?

http://fbodytech.com/download/223/

i hope this is it.

i added a bit more verbose error handling to a lot of the routines too (hope I didn't break anything in the process....)

[steveo]

did a bit more work, i reviewed kur4o's logs where it failed to upload the programming routine "sometimes", and decided to try something different that might help. now it loads the mode 5 loop immediately before uploading the development routine at 0x0000 so there's no delay, before it placed both ecms into mode 5 at the same time, which, on a slow computer, has the opportunity to time out the mode5 loop. i dont know why i wrote it like that in the first place.

flash read is now a bit...behind...but i think it's less important, nobody uses flash read during actual tuning sessions, it's more of a novelty.

also spent some time rewriting the progress log so it displays more useful errors and less verbosity in areas where not required.

i covered a bunch of edge cases in responses and recovery to try to ensure nothing goes crazy if an unexpected reply happens too.

finally you can now cancel a flash operation during initialization and it'll bail at the appropriate time, so you have time to change your mind.

i fixed the bin compare feature too, it was a bit buggy, single-sided flash should be good to go now.

i'm hoping this is a stable flash write program now, but lets test 'er out! still hesitant to officially release as stable until my sockets arrive and I can stress test, though.

http://fbodytech.com/download/223/

[kur4o]

I did multiple single side test and full flash and couldn`t make it fail.
I did have some connection problems on cold boot with no connection made(open the program and go straight to flash.).


I couldn`t make it read the bin also.

Here are some logs.

[steveo]

awesome!

i think i broke read support (since they share lots of functions and i wasn't paying attention). i'll fix it.

write is the priority, since read was already working before.

I did have some connection problems on cold boot with no connection made(open the program and go straight to flash.).

i wonder why? i'll keep working on that. whether it's connected or not, it always does a bunch of mode 1 requests, so the connection should be in the same state when it starts. i do my own checks for voltage, rpm, etc, which are redundant, but it's mostly an excuse to check for bad checksums so i can go 'hey, your connection is no good, we aren't flashing anything today...'

[steveo]

that zip is invalid

[jthompson122183]

Anyway of rewriting the bootloader to run at 10.1 volts instead of 12.1? Most lead cell batterys that I've seen hover around 12.5 resting voltage. By the time the fans and ccp get done doing what there doing that voltage drops. Just a possible idea?

[fbody_Brian]

Tested single e-side write and it worked!
Read was also broken for me. After an attempted read I had to reset the pcm or the car wouldn't start.

I'd get you the logs, but I couldn't seem to find the debug window or the option.

Ensuring that conditions are ideal for programming...
Testing connection stability...
Stability OK!
Executing Flash Read Routine!
F4 Disabling security...
F4 Entering programming mode...
E4 Disabling security...
E4 Entering programming mode...
Uploading T-Side Development Routine...
Uploading E-Side Development Routine...
Uploading E-Side Read Routine..
Uploading T-Side Read Routine..
Reading flash memory...
It's safe to cancel this operation if you'd like!
<-- See Progress
Can't read ECM data, giving up!
*************************
Unfortunately, the development routine is now stuck in ram :(
This means you need to disconnect power from your ecm for a bit
to reset it before it'll function normally; pulling the PCM BAT
fuse would do the trick!!
*************************
Press CANCEL to exit.  Will disconnect automatically.