Crashing at end of saving a data log

[bobxyz]

Hi, I'm working on an .adx monitor for a mid-1980's Bosch LH2.4 Jetronic ECU for a Volvo 240/740/940. It's mostly going well, but I've run into an intermittent problem when saving data logs.

After stopping logging, and typing in the log file name, TunerPro appears to write most of the data to the file but then crashes and disappears. Restarting TunerPro and Loading the log file crashes immediately.

Windows Event Viewer says:
Faulting application name: TunerPro.exe, version: 5.0.10146.0
Faulting module name: ucrtbase.dll, version: 10.0.26100.7019
Exception code: 0xc0000409 --> internet says this is a Stack Buffer Overrun
Fault offset: 0x0002da51
Faulting application path: C:\Program Files (x86)\TunerPro RT\TunerPro.exe
Faulting module path: C:\WINDOWS\System32\ucrtbase.dll

The Bosch LH2.4 ECU has a very primitive serial port debug protocol. The ECU only has 256 bytes of RAM, so a single byte is enough to address all RAM. To dump a byte of RAM, the address is sent in a single serial character and the ECU responds with a single serial character. It runs at an uncommon 187500 baud rate.

I'm using a FTDI FT232RL USB-to-serial adapter. By default, the FTDI Windows driver waits for 16ms to return each character. This is pretty pokey. To speed this up, I'm going into the Windows Advanced Port Settings and changing the default Latency Timer from 16ms to a small value, 1,2,3 or 4. 4ms/byte is ~250Hz. The important part is that the crash occurs much more often with small latency values.

I'm guessing that there's some sort of TunerPro issue where the active monitoring collides with something in the data log save code. If it matters, I'm usually viewing the dashboard gauges when the crash occurs.

I've attached a .zip file with my TunerPro files, and an example bad data log from ~5 seconds of logging with FTDI latency=3. Because the Bosch protocol is so simple, you can recreate the failure without an ECU if you have a FTDI USB-to-serial adapter. Simply tie the Tx and Rx lines of the FTDI adapter together. It will echo back the RAM address as the datavalue for every command.

Thanks,
Bob

BTW: LOG10() is broken, but LOG() is OK.

[Mangus]

Thank you very much for the details and repro files. I wish all reports started out with this much helpful info. I can reproduce the crash on XDL load, but this appears to be an issue with an incomplete log file, which lines up with your observation that it seems to be crashing when being written out after pressing stop. And the "incompleteness" is in the data that would indeed be written at that point. So I think the problem is there, but that represents a challenge for me to repro since I do not have the ability to log with this ADX.

Let me look around a bit more and see what I can find.

[bobxyz]

Thanks for the quick reply! So far, a simple work-around of disconnecting before stopping logging has prevented the crashes.

Currently, I'm gathering ~55 bytes of data for each sample set, i.e. for each Monitor Command. It looks like this results in 55 lines of log data. Is there a way to change the logging to only do one update per Monitor Command? I'm thinking this could reduce the loading, and would result in much more manageable log files.