elan scan drivers

[RonR]

Matt, what were the FTDI driver advanced settings for your test?

Trevor's Windows 11 and my Windows 10 were unable to get more than a few packets through to ES with the recommended 1ms latency timer, and we got loads of errors with the default 16ms.

I was also wrong - I've found new monitoring software that can get deeper into the USB and Serial requests and data streams, and what I thought was a duplication was in fact the first byte of the ECU's reply. I need to do some more tests to be sure, but I think I've found exactly where the problem lies. If I'm right, your idea of a "Shim" program might just fix it!

I'll try to gather some evidence over the next few days...

[matts1972]

Hi Ron,
My FTDI driver is version 2.12.28.0 and ES is beta 0.10.12.72.
The interface hardware is VID 0403 PID 6001.
All settings default.
Best regards
Matt

[chrism]

"My FTDI driver is version 2.12.28.0 and ES is beta 0.10.12.72."

Matts + Simon_P I have just configured my win10 Pro fresh load l/top (which has now self-updated to ver 22H2) with copies of these same versions and will try them with usb EScan tomorrow, if possible, and report back.

My original 'lumpy' ES version wasn't as fully updated as this....and I found this beta version was prohibited when I've tried to load it in the past - but I was able to track it down successfully today.

[Simon_P]

I tried ES again today a few no replies - I checked the latency which was set to 32 from an earlier experiment (just stabbing in the dark no theories!), so I set it to default and then latency 1 and rebooted. Lots of "no reply " so I set latency to 16 which reduced the "no reply" will post settings tomorrow.

[chrism]

log5.zip

Screenshot (1a).jpg

Yep, like Simon_P I got the same old rubbish from usb EScan this morning using Matts' downloads

[RonR]

Marathon Post Alert!

3 flowcharts and an explanation: Flowchart 1 is the "Echo" process, 2 is the ECU ALDL Header process, 3 is the ALDL Data itself.
These have been compiled from studying Serial and USB traces using USB2 and USB3 in a Windows 10 20H2 VM, I get the same results with Hardware based tests, but it's easier to reconfigure VMs!
Edit: I've not included the various time-out and comms-error settings in the flowcharts as they didn't affect my tests, and my Flowcharting software has a limit on number of elements on a page.

ES Flowchart 1.jpg

ES Flowchart 2.jpg

ES Flowchart 3.jpg

Elanscan sends a command to the ECU to request the ALDL Data: 4 Bytes, 0x'F4 56 01 B5'
The Elanscan cable reflects the command back to Elanscan while it's sent to the ECU: 4 Bytes, 0x'F4 56 01 B5'
ES waits until 4 characters arrive by calling Get-Comm-Status, which returns the Receive(RX) Buffer size.
If ES doesn't receive those 4 bytes back intact, a "Bad Echo" message is placed in the Error Log and we start the process again.

The next 2 characters to be processed will be 0x'F4 95' from the ECU, which identify the start of the ALDL data packet.

ES waits for the next character to be received, then reads the character and verifies it as 'F4'
ES requests the number of characters waiting to be read (RX Buffer size).
If there's a character waiting it's read in, verified as 0x'95', and ES continues to read the rest of the ALDL packet.
However, if the RX-Buffer-size = 0 ES sits waiting but hasn't set the "Wait Mask" to trigger it back into life when the character arrives!
So: ES assumes that the second character 0x'95' will be sitting in the buffer ready to be read, even if it hasn't arrived yet!
After the aquisition period expires, ES clears the receive buffer (which by now contains our ALDL packet) without reading it in, and starts at the top again.

Here's where the difference between USB2 and USB3 comes in (on my Laptop, anyway):

For USB2, the wait for characters to arrive in the RX Buffer seems to trigger every few bytes, normally 3-4, even with a 1ms Latency timer.
For USB3, the wait is triggered for every character with a 1ms Latency timer, but can be made to incorporate more characters by increasing the timer.

From what I've seen, as long as the 0x'F4 95' sequence arrives together ES will be happy, but if the 0x'F4' is read and the 0x'95' isn't in the RX Buffer we lose the ALDL Data.
So - it looks like a combination of a small bug in ES (which would never have been triggered when it was written) and the USB2 & USB3 drivers behaving differently that are causing us problems.

I won't clog up LEC by posting the traces here, but I'll gladly send them via Email if anyone would like to check my logic!

Caveat: This might not be the only problem affecting ES, it's just the one I've found so far!

[matts1972]

log5.zip

Screenshot (1a).jpg

Yep, like Simon_P I got the same old rubbish from usb EScan this morning using Matts' downloads

How many errors are there? If it is one every second then 90% of the packets still get through. This is more than enough to work with. You would not even notice, if ES did not show you the errors.

[matts1972]

Caveat: This might not be the only problem affecting ES, it's just the one I've found so far!

So maybe I was only half wrong

[chrism]

You know that's an incredibly detailed explanation, Ron, especially when you mention that 'back in the day' when ES code was originally written there was no idea of these future problems. (It's rather like pollution affecting us by the process of industrial revolution/iron+steel/liquid hydrocarbons etc. Hindsight is everywhere...)

There's never an easy answer and I suppose in the case of EScan - as in any other 'heritage' - we just have to suck it up and put up with its error log complaints as it ages gracefully and pales. At least we're getting enough to work with

