J-series Acura/Honda

[DeuceEFI]

[I didn't verify this specific load, but I don't think I've ever had a good load using the BDM as a power supply. I feel like I might have the wrong version just because it isn't saying anything about verifying the burn.

I've not had any luck using the BDM for the power supply while using the serial port either. My solution was to use the power fly-lead directly to the TA board when using the serial port or only using the BDM to supply power to use with the Freescale HiWave debugger to flash the Serial Monitor. I have seen the same issues with MTX and SeanK's FreeEMS-Loader when using the BDM cable from my TBDML board to power both my TA board and my prototype board.

[DeuceEFI]

I think the problem is using the BDM to power the MCU rather than the fly-lead, check the schematic, there should be a 10k resistor between the MODC/BKGD pin and +5v
and since the BDM applies +5v directly to the MODC/BKGD pin this could be the cause of the corrupted load.

Let me know if I'm way off base

[Fred]

Peter, do a build and install with autogen.sh first and then run megatunix from the command line and look at the hash in the title and you'll know which version you're using. Note if you don't run autogen that version could be older than the real thing.

git log | head

will tell you which version you're on too.

Try hcs12mem and the dump script in the firmware to pull what's inside out and use kdiff3 to compare with what you loaded - then you'll know if the flash image is dodgy.

Otherwise maybe your bdm powered burns are OK and just testing it with BDM is a fail? IE, can you burn bdm powered and then power properly and get success?

Deuce, he's using BDM power to try to test the verify function by (hopefully) getting a bad burn on purpose :-)

Fred

[DeuceEFI]

Ahhh, ok, sorry to interrupt.

[Fred]

No problem, it's good info! :-)

[Peter]

Ahhh, ok, sorry to interrupt.

No worries, you're probably right. Fred made a comment to me on skype about wondering if it powered up all the correct pins.

user@Com:~$ cd '/home/user/MegaTunix'
user@Com:~/MegaTunix$ git log | head
commit 5eda8270cc56493cb37d242fd9f1ddbc7f4d764b
Author: David Andruczyk <dandruczyk@gmail.com>
Date: Sat Feb 11 18:45:10 2012 -0500

Enabled S12x verify by default (hardcoded on). Don't send S0 records...

commit f19367f59179389383c17b6877a28c4474565e36
Author: David Andruczyk <dandruczyk@gmail.com>
Date: Wed Feb 1 20:57:19 2012 -0500

user@Com:~/MegaTunix$

Looks like the right one to me.

There must be something really strange going on here, because uBug12x gave me a good verification. So I tested it against the s19 that didn't have the updated cam timing in it, and it failed. So it must be flashing the memory correctly, but locking it out of the I/O pins somehow? I feel like I'm fucking up the test, but when the benchtest doesn't give me any outputs I still have the same problem as before.

[Fred]

As long as you're doing the test with it powered properly then it should be fine.

[Fred]

Peter, git pull and try again, Dave has improved the output a lot so it should be obvious now :-)

[Peter]

It shows 0 errors just like uBug12x did. It kinda acts like the pins get put in a pull up mode rather than a pull down, but I don't know whats going on.

[Fred]

Are you fully powering down and repowering properly to test these "bad burns" ? If not, it could get in a bad state and then not get out of it with a simple reset. Or if you leave it powered the whole time it could just still be incapable of working while powered that way. Make sense?