MonteCarSlow

Here is a GUI program that can be used with the nvram hack to allow uploading and downloading of bins to the 4kb nvram.

You need to install ActiveState's TCL distribution before being able to "run" the GUI. Get it here: http://downloads.activestate.com/Act...6-threaded.exe

Once the above is installed, down rtp4-tool.zip from this post and unzip rtp4-tool.tcl into a folder somewhere. Just double click the file and the GUI should pop up. Set your COM port and you should be good to go.

Anyone can use this tool to download their eprom over aldl to a file by using the "Download EPROM" button in the GUI. Saves messing around with the memcal if you are trying to read a buddies' chip.

I've tested the GUI on my WinXP laptop (1.5G Pentium M) and my old WinXP PC (PIII-450). The tool should also run on Linux and Mac OS X if you have Tcl and the Iwidgets library installed. However, some editing of the COM ports list will be necessary for Linux and Mac.

The GUI works best when the ecm ALDL chatter has been disabled, but I've done all my development with it turned on so theoretically the program should be fairly resilient.

EdB

junkcltr

iTrader: (1)

Cool. I will give it a whirl tomorrow night. I just have to install the TCL interpreter on the laptop computer (Win98). I have the new & improved ECM testbench setup working and I am going to use the emulator to debug the $58 BBZB code with the NVRAM loader installed. It will probably take a bit of time but doing CAL data changes via the ALDL to the $58 will be nice.

Thank you,
Junk

junkcltr

iTrader: (1)

And a big thanks to you, ECM GUY, Ludis, Mangus, TGO, and all the others that make DIY PROM possible.

JP86SS

iTrader: (1)

I'll second that

MonteCarSlow, Have you looked into using "PCB123" ?
Its a free board construction package that you can purchase right from the designs.
It is priced very nice for small qty runs and is pretty easy to use.
Check it out with a Google search.
not sure what you did for the original batch because they turned out real nice too.

junkcltr

iTrader: (1)

I tried installing tcl/tk 8.4.12 on Win98SE. It failed instantly at the beginning of the install. Searched the web and found this....Tcl - Active Tcl 8.4.12.0 fails to install in win98
It is the exact problem that I had.

I am downloading v8.4.11.2 and will give it a try. If that doesn't work then I am going to download v8.5 beta and compile from source using MinGW via Msys on Win98SE.

MonteCarSlow

I just downloaded 8.4.11.1 and installed it on a Win95 P-75 24Mb ram laptop... its really slow, but it WORKS.

JP86SS

iTrader: (1)

Cool.
Do you have a link to the older version.
couldn't find it on the site,
Thx

Edit: http://downloads.activestate.com/Act...indows/8.4.11/

MonteCarSlow

http://downloads.activestate.com/Act...win32-ix86.exe

MonteCarSlow

Eagle CAD (non-profit license edition) and PCB Prototypes for the pcb service.

junkcltr

iTrader: (1)

I still can't get the RPT.bin to connect via the ALDL to TP4.13_beta. I tried it with the diagnostic signal (ALDL pin B) both open and tied to a 10K ohm resistor to ground. I tried Freescan with it too. It wouldn't connect.

It has to be something simple I am doing wrong here. Have you ALDL data logged with the supplied $8D bins. I can't get either to connect. I loaded a stock AUJP $8D in the emulator and it connected. I then loaded the $AXXC bin(s) and neither would connect. I need to study the supplied .asm files more to see how the ALDL modes operate.....and get some go-go juice/coffee.

MonteCarSlow

I haven't been able to connect with TP either (never have). I use a modified copy of Craig's old "E6" logger in DOS mode. I just tried it - it works fine as it always has before the source code mods. That 10k ohm is only for the 165 ecm isn't it? I never need to do that trick, I just send the ecm F4-57-01-00-B4 to get a mode 1 packet.

junkcltr

iTrader: (1)

