J-series Acura/Honda

[Peter]

I said I would help those with stuff wired up. I'm somewhat over worked

I know, but I wanted to give it a reasonable attempt at doing it myself.
The biggest reason I was trying to run it off the crank and cam was this chunk of code in the missing teeth header file.
#if ((MISSING_TEETH * 4) > TOTAL_TEETH)
#error "Too many missing teeth! (or not enough total teeth!)"
#endif
I thought maybe you knew that it wasn't going to work or something.

If I use the newest version from your git repo, it won't build. I'll attach a copy of the output. I haven't touched anything in the source code to get that output. Commit 7b42cfb builds just fine, so that's what I'm using. I can't seem to get MTX to talk to the ecu. It gives me:
Prompting user for ECU family to interrogate...
Command "c" (MS-II Clock), returned 4096 bytes
Command "A" (MS-I Runtime Vars), returned 4096 bytes
Firmware NOT DETECTED, Enable Interrogation debugging, retry interrogation,
close megatunix, and send ~/MTXlog.txt to the author for analysis with a note
describing which firmware you are attempting to talk to.

With a serial terminal set at 115200, 8bit, no parity, 1 stop bit, and no flow control it spews out the crap, and makes my computer beep.

I'm not too worried about it at this point, because this computer has always done funny things. The clock is generally about 10min slow for every twelve hours since it got the the current time from the internet. So I'll try and find another computer to play with tonight, and report back. But if you have any good ideas I'll take them.

[Fred]

That was arbitrary, comment it out and give it a shot, if you have success I'll remove the check. Sorry about that oversight...

Re the MTX stuff, you're trying to interrogate a MegaSquirt and getting flooded with FreeEMS datalogs. I thought about this for a second and realised that you're using the old 0.9.23 release version which has absolutely no FreeEMS support. You need to beg Dave for an up to date Windows version.

If you set the terminal to odd parity instead of no parity, and record the crap that it spews out, you should be able to view it in OLV on windows. If you can document how to record a stream like that on windows, which app to use, how to configure it, how to do the recording, that would be very useful!

I hope this helps a little! :-)

Fred.

[Peter]

Logging a .bin file in Windows for OLV.
The first thing I did was right click on My Computer, and go down to properties. Then in XP I believe you have to click the Hardware tab, and then Device Manager. In Vista and 7 Device Manager on the left side of the window with a little shield next to it. Then you want to find Ports(COM & LPT), and click on the little triangle expantion arrow next to it. This should show which COM ports are available on your computer. If the port is part of your computer you will just have to try and access them in Tera Term, and see if you're on the right port. If it's a usb adapter like mine you can unplug it to see which port disappears. Tera Term only supports COM 1, 2 ,3, and 4 so if it installs on COM5 like mine did the first you have to right click on the port, and go to properties. Then the Port Settings tab, Advanced, and then you can select the COM port number. I'm using Tera Term Pro vr2.3. Open TeraTerm, click on setup, and go down to Serial Port... From there you can select the Port your computer is using. Baud rate: 115200, Data: 8bit, Parity: odd, Stop: 1bit, Flow control: none. Then click Setup go down to save setup, and then it won't reset all the parameters every time you reopen it. Now that strange looking symbols are scrolling through the screen you should click File, Log..., get to the directory you want to save the log in, and then type in "yourLogsNameHere".bin the .bin being the semi important part. Then once you're done capturing that log you can open OpenLogViewer mine is vr0.0.2. Then File, Open, yourLogsNameHere.bin, Open.

I'm not seeing much of anything in the OLV. Mr. Max99 is sending a good signal to PT0 according to my oscilloscope.

[Fred]

To me it looks as though you had the parity wrong:

EscapePairMismatches: 53 Incremented when an escape is found but not followed by an escapee
ChecksumMismatches: 11687 Incremented when calculated checksum did not match the received one
PacketLengthWrong: 39 The length should match the ID passed in, if not, fail.
PayloadIDWrong: 39 Requests to parse packet as A when packet was of type B.

And the clincher:

PacketsParsedFully: 0 Number of packets that matched all requirements and got into the log.

Start OLV from a terminal and look at the output yourself if you want. Usually if the parity is wrong, the packets all fail, just like this. I can't tell you much more than that without a readable log. There could be other reasons including, but not limited to, a dodgy serial adapter or port.

Fred.

[Fred]

Maybe try this: http://realterm.sourceforge.net/ could be worth a look :-)

[Peter]

I've tried it on two older computers with built in COM ports, and 2 different USB to Serial Adapters on my normal computer. RealTerm reports an Error when I first start it up, and then if I hit the reset button on the TA board the Error message goes away. The logs from Realterm look just like the ones from TeraTerm in OLV. I've been using the MTXloader to load the .s19. I couldn't figure out how to get the Freeems-loader working, and I've also tried the uBug12x, but it seems like I remember reading something about it not being up to snuff. I've tried updating the SerialMonitor with the BDM to vr. 2.3, and back to 2.2 with no real change. I've also tried 115200 and 9600 Baud rates. I've rechecked all my wiring, and pulled everything except the Max99 chip off the board. I'm pretty much out of ideas.
What's the difference between .gc.s19 and .s19 firmware files?

[Fred]

gc = garbage collected, i take it you're running make all, don't bother most of the time, make s19 is sufficient and wont generate those.

That's weird! I have no idea why it would end up corrupted like that if your settings were right and your hardware bug free.

Possibilities seem like:

All four of your serial ports are buggy
All two of your software packages are buggy
You've somehow mis-configured the port without realising it

In terms of loading and reloading, I'd prefer you pulled the image back off of the board to verify it. In fact, please send me a firmware file that you've tried or build one, try it, and send it, and I'll verify that I can talk to it here. And/or I can build you one here and send it to you.

You are using the latest code, right? I don't know what else to say. I suspect we'll have a "Ohhhh" moment soon, though :-)

Fred.

[Fred]

Does it receive your commands? Can you send it a stop logging packet and watch the stream stop? See the lib dir and look for 0x00 and OFF in the file name.

[Peter]

All four of your serial ports are buggy
All two of your software packages are buggy
You've somehow mis-configured the port without realising it

I suppose it's all possible, but I hope my luck's not that bad. I disabled some kind of a FIFO buffer in Windows this morning, and that didn't seem to help.
I setup the toolchain in Ubuntu this morning, and built the firmware there, but it's giving the same sort of stuff. When I send it the 0x00 OFF file it stops streaming, and every time I resend the file with it stopped RealTerm shows the same six Ascii characters. If I send it the other file in that folder 0x01 Basic it starts streaming again.

I suspect we'll have a "Ohhhh" moment soon, though

That'd be nice.

[Fred]

OK, so that proves that the data stream TO the device is fairly clean and that your settings are correct, or you're very lucky. This is a good start. It could be that those two apps both don't handle parity correctly. This is actually possible. I helped a library author diagnose and fix his code with EXACTLY this fault a while back. IE, I could send fine, but receive was all corrupted.

What I'd suggest is that you build the firmware with no and odd parity by changing line 656 of init.c to the values listed just above it. See if you can get a clean log with even parity first. If not, then try none, there should be enough checking present in the firmware without the parity working, though I'd prefer you used parity anyway.

If that works for you, then you can try MegaTunix in Ubuntu and edit the config for FreeEMS to the correct parity style to match your custom firmware, and of course, post a log :-)

Let me know how you get on with that and if not well, I'll try your file, though I suspect that it's pointless right now.

Fred.