Nistune Forums

also DIP versions (what you currently have) are being phased out by Simtek. All future boards will use SMD based 11C88 chips. I have three tubes of these devices now, just waiting for boards to arrive in a few weeks

spent just about the whole day doing protection code for the NVRAM seems to work fine now

also updated nistune messages. should have something out soon

need to get that innovate working still also

I think I figured out my nvram burning issue. It appears that when I do the A-B address copy the willem software doesnt like to actually burn anything past 4000h. If I do the copy, save the 32k file, open the new file, and then burn the chip, everything seems to work perfectly. Strange. This is with version .98D5 that came with the burner. I also tried a 47uF 63v capacitor and it burned fine.

Now that I can burn the chip i'll see if I can test the 2000h rewrite issue sometime this weekend.

Looking forward to some new releases.

ahah that explains why my willem wasn't working properly. its because when you load a 16K image it thinks when it programs to do 16K

even when you do a copy/paste although in the buffer and it looks like 32K.... its still internally 16K and burns that size. its a bug with the programmer.

not suprising... the willem programmer software is so poorly written and buggy. i have source code for an older version and it is terrible to modify


anyway i took the NVRAM out of my r31 tonight and also get the 0x2000 set from 0x26 to 0x00.... this is with the rev2 patch code tooo.... also checked bernards image and same thing.....

i also found from doing some testing that the STK15C88 can do an AUTOSTORE by itself to EEPROM on dodgy power glitches. the STK15C88 is meant to be protected from brown outs but does an AUTOSTORE attempt if enough capacitance in circuit. this gets screwed over during this test and the chip ends up corrupt (see attachment). consequently i will prefer not to be using this chip any longer on these boards.

to set the address 0x2000 requires address line A13 (2^14=0x2000) to be high during a write (/WE low and /CE low). this could be caused by floating lines on powerdown.

so if address line A13 is high during power down, and data lines are low, and the NVRAM does an AUTOSTORE it is possible that this hardware combination is writing '00' to A13 in this circumstance

i am currently running the STK15C88 also. the only thing i have changed was K constant and did a STORE after that. so the software hasn't specifically written to this address.

after re-reading the datasheets for these chips, all our boards require a modification. at the minimum, /WE line should be tied to VCC via a 10K resistor

Bryant and Bernard, can you please put a 10K resistor between either
(a) pins 27 and 28 of the EPROM socket
(b) pins 1,2 of the second header connector (X4)

Best to use a 10K surface mount resistor, which may be available over there from local electronics shops. the part i get is below. 0805 or 1206 are the sizes, our board size is 1206 (larger size, easier to solder)
http://www.altronics.com.au/index.asp?a ... m&id=R8188

once installed, let me know if 0x2000 still erases, i'm going to update my boards here and keep using the STK15C88 with my developmental code (patch rev 4) and see if it does it

by the way the STK11C88s dont do AUTOSTORE on powerdown so the above issue shouldn't be a problem, however i have noticed there has been corruption sometimes on powerup, which the resistor modifications will fix

I dont know of anyplace local that has surface mount components. Is there any problem with using a normal variety pack type with the leads?

this pic btw also shows C22 i was mentioning needed the extra (black) capacitor shown, soldered over the top of the old one. that is for rev1 boards only since rev2 ones ive done this mod already

you can use a normal 10K resistor if local places dont stock them just easier to fit the SMD ones to this boards

specialist electronics shops (ones which sell just compoennts) normally have them. we have several in adelaide that stock them (and this is a small place)

Matt,
Did the 10k resistor on pin 27 and 28. 2000h still goes to 00 as soon as I do a burn it seems. I havent done the capacitor for the disconnect issue. Would that matter?

damn. okay i'll keep looking into it

the cap wont make any difference to this problem

found and fixed. patch code writing to address 0xe000 during STORE(which maps to 0xa000 when A14 is not used)

also fixed up the STORE code further by sending correct verification success byte and nistune will pop up a dialog box to indicate store is complete

also the Z31 address files need an update. the patch code is moving to consult address 3300 (B300) because jasons ECU code is larger than other ones and i needed to account for this

early Z31 ecus also only have 256 bytes of onboard ram. hence the consult reconcile/download buffer size is changing from 128 to 64 bytes. this will make things a little slower but not much

bryant - with the 28 pin socket. you have to solder to the pins of the socket where the NVRAM plugs in. not to the pins that plug into the ecu

the best access point is still on the header connector

I put the resistor on the underside of the nistune board where the eprom socket pins come through to the bottom. It sits inside the pins that go to the ecu. I'll post a pic if that doesnt sound right.

Glad to hear you got the problem figured out.

On a side note. You mentioned something about Jasons file being larger. Is he using the JWT base code? I tried the jwt code I had you patch and it spit out " Found invalid RAM address during USB init BF0B." Does that hvae anything to do with it or is that a separate issue.

it could well be. if the code infringes on the CONSULT value in the address file it will not work.

the CONSULT value is the start of the patch tables+code in the ROM/NVRAM. if the ecu has rom code/maps here it will be corrupted

i have finally finished testing a 1984 Z31 NVRAM ecu for someone. that is going to be shipped back. i have a whopping 32 bytes of free RAM on this ecu to use with the buffering on USB. it all works now, no NVRAM corruption or accidental write problems from what i can see