stuckatcuse

Maybe you guys can help me out. I bought an autoprom a couple of months ago and I can't seem to emulate with it. I'll elaborate below:

Oh yeah, the tone of this email may sound like I’m bashing this equipment, but rest assured I am not. Hours of frustration are making me cranky, and I acknowledge that it’s probably me doing something wrong.

I'm using the 0D bin.

So far ive been able to burn 2 chips with version 4 of tunerpro. I decided that some of the problems I'm having may be related to the beta version so I switched to version 3.xx. It took me literally 20 times to get tunerpro (version 3) to read one of the chips I burned with version 4 (communication errors). Finally, I saved the buffer as a bin and tried to emulate.

I thought I read in the instructions that it was fine to update the emulation ram (entirely) while emulating but I've quickly learned that it locks up my vehicles computer, requiring me to disconnect it entirely from everything to reset it.

I know my bin is correct because I can make offline changes and burn a new chip and it seems to work fine. I've tried to adjust my VE near idle and it just seems to crash the emulation. I always get the same weird result: My blms and ints crash to the richest values (with any attempted change) and then become unresponsive to any future changes. I can literally zero the table, tunerpro says update successful and nothing happens. On a side note, I tried changing my desired RPM vs. coolant temp and it seems to work- until I make a change to the ve table. I don't want to mess with any other variables because I'm afraid I'll burn the engine. I would suspect a problem with the ecu file, except that offline changes work fine.

Most of the problems seem to be communication related, whether burning a chip or trying to emulate. I have no ALDL communication issues.

Here's to modern technology: I'm parked in back of my house writing this in my car. (Mmmm wireless...)

I'm sure you guys can help me out and I'm looking forward to hearing from someone! Thanks in advance!
Sean

Craig Moates

Did you try enabling the 'Disable Checksum by uploading 'AA' to '08' under TunerPro preferences?

Mangus

Sean -

The first thing we need to do is figure out why you're getting communication errors with verification/reading/writing/etc.

Can you try a different USB cable (I'm assuming this is a USB AutoProm)? Note that nothing significant changed between 3.10 and 4.0 that would cause communications issues like this. Also, make sure the horizontal switch on the backplane of the AutoProm is towards the port.

Also, do not emulate with a chip in the AutoProm ZIF. This will give you problems.

Let me know,

M

stuckatcuse

Thanks a ton for the quick response guys!

Mark-
I definitely had a chip in the ZIF socket.
I’ll remove it and try again.
I’ll also try using my printer USB cable.

Craig-
I’m fairly sure I had that disabled in ver 4, but I forgot to check in version 3 (after I switched back). I'll get back to you guys on this one as well.

Thanks again for helping me out!

Sean

stuckatcuse

Tried all of the above. All symptoms persist.
Any other suggestions?

Mangus

Do the upload/download failures continue? Again, thats the first thing we should be flushing out. Do you by chance have a desktop computer you can try for the sake of testing COM functionality? If it works on the desktop, you might try placing a USB hub between the laptop USB port and the AutoProm.

PS - if we can't get this figured out (its likely we will, though), we'll get a different solution to you (perhaps all three separate products, etc).

We appreciate your patience. This is indeed a hobby for both of us, afterall. =)

stuckatcuse

I more than understand. Is there a limit to the amount of cells that can be updated at one time? I'm been trying to update a table at once (Near idle VE). Also, I've actually tried this with 3 different lap tops, all plugged in... I' doubt I could find a usb cable long enough to use my desktop, and even if I did, it would be too long.

Mangus

No, no limit to the number of cells that can be updated. However, TunerPro only updates the cells that have actually changed.

You can test the AutoProm with your desktop without the AutoProm being in the car. Simply plug it into the USB port on your desktop, place it on the desk, and attempt to upload/download the binary information. Again, we're not yet concerned with emulation, we're concerned with the read/write errors. The reason is that if there is read/write errors, there's a good chance that data in AutoProm memory is incorrect, which would lead to the emulation issues you're seeing.

More questions and tips:

1) You mention $0D - you are using an adapter, correct? Which?
2) When attempting to emulate (without a chip in the ZIF, of course), are you sure the emulation header is placed correctly in the adapter? Can you describe the placement?
3) Make sure the horizontal switch is towards the port

stuckatcuse

1) I'm using an old hypertech adapter, which seems to work fine as a chip carrier. Are you aware of any issues that would mess up emulation?

2)Yes, it's placed with the notch in the chip socket the same way as the notch in the chip, which works fine. Also, emulation works great until I try to change something. It's almost like the ecm faults as soon as the update is issued, but I get no pcm error.