Yeah, I think I know what is going on with it. In your custom bins you disabled the ALDL broadcast message (aka chatter). I saw it in the ALDL schedule table.
The normal method for ALDL mode commands from the PC are sent after a ALDL broadcast message is sent from the ECM. I am guessing TP and Freescan wait for the broadcast message before sending the ALDL Mode command. The PC never gets the command so it does a time out. I seemed to remember ECM85x just jamming out the Mode 1 command and that was never really right because had a possible bus contention thing. The odds of contention was very small, but from a design point of view it wasn't right.
I always wondered how TP and Freescan did it. Learn something new everyday. I am going to try enabling the broadcast message tomorrow and see how it goes. The tough part is neither TP or Freescan report an error....they just time out. I am guessing it is due to no ALDL broadcast msg.

I have been commenting the Mode 4 code section of the $58 BBZB. It is going OK and will proabably take a few more nights to finish commenting and a few more to code the Mode 4 write command stuff. The $58 ALDL mode stuff is all spread out. It isn't nice and concise like the $8D stuff. In general, the $58 stuff is scattered everywhere. No wonder why the ALDL BPW gets spurious data sometimes. Anyway, so far the Mode 4 stuff doesn't look that bad. The NVRAM checksum routine & stuff should be easy in comparison. After I get the $58_NVRAM so that I can upload/download I will look into why TP and Freescan will not connect. I am getting more familiar with TP4.13 and at this point I can't see going back to ECM852 because it won't do Windows properly and I would have to write a $58 ALDL def. for it. I sure did like being able to start/stop datalogging by pressing keys instead of mouse clicking. I hope Mangus adds hot keys for recording in the next version of TP.

I still need to edit the TCL file to change it over to $58 message parameters. All of the messages that you use in the $8D are listed in the $58. I think I need to check on the "reset command" though. Nice job on the TCL file. It is easy to read and I rarely do TCL stuff. It is good to see you actually write out name of variables so that it flows like a book.

I used the v8.4.11.2 with Win98SE and the program worked fine. It took a few seconds to load at first. The actual data transfers went as fast as possible with the ALDL being the rate limiter. After the first execution of the TCL script it reloaded quickly because it was still in PC mem (96 MEG). Overall, it was plenty fast on the 300Mhz-PII.

I think I had enough $58 commenting for today. Back at it tomorrow.

MonteCarSlow

My aldl protocol code waits until there is nothing in the receive buffer and then tries to send. I don't have a problem with chatter or no chatter. It would be a surprise to me if they wrote their aldl protocol assuming there was chatter.

I'm still dumb founded the aldl protocol part of the GUI works on my old P75 laptop in Win95. I rewrote parts of it before sending it out, the old code didn't work without delay statements.

junkcltr

iTrader: (1)

I haven't really looked at the mechanism you used in the TCL file for transferring data. I did take a look at the "reset" ALDL message because I didn't remember one ever existing. The MSG ID and MODE look to be a Mode 4 message but I can't find it defined in a BIN. Where did you find the documentation that says this is a "reset command". I need to dig deeper into this, but right now it just seems like a bad/undefined Mode 4 command.
It could just be that I am looking at it wrong thinking it is a "reset" for the ECM. It might be a "reset ALDL" messaging which is really Mode 7. Am I way off here?

I tried enabling the AXXC chatter by inserting the Time_0 message address in the message scheduler table. Still no connect with TP. I did the insert using a binary editor. It may be that the code was assembled with the address removed and it is missing somewhere else in the bin.

MonteCarSlow

I got that trick from one of RBob posts. Write any byte to 0x6000... it resets the ecm. I guess I should have formed the command a bit better in the code. You are right, it is a malformed command because it doesn't supply the byte to write to 0x6000 (the packet is still valid and the ecm will fetch the next byte in the buffer as the byte to write even though it wasn't actually sent via aldl). Sorry about that confusion. I'll fix it - I'm sure I'll be wondering 5 yrs from now what the heck I did.


edit: Here's the old thread I got the info from: https://www.thirdgen.org/forums/diy-...38-swi-8d.html

junkcltr

iTrader: (1)

Yes, that is how the SWI instruction causes the processor reset. The "external emulators" cause the reset sometimes by corrupting an instruction. That forces a processor reset also. That is also why some people see strange behaviour while on-the-fly tuning when do a key off/on after tuning. The vectors are defined at the bottom of the code in the interrupt vector space.

