Help with MPTune

[vipernbox]

having the same problem... I have the SCI cable with board on end... probably bought some time ago...

HELP!!!

[ShelGame]

having the same problem... I have the SCI cable with board on end... probably bought some time ago...

HELP!!!

What does it do exactly?

[vipernbox]

I go to Misc... Read..

Prompts me to do the bootstrap process within 5 seconds after hitting OK...

Hit Ok.. Push the momentary switch.. Turn the key... release momentary..

instantly a little message pops up with something about baud rate.. Just numbers...

hit Ok...

Then I get the pretty much the message described in first post of this thread..

"Unable to download entire boot program for ftdi coms. Only 0 were downloaded. Please turn off key and restart the process."



I can take screen shots if needed?

[motorhead153]

Mine is going exactly the same thing

[ShelGame]

I go to Misc... Read..

Prompts me to do the bootstrap process within 5 seconds after hitting OK...

Hit Ok.. Push the momentary switch.. Turn the key... release momentary..

instantly a little message pops up with something about baud rate.. Just numbers...

hit Ok...

Then I get the pretty much the message described in first post of this thread..

"Unable to download entire boot program for ftdi coms. Only 0 were downloaded. Please turn off key and restart the process."



I can take screen shots if needed?

Where are you getting the 12v for the pushbutton?

[vipernbox]

Direct from Battery...

[wowzer]

what version of mptune are you running? i don't think there should be any message about baud rate!! give me a screeen shot. i just tried a flash with my ftdi cable and smec and it worked. the version should be 2.0.4.0.

[vipernbox]

Yep... 2.0.4.0.


and it is totally possible... and very likely I have something screwed up.. or doing something wrong.. I just don't know enough to know what it is...


We select misc... Read... this pops up...






Then hit Ok... .... Hit the 12volts button.. Flip the key on.. Release button... This pops up near instantly.. The last few numbers are not always the same..







Hit Ok.. and this pops up...









Sorry about the pix... Some idiot just dropped his phone in a tub of oil... Again... Geez....

[ShelGame]

I get a similar message occasionally, but if I try it a 2nd time, it usually works.

Morris, my impression is that MPT is trying to DL too quickly when this happens. Like it doesn't pause enough for the button to be released. Only a problem for the SBEC where you have to release the button before com's can happen...

[wowzer]

OK. I'll look at it later today. We got over 26 inches of snow yesterday so will be digging out today - and its only the first part of Oct. Gonna be a long winter

[ShelGame]

On your com port settings, what bin size do you have selected?

I was just trying to read a SBEC, and had the same message pop-up 5 times in a row - until I realized I had it set to read a 59.5k bin. I changed it back to 32k and it read just fine...

[vipernbox]

I tried that... The menus are a bit different than the instructions on your site.. but it was all there.. and I have tried setting them every way I could think of..

[wowzer]

vipernbox - look in the mptune program directory for a file called mpt2boot.txt. this logs the activity when trying to flash/read a chip. if you don't have the file go into the program settings and make sure "Log FTDI Port Activity" is set to true. once you do that and try to flash the chip it should create the file mentioned. post up the file text so rob/I can see what it says.

the message indicates that only 1 byte came back from the ecu after the boot program was downloaded. it should report that all 255+ bytes came back. so hopefully the log file will give us more info.

[vipernbox]

Tried the same way I have been....



There wasn't the txt file in the directory.. So I followed instructions.. changed the Log FTDI port activity to 'true'

got this...

Everything went the same...




Changed the "high speed rate" to 125000... (this made no difference before) and tried to be super fast releasing the 12volts with the key...

Didn't get the first message... but still got the "didn't download boot program' and the mpt2boot file showed this..

[ShelGame]

Try setting the hi speed rate to 62500. I don't always have good luck at 125k....

[wowzer]

Nothing is coming back from the ecu when the boot program is downloaded. It should send back all the boot bytes. All you are getting is the switch on byte. It's acts like the ftdi cable is not working correctly. Have you tried switching the tx/Rx lines?

Edit....
Oops. Just saw the second screen shot. Definitely getting the boot program back correctly. I'll look again at the code to see what else could be going on. Did you change anything between the first and second screen shots other than the baud rate?

[vipernbox]

Just maybe released the 12v button quicker... That was the first time it hadn't displayed the baud rate massage though...

just tried it with all baud rates and same deal...


I haven't tried switching Tx/Rx lines.. the cable is one I bought from Rob some time ago..

[wowzer]

here is what a successful log should look like (its just the first part). post up again the message you get when it works like the second time. does it say "Boot program download failed. Corrupted bootprogram." or does it say "Unable to download entire boot program for serial coms."? if its the first one then the boot program that is being read back from the ecu does not match up with what was sent to the ecu for some reason.