3) yes.

Chip communication seems reliable. I hypothesize that either the autoprom is having problems updating the nvram, or the ecm is somehow messed up upon updating the nvram.

Craig Moates

How about the 'Disable checksum by uploading AA to 08' box in the TunerPro RT preferences? Is that checked?

Also, Mark, is that the correct location for the $0D? I think it is.

Mangus

Yeah, 0x08 is the correct offset for checksum disable. Do make sure the auto-disable is checked, then re-upload the bin.

Alternately you could disable it manually by placing AA in the mask ID item (or by placing AA using the hex editor).

Checksum definitely sounds like the issue here.

What happens when you make small changes (like, changing the current idle cell or fan off/on temps)? Does the car cough? If not, it could be that the car is coughing during the upload when you change a large table, then never comes back like it should.

Grumpy

You want to set 4008 to AA to disable the checksum.

The lower half of the chip is just FF's, at least the ones I have.

Mangus

Would that not mean that all items in the definition would have a $4000 offset?

Grumpy

Yes, the code starts at 4000.

stuckatcuse

That sounds exactly right. I can make small changes (1 cell) and it's ok. If I try to upload a table, or upload the entire bin then it coughs (and becomes unresponsive to future changes). I have the checksum disable checked with the locations you specified.

From the hack:
************************************************
* ERPOM CHECK SUM ROUTINE
* TYPE $OD ECM
*
* ENTER WITH:
* X POINTING TO START OF CK SUM AREA
*
* EXIT WITH:
* 16 BIT CK SUM RESULTS IN Y Reg
*
*
************************************************
EF47: LEF47 LDY #0 ; CLR CK SUM RESULT REG
EF4B: PSHX
EF4C: PULA
EF4D: PULA
EF4E: CLRB
EF4F: LSRD
EF50: LSRD
EF51: LSRD
EF52: PSHA
EF53: TBA
EF54: BEQ LEF5F

EF56: LEF56 LDAB 0,X
EF58: ABY
EF5A: INX
EF5B: ADDA #$20
EF5D: BNE LEF56

EF5F: LEF5F LDAB #$08
EF61: PULA
EF62: LEF62 XGDY
EF64: ADDB 0,X
EF66: ADCA #0
EF68: ADDB 1,X
EF6A: ADCA #0
EF6C: ADDB 2,X
EF6E: ADCA #0
EF70: ADDB 3,X
EF72: ADCA #0
EF74: ADDB 4,X
EF76: ADCA #0
EF78: ADDB 5,X
EF7A: ADCA #0
EF7C: ADDB 6,X
EF7E: ADCA #0
EF80: ADDB 7,X
EF82: ADCA #0
EF84: XGDY
EF86: ABX
EF87: INCA
EF88: BNE LEF62


;-------------------
; TOGGLE COP REG
;-------------------
EF8A: LDAA #$55
EF8C: STAA L303A ; COP RST
EF8F: COMA
EF90: STAA L303A ; COP RST
EF93: CLRA


EF94: CPX #0 ; CK FOR DONE
EF97: BNE LEF62

EF99: RTS
*****************************************************
Looks like $08 is right

Mangus

Craig may have a solution, if this is the case.

stuckatcuse

I hope so....I just want to get my blms near idle correct, then I'll deal with off idle. I'm running so rich right now that I'm getting 200 miles out of 26 gallons of high test ($2.36/gal). I'm paying $0.31/mile right now in gas. That's too much! Craig, please help!

stuckatcuse

Anything? Is it just impossible to update a table at a time?

Sean

Mangus

Its not that its impossible. Its that some ECMs and setups are more sensitive to large data transfers. All of the emulators exhibit this issue (except the Ostrich).

Craig - any word on the hardware update for the AutoProm?

Craig Moates

I thought I'd already fixed that...

stuckatcuse

Sorry guys, maybe I haven't been keeping up. I guess for now, if I need to change more than one value, I'll do it offline, and save the small changes for emulation. And Craig, I'm not intentionally trying to create more work for you, I promise! Let me know if you want me to do anything to [try to] help.

junkcltr

iTrader: (1)

I have never had a problem updating large tables. Well, except for my early development stages. These days I can actually upload an entire bin at a time with no engine stumble. The service engine light doesn't evern flicker. The problem lies in the emulator itself. The timing is probably too short and it forces an access to the PROM while the ECM is trying to access it.
You have to remember that the commercially available emulators are in the early stages and will get better as time goes on.
BTW, I have started emulating a little bit with TunerPro V4.00 and it is working great so far.