That answers that. It is an ECM reset command, not a force "Mode 0" command. Without the 0x6000 address things may act a little strange. I will download the latest TCL file when it is ready and use that for testing.

I am still commenting the $58 BBZB Mode 4 stuff. Looking good so far and I fixed a few bad comments that I came across in other sections while doing the Mode commenting. All good stuff. In terms of TCL file changes, All I really need to do is change the MSG ID from "F4" to "F0" for the most part. Good choice on using TCL. It is nice to make a quick code change and just run it. No need for the compiler on the laptop, although I ended up with MinGW on it with Msys so that I can do file diffs and scripts for assembling. Tab completion is a must have for me. Emacs split windows for code editing makes it so much easier. All of it is running great on WIN98SE.

MonteCarSlow

If you move all of the procs into a seperate file, you can add a button to the GUI to (re)source the procs in your file after you've edited the file. Saves reloading the gui. I moved everything into one file when I released it (less confusion).

jwscab

So how would I go about enabling the chatter(ALDL broadcast message) on the BIN, to test working with TP? If that gets re-enabled, do you forsee any problems? I'm assuming its just a byte change, but, I'm total crap when it comes to the assembly. some kind of mental block or something...

this is a great thing, BTW, I can't wait to actually start using it..Ernst, you might think about spinning up some new boards, as this gets more attention, i have a feeling there will be more demand for this. I can probably help out on the hardware end, if you need it, just PM to let me know.....

Mangus

Already there. See the Tools->ALDL/Datalogging menu. Ctrl + R will toggle recording. Ctrl + Space toggles playback, etc.



I'm contemplating making all hot keys assignable in V5. We'll see how much work that'll take, though.

MonteCarSlow

I figured out this morning what the problem is. It's TunerPro. It is expecting a mode 1 reply to start with 0xF4, which is not universally true. AXXC starts a mode 1 reply with 0x82. By changing the 0x82 in AXXC to 0xF4, TunerPro immediately connected. The byte is located at offset 0x08C6.

Mangus - if you are reading this, note that it is possible to get into a race condition on mode 1 packets if you are looking for 0x82 and 0xF4 as a start of packet when just sniffing chatter packets. In your receive routine, after receiving a bad checksum you should toss the next byte you receive into the bit bucket to get out of the race condition.

EdB

Mangus

I'm not quite sure I understand. TunerPro itself doesn't have any expectations. The definition is what defines what a mode 1 (or any) commnand looks like, and what its reply looks like. Additionally, the current incarnation of TunerPro doesn't listen for chatter (the next major version will).

It sounds like you need to change your definition to match your expectations. Also, you'd be doing yourself a favor to modify your code to not send the scheduler (chatter) commands.

MonteCarSlow

In AXXC:
send: F4-56-01-cksum
reply: 82-xx-xx-xx... etc

In AUJP:
send: F4-56-01-cksum
reply: F4-xx-xx-xx... etc

I think your packet receive code is looking for 0xF4 as the only valid start-of-frame. Am I mistaken? Because if I change axxc's definition of how to send a mode 1, everything starts to work in TP.

Mangus

Ah, I see now. Yes, you're right. Every GM ECM responds to a command with the same chatter ID byte the command has. So indeed TunerPro is looking for that. Again, the next version will not (I'm doing a 100% re-write of the data acquisition engine).

Did you code the 0x82 in there (i.e. did you chance the stock code to reply with 0x82)? It looks like you've found the fix.

MonteCarSlow

No I didn't. However, if you disassemble AXXC, you see something really weird. It has a factory(?) code patch applied in the aldl section (they added a mode). Either my AXXC baseline bin is not genuine original, or GM made a mistake when they released this bin.

Mangus

Bizarre. Very bizarre. Either it is indeed a mistake on GMs part, or they had a really good reason to deviate from their own specification. Was AXXC used in any other platforms (maybe one that has other modules that reply on the Mode 1 data)?

What mode did they patch in, and what was it used for?

MonteCarSlow

They added mode 11. I haven't spent the time to figure out exactly what it does.

MonteCarSlow