I reckon that now we have more options we can enjoy what we have left without losing it. And if it can be restored 'back to factory' somehow then so much the better.

Yes please: I don't pretend to understand software but if there's more detail that you're happy to explain in that manner then I'm up for it

Thanks for that

[matts1972]

So - it looks like a combination of a small bug in ES (which would never have been triggered when it was written) and the USB2 & USB3 drivers behaving differently that are causing us problems.

Perfect analysis by Ron.

My script fixes the issue, please find it attached in a zip-file.

You first will need to install "com0com" - however not its latest version 3, which is broken. Install version 2 from here: https://sourceforge.net/projects/com0com/files/com0com/2.2.2.0/com0com-2.2.2.0-x64-fre-signed.zip/download

Run the setup command and select "Launch Setup Command Prompt".

You will now have two virtual and linked COM-ports.

In the setup command prompt, list your two devices with "list", it will show something like this:

Code: Select all

command> list
       CNCA0 PortName=-
       CNCB0 PortName=-

Change this two ports to COM-port names that are available on your system, e.g. COM15 and COM16:

Code: Select all

change CNCA0 PortName=COM15
change CNCB0 PortName=COM16

"list" will now show the ports with proper names that can be used by Elanscan:

Code: Select all

command> list
       CNCA0 PortName=COM15
       CNCB0 PortName=COM16

Now run my powershell script with "right-click->run".

The script will ask for the COM-port number of your USB-Interface. Mine is attached to COM7, so I enter "7".

The script will now ask for one of the COM-port numbers of the newly created virtual ports, I enter "16".

Now run Elanscan and point it to the other virtual COM-port (in my case COM15).

Elanscan should now work without errors.

Cheers,

Matt

PS: unpolished as always - until someone comes up with a better solution

[RonR]

Well done Matt, the script works a treat!

I tried it on Windows 10 22H2 with an ES cable on a USB3 port with the Latency timer set to 1ms and I didn't see any errors at all - It would never have worked without your script! Once I'd seen the data scrolling by in the console window I removed the display code so the script now runs silently on my Laptop - I've attached it here.

elanscanfix2.zip

For those not Tech-Savvy - to stop the script click on the window it's running in and hit Ctrl-C.

Coincidentally I used Com0Com in my unsuccessful attempt to get a serial solution working over Bluetooth BLE, but I used Version 3 - I now wonder if it would have worked with version 2?

[chrism]

This is brilliant, I can't wait to try this...

EDIT: Actually no; I've set my win10 l/top up now to use Ken's bluetooth unit, but I'm really glad that this piece of our heritage hasn't been allowed to fade away and that usb EScan can be 'complete' again for leaded adaptor use.

Now folks...will usb users have to adapt to adding the 'patch' - or can the code be written into a new version of EScan?

[matts1972]

Well done Matt, the script works a treat!

I tried it on Windows 10 22H2 with an ES cable on a USB3 port with the Latency timer set to 1ms and I didn't see any errors at all - It would never have worked without your script! Once I'd seen the data scrolling by in the console window I removed the display code so the script now runs silently on my Laptop - I've attached it here.

elanscanfix2.zip

For those not Tech-Savvy - to stop the script click on the window it's running in and hit Ctrl-C.

Coincidentally I used Com0Com in my unsuccessful attempt to get a serial solution working over Bluetooth BLE, but I used Version 3 - I now wonder if it would have worked with version 2?

This script works because your analysis was correct. When there is new data in the buffer, the script waits 5 milliseconds to make sure the buffer fills with more bytes. So ES cannot run into a situation where it pulls the problematic single byte from the buffer. It is really valuable that we know now where the original problem lies and how to fix it.

[RonR]

As a matter of interest I tried Matt's script with my other USB-to-Serial adapters which can be configured to allow the 8192 Baud setting,
Cypress CY7C65213 and Silicon Labs CP2102 - They both worked without errors, so we can safely assume we've found the solution as it works with 3 different manufacturers chips and USB-to-Serial drivers.

Now if we could get our hands on the source code or patch the ES executable....

[matts1972]

Now if we could get our hands on the source code or patch the ES executable....

Good news. I have disassembled and corrected the machine code directly in the ElanScan executable. No more workarounds.

[KenS]

Great work Matt, I have run your new Elanscan USB version on Win11 USB2 (I dont have USB3) with a FTDI wired interface and an ESP32 Classic/BR Bluetooth interface and they both run well. Its a big tick from me. Thanks.

[matts1972]

Great work Matt, I have run your new Elanscan USB version on Win11 USB2 (I dont have USB3) with a FTDI wired interface and an ESP32 Classic/BR Bluetooth interface and they both run well. Its a big tick from me. Thanks.

Thank you for the feedback, Ken

[chrism]

Well impressed!!!

[RonR]

Well done again, Matt

I can confirm it also works with USB3 on Windows 10. Would someone like to try it on Windows 11 with USB3, just to be sure all bases are covered?

[matts1972]

Well done again, Matt

I can confirm it also works with USB3 on Windows 10. Would someone like to try it on Windows 11 with USB3, just to be sure all bases are covered?

Thanks, Ron. Pretty sure this will work. I have patched the header processing bug that you identified in your flow graphs by adding code to make sure the buffer does not run dry at this exact moment. So this is a proper fix for this one bug and not a workaround. If this was the only flaw in the original code, then we will be fine regardless of interface technology or latency settings.