Is it possible to add in a HIDDEN READ function to TunerPro 4.00. That is the one thing that I had with my MS-DOS software that no one seems to support. It is great for doing readbacks of the EEPROM while the engine is spinning which allows data verification. A TRACE function would be nice too. It allows you to follow the execution of your code (if write 68HC11 stuff). I know you are very busy but it would be nice to have in versions to come. Let me know if you are interested and I will PM you the details.

HaulnA$$

Sorry for the late response, I just got married Feb. 26 and I just got back into the groove after the honeymoon. Grumpy is correct. The code starts at 4000 and wants to see AA at 4008 to disable the checksum. I have been emulating with TunerProRT on 2 $0D PCM's since I got my AutoProm over a year ago or whenever they came out. I have no problems with TunerCatRT either. Both work as advertised. HTH

junkcltr

iTrader: (1)

I noticed that you are in NY. It is pretty cold there right now.
If the emulator uses any commercial grade parts (only good from +32 F to +158 F degrees) then that could be causing a problem. The timing changes at the lower and upper temperatures. It also depends on the design timing margin. Sometimes you can get away with using commercial grade parts over larger temperature ranges. Craig should be able to fill you in on that.

Did you check to see if maybe it is an EMI problem (bad spark plug wires)? Try wrapping the extension cable in tin foil to see if the errors go away. I know it sounds funny, but if that is the problem it might fix it.

stuckatcuse

Actually I had thought of the temp range problem as well, but even if I go directly from my house (70 *) to a warm car, the problem still occurs...

The spark plug wires are less than 6 months old... If emi is a probem, I'm sure it would mess up my aldl data as well, which is fine, untill I try to update the prom with a large table or update the whole prom... I'll try the foil. Thanks for the suggestions.

stuckatcuse

Congrats!!
What's your secret man??? Can you update an entire prom while the engine is running? Can you update say, your ve near idle without killing your blms...??? From your post I'd say you could. Now the question is what's different between your setup and mine...

Mangus

ALDL and the emulation header ribbon are two very different things. I'd say the ribbon is much more sensitive to interference.

With the Ostrich you can upload the entire binary image without the engine coughing. Earlier AutoProms (and maybe even current ones - Craig?) cannot do this without a hardware mod that Craig can do.

stuckatcuse

Good call! I never thought of the ribbon! (I just kept thinking of the USB cable....)

OK I'd still like to update a table. Let me just verify that if I change the mask to AA and keep the check checked, then the checksum should be disabled... Is this correct?

HaulnA$$

I can update entire tables, no problem. VE, spark, whatever. I have never tried to upload an entire 512 Kbit .bin with the engine running and I'm not sure I want to try it. If I had an older (slower) ECM and a 32 kbit .bin, I might try it but 512 kbit is a lot of data to update by sneaking it in between address cycles or however Craig does it. I would even be reluctant to try it with the Ostritch. So far I have never felt the need to update an entire .bin with the engine running. HTH

HaulnA$$

I can verify the ribbon cable interference thing. When I go on long tuning sessions and hook up my inverter to the laptop supply, it interferes with the Autoprom if it is too close to the ribbon cable. If I throw it in the back seat, all is fine. I have had the inverter right next to the PCM without the AutoProm hooked up and it seems to work fine. HTH

stuckatcuse

My inverter is in my back seat. I've noticed that it can create interference (stereo), so I just turned if off and went to battery... It did exactly the same thing... I wish I could figure out what it is. Did you do anthing crazy with your checksum... I just have the thing checked with AA to 08.... I also tried setting the mask to AA and letting it create a new checksum. Made no difference...

Think you could IM me? eclipse959
I'll summarize our chat here..
Sean

HaulnA$$

Check the "Disable checksum by uploading" box and set it to upload AA to 4008 not 08 and it should work. Do not check the "Keep running checksum" box. HTH

stuckatcuse

stuckatcuse

Thanks,
I'll give this one a try...

junkcltr

iTrader: (1)

It still could be a timing margin thing. ECMs for the same vehicle vary in terms of speed. The emulator needs to be designed to meet the worst case timing for each ECM. I came across one 730 ECM with very fast timing (hardest to emulate) with and used it as my test mule.
Craig how quickly do you get off the ECM bus before the ECM attempts a read? When doing the timing analysis don't forget to include the cable bounce.
I run my emulator with a 70ns cycle and give more than 70ns of idle/ECM address time before the ECM selects the PROM. Never had a problem with this setup. Complete bin hidden writes and reads without a hiccup.

