Quote: Originally Posted by junkcltr 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. Cool... so can you now upload a new bin with the GUI and see the delta? My test bench only has power and an aldl interface. Neat to see someone else reach this milestone.

And my solution was exact for the problem mentioned before. Once I closed Tunerpro, I was able to fire up the bench, see no PW, download the eprom, and call it 'test'. re-enter Tunerpro, open 'test' flip the flag bit, close TP, open the utility, upload the updated new 'test' bin, and watch the PW pop up on the scope screen.

This is too sweet, I'm gonna have alot of fun with this!

I changed the desired idle vs. temp. and saw the changes in the ALDL datastream. It worked fine. The TCL "reset" command caused the ALDL stream to lock up. It also caused the emulator to need a complete power down or TP would not recognize it. Only a ECM power-down & power-up would fix it.
I think the TCL "reset" problem is because of the malformed command.

I just fixed this for you. Build here:

Index of /beta/Builds

Give it a go and let me know if it works. Remember to disconnect from your ECM (ALDL) in TunerPro before running your script.

What bin are you using? I have only had issues with locking up the ecm when the source code was not quite right.

BTW: the AUJP_RT.BIN works in a real car...

I still don't think that is the cause of your lock up, since the ecm will just be writing stale data from it's internal buffer instead of known data (the aldl command itself is a valid packet, it is only malformed from the perspective of mode 4 which does not do error checking save for checking the # of bytes to write).

change this:
<code>proc resetEcm {} {
global _serialPortSpawnId
if {$_serialPortSpawnId == ""} {return}

aldlSend $_serialPortSpawnId "F4 59 04 01 60 00"
aldlReceive $_serialPortSpawnId
return OK
}</code>

to this:
<code>proc resetEcm {} {
global _serialPortSpawnId
if {$_serialPortSpawnId == ""} {return}

aldlSend $_serialPortSpawnId "F4 5A 04 01 60 00 00"
aldlReceive $_serialPortSpawnId
return OK
}</code>

I will give Mangus' TP4.13 with the comm port code change with the TCL script with the updated "reset" command this weekend.
I have been doing a lot of commenting on the $58 BBZB code. I have been tracing through it to see how different parts of it are affected by the Mode 4 command. I might start adding the NVRAM code modifications to it this weekend.

Works. I guess it's my turn now, because I know my GUI does not release the com port until you close it...

I tested the TCL "reset" command on the bench with the aujp_rt.bin. It seemed to work fine. I could change CAL stuff and reset and the ALDL worked properly everytime.

I tried the beta TP4.13 with the comm port release on WIN98 SE and it created fatal execution errors with the KERNEL32.DLL and WISH84.DLL when I ran the TCL script. I would open TP and ALDL log, then click the double arrow icon to stop the ALDL connection. Then I would run the NVRAM TCL script and it would report "failed to allocate". The windows debug box showed the error was with KERNEL32.DLL.

If I closed TP and ran the NVRAM TCL script it was fine.

What the heck is wish84.dll? I've never heard of it nor can I find any info on it anywhere!

Weird.

Which program is crashing when you run the script? The executable the script is running, or TunerPro?

WISH84.DLL is from running the TCL script. All TCL srcipts run on top of the WISH84.DLL executable.

It seems like TP didn't release the comm port completely and WISH is having a problem getting it. It might be just a problem with WIN98 SE and how MS cleans up releasing the comm port.

It does cause a problem with TP afterwards though. The font in TP becomes large and bold. Once it completely locked up TP so that I had to kill it with the task manager. The other times it closed using the normal method but the font was still large and bold. It looks to be about 12 to 14 point font.
I can screenshot it if that helps. I did have a problem running electronics workbench with TP open last week. With TP open, I ran electronics workbench it came up with a fatal execution error. I never had an error from it before with other programs running.

I might move to WINXP on the laptop. Not sure how bad it will be on a 300Mhz machine so I have been trying to avoid it. I really like the NVRAM module setup so I will upgrade the OS if I have to.

Ah, I see. So the unhandled exception really is on the TCL side, then. The problem is, with the COM port there is no way to "partially" release it. The port is completely released with one function call: CloseHandle(<handle to port>); So there's nothing more I can do on that front.

Now, if the TCL is causing these font issues in TunerPro that you're describing, that means one of two things is happening:

a) TunerPro is allocating and using memory beyond it's own application space and WISH is (rightfully) using that memory, in which case TunerPro is "in the wrong", or

b) TCL is allocating and using memory beyond it's own application space and TunerPro is (rightfully) using that memory, in which case TCL is "in the wrong."

It could very well be A, and since you're seeing a font issue, that's a good pointer in the direction that I should look.

Can you attach (or email me) a screen of the issue?

Thanks again for the continued assistance, Junk.

I did some more testing with other programs and TP running.

I have attached a few screenshots from a digital camera. I reduced the resolution so the file size would be smaller. The images are from a session where I connected the emulator and ALDL to the ECM bench. I then opened TP and clicked the double arrow icon to ALDL log. The emulator was recognized when TP was run initially.

I changed a few bin items and saved. All was fine. I then minimized TP and ran MS-Word. It came up with the "not enough memory box". I took some pictures of it. I then maximized TP and the bin items I was editing were now bold font. I tried running MS-Word again and the TP bin item box came up blank when I went back to TP. Notice in the pics that the TP window box lost the "window name" at the upper left corner. I then closed TP and went to shutdown, but the normal WIN98 popup menu was replaced by a strange "Windows 98 SE" message box. I took pics of that too.

I did not get strange results when the ALDL was not connected most of the time. One time TP did freeze with the emulator not connected and the ALDL not connected with no other programs running. I made a few bin changes and saved. TP then froze and I had to ctl-alt-del to kill it. No errors came up so there was nothing I could take a pic of that would be out of the norm. The font was normal before it froze.

I can test out other specific situations if you need a certain sequence of events to be done to help debug it. The zip file contains JPG images (screenshots) and is 530K. I will remove it after you download it.

Thanks,
Junk

Heh. Your computer is inhabited by evil spirits, dewd.

The Win98 menu bitmap is a feature of the start menu. You probably have it disable by default, and whatever this corruption is, it's causing the start menu itself to not show up, but the bitmap still shows.

So the memory used by the table's grid control is being stomped on, and it appears some OS memory is being stomped on.

How much memory is in this particular PC?

Let's take this offline to keep from further hijacking... email me at mmansur at hotmail

Email sent. I will send all stuff to that email address from now on.

I've seen word cause problems with other programs.
Word appears to get corrupted after a while and stops playing nice.
Never had a problem with Excel,Acrobat reader,TP, and a text editor open at same time. I try not to do that with the 98se/128meg machine though.

To program a chip on the bench you would need power to b1 and b16 ,ground to b5,b6,b9 and a12 along with the aldl hooked up?
thanks for helping me learn

Assuming a 727
C1, B10 to 12V
C6 to GND

Assuming a 730
BA6, BB1 to 12V
BD1 to GND

A lot of the power input pins are internally connected together...

Hey where is the new link to the gui? Thanks!

http://downloads.activestate.com/Act...ases/8.4.19.3/
this seemed to work but i don't have a test bench to check it.
http://www.thirdgen.org/techboard/at...-rtp4-tool.zip