-BootSerial routine-(Called from StdBinWrite)
Using Boot Program MPTune Smec/Sbec Bootloader ver2040
got ecu acknowledgement byte - 0 at 13:51:36.8514958
total bytes returned on switch-on were 1
boot download routine is started.
boot baudrate = 7812
hi speed rate = 62500
sent FF byte
sending boot program. length = 256
Boot send start time 13:51:38.8638993
Boot send finish time 13:51:39.4099003
Boot reread finish time 13:51:39.4099003
done sending boot program. bytes returned = 255
read timeout set to 328
bytes returned were:
8E 10 22 CE 10 00 CC 01 0C A7 2B E7 2D 0F CC 60 01 A7 3C E7 3F B6 10 2E 84 20 27 F9 8D 02 20 F5 F6 10 2F 53 8D 1E 20 27 8D 08 8F 8D 05 17 8D 02 8F 39 8D 06 27 FC F6 10 2F 39 F6 10 2E C5 0A 26 BF C4 20 39 37 F6 10 2E 2A FB 33 F7 10 2F 39 C1 EE 26 0A 8D D3 E6 00 8D EB 08 26 F9 39 C1 AE 26 35 8D C5 17 8D CC 8D 5D 20 02 8D 0D E7 00 4A 26 02 8D 13 08 4D 26 F3 09 39 36 17 09 A7 00 08 8D B9 27 F8 32 20 B0 36 A6 00 37 C4 80 84 80 11 33 26 F5 E6 00 32 39 C1 CE 26 2A CE B6 00 86 06 B7 10 3B E7 00 7C 10 3B CE 0D 06 09 26 FD 7A 10 3B 7F 10 3B CE B6 00 E6 00 C1 FF 26 06 08 8C B8 00 26 F4 8D 80 39 36 86 AA B7 D5 55 86 55 B7 AA AA 86 A0 B7 D5 55 32 39 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
left over bytes after boot prog was sent were 1
left over bytes were FF
boot program loaded and baud rate is now set to 62500
writing data to chip using 'StdBinWrite' routine
using high resolution timer class
read timeout set to 50 mSecs to handle write block size of 64

send cmd 51 to write bytes at 13:51:39.7843010 (0)
write cmd confirmation returned 1 bytes at 13:51:39.7843010 (5)
write byte confirmation byte was AE
send cmd to write 64 bytes at address 8000 at 13:51:39.7843010 (5)
sending 64 bytes

- - - Updated - - -

hold on - i just noticed on your second picture that when you send the 0xff byte which is suppose to set the baud rate on the ecu to 7812 that it returns a 0xff byte. if i remember the ecu is suppose to "eat" this byte, ie. not return anything. i wonder if the chip could be write protected some how.

Rob - do you recall having this issue when we were testing the sbec stuff. seems like we were dealing with a security issue on certain chips. i'ld be curious what your log shows, i.e. if it shows a 0xff coming back.

you still may want to try switching the tx/rx lines once and see what that does. also, as rob stated, 125k baud can be unreliable. however, you have not gotten that far yet.

[ShelGame]

Just maybe released the 12v button quicker... That was the first time it hadn't displayed the baud rate massage though...

just tried it with all baud rates and same deal...


I haven't tried switching Tx/Rx lines.. the cable is one I bought from Rob some time ago..

Can you take a pic of the rear of the board on the end of the cable? I just want to make sure it's not a 'Series 1' board.

- - - Updated - - -

hold on - i just noticed on your second picture that when you send the 0xff byte which is suppose to set the baud rate on the ecu to 7812 that it returns a 0xff byte. if i remember the ecu is suppose to "eat" this byte, ie. not return anything. i wonder if the chip could be write protected some how.

Rob - do you recall having this issue when we were testing the sbec stuff. seems like we were dealing with a security issue on certain chips. i'ld be curious what your log shows, i.e. if it shows a 0xff coming back.

you still may want to try switching the tx/rx lines once and see what that does. also, as rob stated, 125k baud can be unreliable. however, you have not gotten that far yet.

If it's one of my boards, he can't swap the wires; they're soldered in place.

I thought we fixed the security issue, though, with release 2.0.4.0? The current boot program should dis-able the security before writing, and re-enable it when done.

[wowzer]

...

I thought we fixed the security issue, though, with release 2.0.4.0? The current boot program should dis-able the security before writing, and re-enable it when done.

we did when we actually flash the chip. what i'm talking about is the initial 0xff that is sent. i thought we struggled with that initially - either it was some type of security thing from the factory or a baud rate issue. i can't remember. i just don't think the smec/sbec boot program echos back the initial 0xff. it's used to set the ecu baud from 1200 to 7812. the fact that it is echo'd back seems like the ecu is just kicking it back. maybe it was with the fcc chip we were having this happen. can't remember.

- - - Updated - - -

rob - when you just tested the sbec did the boot log file show the 0xff coming back, or was it like the log i posted from my smec?

vipernbox and motorhead53 - are you reading a smec or sbec?