No surprise on the stereo thing. Current spikes radiate noise which is picked up by the ribbon cable. It is a design/grounding problem. Also, bad spark wires are not ones that will not fire a cylinder properly or are old, they are ones that radiate a lot of electrical noise. Different types or cores radiate more than others. Although, notice that the TPS, MAP, etc never have this problem......it is a design thing.

No, wrapping the USB cable in tin foil will not help anything.

Why the worry of a 64kx8 (512kbit) bin?? It is only twice as large as a $8D bin which is 32kx8 (or 256kbit). I think you mixed up your terminology.

Uploading the entire bin should be fire. It is when you start making large code (not data) changes that mess up the ECM. It confuses it for a bit AND will ALWAYS be that way. It isn't an emulator thing. The code itself is messing "itself" up.

junkcltr

iTrader: (1)

What speed does the $0D ECM run at? Both the 165 and 730 and variants run at the same speed. I am surprised that this one is faster. How do you know the older ones are slower??

stuckatcuse

I'm not sure of the speed exactly, but the 16197427 controls both the engine and tranny, and has 8192 bps aldl, so I'm assuming its faster. I believe it was the last TBI ecm...

junkcltr

iTrader: (1)

I am making a guess here. Since the ALDL speed (8192) is a power of two derivative of the system clock then the ECM runs at the same speed as the 730 ECM, or it would have to run at twice as fast or four times as fast.....

This is highly unlikely. I would say the $0D ECM runs at the same speed as the 730 ECM. It doesn't take much code/time to do simple tranny control.

I think that none of the emulators are "pure emulator" is the strict sense. That is, if the ECM or any other device operates with single cycle access then the emulator is entirely locked. Note that none of the comercially available emulators state the EEPROM chip speed that they will emulate. So there is no guarantee that it will work in an application. All they same is it will emulate a 27Cxx/28Cxx device.......??? what ever that is. What is the min. read access time that they will emulate. I looked on the romulator page and the autoprom page and neither state the read access time of the device they try to emulate. For the money they should be specifying this.

stuckatcuse

Honestly, if you're an engineer, that information may be useful, but to the common joe (not that the common joe would be tuning anyway) I don't think that info would be understood. I'm not trying to knock any hardware here. I think that the autoprom is a great device, and I'm sure it will work well.

I don't really care about updating an entire prom (I thought I read that it could be done), but I do think I should be able to update an entire table. I'm sure I can... I just need to figure out what I'm doing wrong.

junkcltr

iTrader: (1)

I am not trying to knock anything either. I believe all of the products out there are useful. Just pointing out the apps were these devices are not perfect. That is, with some ECM they are not going to work. With yours it should work.

If you buy a TV you would like to know what stations it will work with right? If I bought an emulator I would like to know all of the ECMs it will work with.

I'm a common joe tuner. I think we all are. Well, except for Grumpy and Rbob. Those two are know more about all this stuff than the rest of us combined.

Craig Moates

Once you account for all of the propagation delays and hold times, notwithstanding cable effects, the AutoProm emulates down to ca. 80nS. It uses a 70nS NVRAM that is always CE enabled, with a 3nS gate feeding the OE line from the target device. The OE transition is much faster, ca. 35nS.

Write cycles are two clock cycles total. However, data latching at the data port during the write cycle ensures that no 'spurious' data shows up. So while the write cycle is non-invasive from the target device perspective, a write cycle could delay data propagation from a 'fresh' addressing request by as much as 140nS or so.

For the Ostrich, a battery-backed SRAM is used. Access times are similar, but pin capacitance is a bit less so write cycles are able to occur in a single 70nS clock cycle. Again, the actual 'offline' time is less.

Reads on both units require too much propagation time due to the buffering system used, such that 3-4 clock cycles are required. This becomes invasive with respect to emulation (causes a blip on target device operation).

Both the AutoProm and the Ostrich use a single bank of RAM. Bytes can be written one at a time if desired.

Bill Hitchcock's Prominator uses a CPLD to arbitrate the read/write/muxing of two Flash memories. In this way, it is somewhat more of a 'pure' emulator. However, entire sectors must be erased and written when a change is made. This isn't a deal killer, just takes longer if you just want to make single-byte changes.

To the guy having issues and anyone else: If you ever have issues with my stuff to where you can't get it to work like you want, I'll be glad to walk you through troubleshooting personally on the phone or via email. If we can't get it straightened out for whatever reason, an unconditional money back guarantee is always in effect. If you would like to send any hardware to me for troubleshooting or swapout, that is also totally A-OK.

Hope this helps,
-Craig

Craig Moates

