Interrogation Routine

Aaron Barnes' wxPython based FreeEMS tuning tool. No longer maintained and out of date with the protocol requirements.
Post Reply
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Interrogation Routine

Post by Fred »

I spoke with Aaron about this the other night. This is an extension of that conversation as I've realised today that it would be quite nice to ensure we didn't corrupt the flash memory by inadvertently controlling the serial monitor with random data.

The discussion on the phone went something like this :
If you want to support MS as well as FreeEMS then the interrogation routine will need to attempt to query the MS device first. The reason for this is that the communications on the FreeEMS are robust and can not cause corruption when receiving random data. The reverse is not true and a packet for FreeEMS could very easily cause corruption of a MegaSquirt box.
The extension is that there is more than just MS and FreeEMS to think about! I hadn't realised this when we spoke the other night. The third player is the Serial Monitor!

Variables :

Serial Port Setup
Data Sent To Find Out About The Device

MS and SM share the same serial port config : 8 data, 1 stop, NO parity, 115200 (for ms2, forget ms1...)
FreeEMS uses the following : 8 data, 1 stop, ODD parity, 115200

Nothing you can send to either SM or MS can harm the FreeEMS, so the only thing to consider then is what will happen if you MS query the SM and what will happen if you SM query the MS.

The details of how to talk to the SM are available in FreeScale AN2548 :

http://www.freescale.com/files/microcon ... AN2548.pdf

and the details of the MS comms "protocol" are here (copy paste the link...) :

http://www.megamanual.com/ms2/code.htm near the bottom

Having thought about this for a second more, the answer is obvious :

Query for MS2 - If found, load appropriate code/config etc
Query for SM - If found, ask user for next step (load code (not yet, but...), flick switch and send reset, close, offline, etc...)
Query for FreeEMS - If found, load appropriate code/config etc, if not, go offline or close at the users discretion.

Reason being, the SM will also ignore all data until it has initiated comms by receiving a 0x0D character and sent back a prompt sequence and the query for MS2 is just a single Q or S char :
'Q' and 'S' commands (both caps) are used to retrieve two indicators of the MS-II code version. The first is the 20-byte ASCII string for the Rev Number of the code version, the second is for a 32-byte Signature string. The latter is changed in the code whenever a new feature is added, the first is changed in the code whenever there has been an input parameter or output variable added.
Actually, I guess it doesn't matter, except that FreeEMS should come last.

I believe MS1 was even more primitive and it is probably queried using some action command that confirms it is alive and normal by performing that action.

I got thinking about this because I want a Big Yellow Button ;-)

http://issues.freeems.org/view.php?id=58

But implementing that is different to the other two colours in that the serial settings are different and it doesn't use a packet etc...

I would like to be able to reset the device into the firmware out of the serial monitor.

To achieve this you will need to bypass the comms wrapper and write to the serial port directly after changing the configuration of it.

I imagine the sequence would go something like :

disconnect serial
change to no parity, 8 bits, 1 stop, 115200bps
reconnect serial
initiate comms with SM : send [0x0D] receive [0xE0 0x08 '>']
send reset command : B4
disconnect serial
reconfigure with parity = odd, 8 bits, 1 stop, 115200bps
reconnect serial

With the red/orange and yellow buttons I can then move between SM and FreeEMS modes quite easily :-)

Before trying to implement it I think Ben and Aaron should have a chat about the best way to approach interrogation and perhaps implement that part of the setup such that it can be hooked up to various devices safely and take care of the nuances of each.

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Interrogation Routine

Post by Fred »

I've just successfully completed the sequence of swapping back and forward by connecting with cutecom to reset the SM with two hand rolled packets and then disconnecting, connecting with FreeEMS-Tuner and reset it back again with the hard reset red button.

I also raised a new issue for this :

http://issues.freeems.org/view.php?id=59

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
dandruczyk
LQFP112 - Up with the play
Posts: 100
Joined: Sun Apr 06, 2008 6:30 pm

Re: Interrogation Routine

Post by dandruczyk »

The interrogation is NOT a problem. Mtx now prompts for a ecu personality on startup before it even opens the serial port and that determines things like baud/serial config as well as the interrogation routine used. (the interrogation routine is ECU specific and thus being pulled into a plugin. Since I don't have any real specifics on HOW to interrogate a freeEMS that routine for that ecu is unwritten as of now.
Post Reply