No I didn't. However, if you disassemble AXXC, you see something really weird. It has a factory(?) code patch applied in the aldl section (they added a mode). Either my AXXC baseline bin is not genuine original, or GM made a mistake when they released this bin.

tpep

Curious to know how to do this. I have a complete commented disassembly, so I could probably figure out how to do it, with a little hint...

Will this allow troublesome, chatty ECM's to connect in the current version of TP? I am eagerly awaiting the new version, since my '91 vette just can't seem to connect. I've tried the Silence Command over and over.

If I can overcome this by changing the bin or source code, I will definitely do it.

Todd

MonteCarSlow

There is a table of 16 possible aldl messages that are sent, round robin. Populate the table with 00's to disable the chatter.

<code>
*******************************************************
* SERIAL DATA CALIB
* 8192 Baud Comm
*******************************************************
L8824: FCB 118 ; INJ FLOW RATE 3776 gal/hr
; (GAL/HR)/32, IP DISPLAY
;-------------------------------------------------
; Broadcast Message Scheduling table
; SELECT MSG ADDRESS FOR EACH MINOR LOOP NUMBER
; If address = 0000 the the message is ignored
;
; table = Address
;-------------------------------------------------
L8825: FDB $0000 ; 0
FDB $0000 ; 1
FDB $0000 ; 2
FDB $0000 ; 3
FDB $0000 ; 4
FDB $0000 ; 5
FDB $0000 ; 6
FDB $0000 ; 7
FDB $0000 ; 8
FDB $0000 ; 9
FDB $0000 ; 10
FDB $0000 ; 11
FDB $0000 ; 12
FDB $0000 ; 13
FDB $0000 ; 14
FDB $0000 ; 15
</code>

Mangus

Monte - quick question: If you disable all messages in the scheduler, does that open up the ECMs "listen" window, too? I know, for instance, that some ECMs listen for a short period of time (some, like $58, as low as 2ms) after a chatter packet.

Seems that it would.

RBob

iTrader: (1)

It is probably the BCM chattering. I've yet to see a y-body $8D bin chatter. If you can unplug the BCM do that and try TP again. If that doesn't work it may be the ABS module. Much different then what is seen in 3rd Gens.

RBob.

Mangus

You must mean not chatter. Y-Body BCCs are chatty as all get out. Worse than SyTy even.

Unplugging the other modules probably won't work, as the ECM will still be sending out it's scheduled "pings". The best way to get around it until the next major version is to disable them in the scheduler.

RBob

iTrader: (1)

No, I meant what I said. What y-body $8D bin's have you seen chatter? I'd be interested. . .

RBob.

Mangus

Then I apologize for putting words in your mouth. Every 90 and 91 'Vette w/ a digital dash is chatty.

RBob

iTrader: (1)

Yes, there is chat on the ALDL line. However, I believe the CCM initiates the chat, not the ECM. The ECM just responds to CCM requests.

RBob.

Mangus

What does sending the ECM a mode 8 command accomplish if the ECM isn't in charge of the conversation? Does it tell the ECM not to respond to the CCM, and once the CCM doesn't see the reply from the ECM the CCM shuts up too? Or does every device on the line respect the mode 8 command?

RBob

iTrader: (1)

Mode 8 command is for the CCM.

RBob.

Mangus

I did not know that. Thanks Bob! And that sheds light on other matters too. For instance:

$58 is chatty, but it doesn't shut up with the mode 8 command. It only shuts up by responding to chatter with the Mode 1 command. In contrast, $8D shuts up with mode 8 in response to chatter, but does not shut up with mode 1. This now makes sense, since $58 doesn't have a CCM.

Learning is awesome. So is RBob!

MonteCarSlow

Anyone with the 4kb nvsram module care to beta test an AUJP bin for me? It works on my bench (no sensor inputs - but I can update the promid using the GUI and see the update in aldl stream). It'll be another week or two before I can test it myself on my wife's 83 T/A.

E.

junkcltr

iTrader: (1)