That all being said, I've got my sights on a 'very' pure emulator. Called the Ostrich2, it will emulate 8mbit 16-bit memories, with full dual-bank batterybacked SRAM. The prorotype is sitting right here on my desk, just have to get around to writing the firmware (easy) and VHDL (also not that bad). It will indeed have full trace functionality, high-speed watch alerts, all kinds of cool stuff. Need to find a big box of 'spare time' to work on it. It's not really designed for the OBD1 stuff though.

Craig Moates

Oh yeah, ca. 30nS...

Mangus

Oh, man. I totally forgot that we do this in our spare time. Wow, for the money, that should be on the web site too.

Craig Moates

Come now Mr. M, be a nice guy. I know that sarcasm flows through your veins almost as thoroughly as yours truly, but I think Mr. J is a 'good' guy as Bruce always says.

junkcltr

iTrader: (1)

Interesting that you went battey backed. I decided on the same thing some time ago. Two batteries can give you a typical 140 years of data retention. EEPROM only boosts 20 years so I think that is a good thing.

Cool...dipping into VHDL. Another good choice. Stay away from that Verilog stuff. To start you might want to check out Xilinxs design software. It is pretty reliable.

You are right in the sense that a pure emulator can't be done with an MCU and only a CPLD or FPGA.... can do it. For this ECM stuff it really isn't necessary. My CPLD w/ SRAM works just as well as my ATmega8 emulator. Although, a more pure emulator would be better for ECMs to come and other apps.

I hear you with the spare time or is it missed sleep. The times you posted seem a bit strange though. If you are setup using an AVR RISC like my Atmega8 emulator then it is impossible to do reads in only 80 ns. You have to read the ECM chipselect line which takes .5 to 1.5 clock cycles. I run at 14MHz ish so my cycle time is about 70ns. I use LP SRAM that is 70ns so it works out well. Anyway, it is going to take at worst case 1.5 cycles just to see if the ECM chipselect is high or low. Then you have to see which way it is headed which is another clock cycle. Way over 80ns before the emulator read has taken place. The number don't seem to make sense. What is "ca.", never seen this before??

I am guessing it is more in the >500ns access time range. Are you only counting the ECM read access time 70 + 10 = 80 SRAM access + prop delay. This isn't the emulate access time. It is simply the read access time. The emulate time is from when the emulator senses that it can sneak in TO the time that the ECM can read data (ECM data is available)

If you do it without a MCU and with pure hardware (VHDL stuff) you will find that to get down to the 150ns range you would need a clock of at least 200MHz which is almost impossible. That is....sample CS a few times (10ns) (metastability), the out address (5ns), then read (70ns), then out ECM address (70ns). Total time 10+5+140 = 155ns.

Not sure how you figured you times but I would guess they are between 500ns = 1000ns.......much like my Atmega8 emulator. The CPLD version does down to less than 400ns.....all in an ECM clock cycle. Overall, it terms of tuning it happens so quick that there is essentially no difference between the two emulators. The CPLD using SEEPROM so it doesn't need any batteries. You might want to go with some SEEPROM on your VHDL version. It is a nice small part.

J

!6-bit emulator would be cool though. Keep up the good work.

junkcltr

iTrader: (1)

I meant no disrespect toward you. I know you work hard on this stuff and it is appreciated by everyone that uses it. TunerPro is a great program.

But the hardware: $325, shouldn't it say what it will work with. And I meant no disrespect toward Craig. I know he works hard on this stuff too.

I was just trying to explore what could be causing the problem.

junkcltr

iTrader: (1)

And was I a "good" guy when you asked me to look over your schematics for you last year and when I was telling what needed to be done to build an emulator.

I was just trying to help the guy out.

Mangus

Sure thing, good guys, all of you. I'll be the first to say that I'm not a good guy. I suck.

Naw, but really, we still have to gather the list of what it works on. Its a relatively limited community of users.

junkcltr

iTrader: (1)

I messed around with dual-banks of SRAM at one point. I found that it really wasn't necessary for the ECM stuff and actually not necessary for other apps.
The reason is that you only might need dual banks if you are making code (not data) changes. You will find that dual-buffering becomes a bad thing in one sense. What happens is that the code changes while it is executing and gets all messed up.
So you actually want the reset to occur.
Code that modifies itself has always been a bad idea and no one supports it. Take a look at the AVR bootloader stuff as an example and you will see how the memory is strictly segmented for bootloader and applications. This is to keep the app. from modifiying the bootloader.
Just something to think about. The trace functionality is a good thing. You can see how the ECM responds as different things are happening. Works nice if you write your own 68HC11 apps. If you are interested in this stuff start another thread on this. It really doesn't belong here.