I finally had a little free time to play with this stuff. I tested out the aujp_rt_bin on the testbench. Everything looked good except for the reported ALDL "BPW". It was stuck at 0.00ms using TP with the included 730.ADS file. I tried an old 730 bin that I used before the boost setup and it reported the BPW with various values. All of the other aujp_rt.bin ALDL values looked OK.

Junk

jwscab

Junk, man, thats freaky.....really....I just got my bench back up and running tonight, literally minutes ago, and got to test the file as well! Had a bad capacitor solder joint that was preventing my 'crank' signal from working (my own bench, added some flip flops to let you actually 'start' the 'car'.). Then I got sidetracked with the missing jumper for the onboard eprom select.

Ernst, I noticed the same things Junk saw. Everything looks pretty good, with the exception of the injector PW. I'm use the Super8D.xdf in tunerpro, but not sure of the version.

I'm planning to test out the aldl stuff as well. Will let you know what I find. Connects right up though, quickly!

RBob

iTrader: (1)

Is vats enabled in the bin? Gets me all of the time.

RBob.

jwscab

that might be the case. I was just happy that the bench was back up and running, and that the thing actually fired up (all my stuff was all torn apart, and piled on itself from other projects.) I'll have to check when I get a free minute, but that certainly sounds like it.

Oh, just a question to Ernst, I briefly looked at the GUI, maybe I'm just dense, but, what is the exact usage procedure? meaning, uploading, downloading, when I hit the button(s), there was no indication that anything happened, and I expected something to prompt for a .bin file source or destination? Does the gui just look for the .bin in the folder that the application resides in? and does it need a specific file name? I have to apologize, I haven't even gotten a chance to test out the dos commands yet, so this is the first time I'm trying this functionality.

MonteCarSlow

If your (selected) COM port connection was successful the buttons will work, if not they will not do anything when you click on them. Was the port being blocked by your aldl logger?

Upload BIN: uploads the cal region of a ($8D) bin to the nvsram
Download BIN: copies the cal region in the nvsram and the code region of the eprom into a bin file (the downloaded bin can be edited with TunerPro/Cats)
Download EPROM: copies the entire eprom (8000-FFFF) to a bin file
Reset ECM: resets the ECM
Restore NVRAM: invalidates the checksum on the nvsram and then resets the ECM (the ECM will renew the nvsram contents with the contents from eprom after the reset)
----------
Yes it is enabled. It is a stock aujp cal converted for use with the nvsram (to enable the on-the-fly calibration changes via aldl).

MonteCarSlow

There is one "bug" I've noticed recently. I think I am going to add the eprom promid to the checksum. Anytime the promid changes in the eprom, the nvsram will get reinitialized with that eprom's baseline.

I was also thinking it would be good to build a special test bin that checks the nvsram (flashing a certain pattern on CEL for errors), and also wipes the nvsram clean when done (there by ensuring the nvsram checksum is null and void).

jwscab

ah crap, thats probably what it was. I had a ton of windows open, and had tunerpro open. I'll try it again, disconnecting the logger.

I agree, might be nice to have a test bin, though not critical.

BTW, thanks for this stuff, its gonna be a very cool thing to have moving forward!

MonteCarSlow

The other way to do it is to install an eprom with only the mode 4 byte write hack in it, and then using s/w on a PC use ALDL to read/write the nvsram. I used this method when building and testing the nvsram boards before shipping them out.

junkcltr

iTrader: (1)

I think RBob is correct. All of the ALDL params were coming through fine except for the BPW. Kind of interesting how GM did it. Allowed ALDL but force the injectors off. I will take a look at the VATS flag and re-test it.

I noticed before that TP will grab a comm port and not release it when not datalogging. Therefore, the TCL script can't get the port. The TCL script needs to grab the Comm port only when a button is clicked and then release it afterwards. TP needs to grab the comm port only when an ALDL comms button is clicked and release it when stopping the ALDL session. It doesn't seem to do this currently. Hopefully, it will in the next release.

JP86SS

iTrader: (1)

XDF def should be multiply by 0.015259 and set to 16 bit.
HTH

junkcltr

iTrader: (1)

Rbob was correct. The BPW was disabled due to VATS. With VATS disabled in the aujp_rt.bin everything reported correctly on the ALDL link.