Pages: 1 2 [3]
Author Topic: Fully open source ME7 EEPROM tool :)  (Read 31496 times)
nyet
Administrator
Hero Member
*****

Karma: +604/-166
Offline Offline

Posts: 12232


WWW
« Reply #30 on: November 12, 2020, 06:35:53 PM »

Yes. Unfortunately most of the changes (in small changes to maps/code) are in checksums (even worse, often spread across many blocks), and because of the nature of checksums (and crcs) the odds of having only bit sets (or clears) is nearly zero.
Logged

ME7.1 tuning guide (READ FIRST)
ECUx Plot
ME7Sum checksum checker/corrrector for ME7.x

Please do not ask me for tunes. I'm here to help people make their own.

Do not PM me technical questions! Please, ask all questions on the forums! Doing so will ensure the next person with the same issue gets the opportunity to learn from your experience.
Blazius
Hero Member
*****

Karma: +89/-40
Offline Offline

Posts: 1277



« Reply #31 on: November 12, 2020, 06:42:58 PM »

Unfortunately the cheap Ch340 cables dont come with a can chip(if i remember right), so if you do precompile this for public it would be nice to have the option to "choose".
(Tried using ch340 cable with argdubs tool a while back , and I couldnt not get it working for the life of me for some reason [through OBD bootmode that is, could've been many things])

And yes technically nef should work on ch340 or cheaper usbtoserial chips without serial number id's if not for the dll, I am sure it would be nice for some people.
« Last Edit: November 12, 2020, 06:57:22 PM by Blazius » Logged
360trev
Full Member
***

Karma: +66/-2
Offline Offline

Posts: 235


« Reply #32 on: November 12, 2020, 07:28:27 PM »

Unfortunately the cheap Ch340 cables dont come with a can chip(if i remember right), so if you do precompile this for public it would be nice to have the option to "choose".
(Tried using ch340 cable with argdubs tool a while back , and I couldnt not get it working for the life of me for some reason [through OBD bootmode that is, could've been many things])

And yes technically nef should work on ch340 or cheaper usbtoserial chips without serial number id's if not for the dll, I am sure it would be nice for some people.

Well with a good serial port abstraction interface your really just talking about 2 way streams i/o...
You can do multiple different things here and it really is up to your imagination how much support you add...

1. Search via linking against the the FDTI lib for Unique named devices or serial's (ugh!), this could also read eeprom and determine if the device supports CAN, If that fails to find any ;
2. Search for USB attached serial devices by looking for compatible VID/PID's in the registry entries,
3. If none exist, search for any other attached USB devices which are of type serial port,
4. If that fails try to fallback to Auto-discovery of regular good old fashioned serial attached to non (virtual) com ports and if multiple serial devices are present allow you to choose which one to use.
5. Override with ability to choose com port number manually.
6. Override with ability to redirect and tunnel serial traffic over TCP/IP. This allows you to run a client/server over the internet and read from a remote serial port attached, i.e. flash over the internet. The only challenge is to do a speed test on setup to determine if your speed and latency is good enough.

To make it all encompassing its quite a lot of work but you get the most flexibility..
Logged
360trev
Full Member
***

Karma: +66/-2
Offline Offline

Posts: 235


« Reply #33 on: November 12, 2020, 07:33:51 PM »

Yes. Unfortunately most of the changes (in small changes to maps/code) are in checksums (even worse, often spread across many blocks), and because of the nature of checksums (and crcs) the odds of having only bit sets (or clears) is nearly zero.

True, checksums however are not scattered everywhere, typically the multipoints are all in one location and the shadow and main sums can be done but even so, 95% of the rom is going to be the same so it can yield big benefits still for speed.

Logged
nyet
Administrator
Hero Member
*****

Karma: +604/-166
Offline Offline

Posts: 12232


WWW
« Reply #34 on: November 12, 2020, 07:54:56 PM »

True, checksums however are not scattered everywhere, typically the multipoints are all in one location and the shadow and main sums can be done but even so, 95% of the rom is going to be the same so it can yield big benefits still for speed.

I have yet to see a change that is entirely bit sets in a given block .. ymmv ... At 16 blocks (or even 32), its never going to be 95%

Again, i have written flash drivers (unrelated to car tuning) that attempt to do this. They don't work as well as you'd think. There are filesystems though (back when this sort of flash was popular) that attempt to do this with set-only bits baked into the format (e.g. jffs). They're long dead.

If Bosch had cared, they could have written their checksum system to take advantage of this. They did not, since they no doubt never used an ECU with flash during ECU tuning/mapping/calibration
« Last Edit: November 12, 2020, 10:31:50 PM by nyet » Logged

ME7.1 tuning guide (READ FIRST)
ECUx Plot
ME7Sum checksum checker/corrrector for ME7.x

Please do not ask me for tunes. I'm here to help people make their own.

Do not PM me technical questions! Please, ask all questions on the forums! Doing so will ensure the next person with the same issue gets the opportunity to learn from your experience.
360trev
Full Member
***

Karma: +66/-2
Offline Offline

Posts: 235


« Reply #35 on: November 12, 2020, 08:19:30 PM »

I'm still using JFFS in some Linux project today Smiley

My observation is that the writing time is a smaller proportion of the overall re-flashing time. The vast majority is the bottleneck of the download itself. So if you remove the downloading time by only downloading the differential data then read back into ram, erase and individual sector, merge differences in ram and write back you should see a big improvement in speed. I will test this shortly and give you some figures...

Logged
d3irb
Full Member
***

Karma: +131/-1
Offline Offline

Posts: 185


« Reply #36 on: November 12, 2020, 08:54:00 PM »

With respect to CAN, it's unfortunate there is no standard (or even de facto standard like FTDI ended up being for bitbang+UART) driver interface for CAN. SocketCAN on Linux and J2534 on Windows seem to be the closest to dominant standards, but J2534 is a mess of expensive and non-compliant "compliant" vendor devices and SocketCAN requires being a bit of a Linux nerd to deal with (finding hardware, configuring the interface, adding isotp kernel module if necessary, and so on). And then there are all of the weird serial<->CAN devices which all seem to implement different little wire protocols. A higher-level abstraction would be truly amazing but also quite a lot of work since there is a fair amount of nuance (between baud rate, filters/interrupt setup, padding, ISOTP framing, etc.).

As for this bootloader work, amazing. It's great to see people still reversing stuff and rebuilding, even if it is for ancient ECUs.
Logged
nyet
Administrator
Hero Member
*****

Karma: +604/-166
Offline Offline

Posts: 12232


WWW
« Reply #37 on: November 12, 2020, 10:30:40 PM »

I'm still using JFFS in some Linux project today Smiley

My observation is that the writing time is a smaller proportion of the overall re-flashing time. The vast majority is the bottleneck of the download itself. So if you remove the downloading time by only downloading the differential data then read back into ram, erase and individual sector, merge differences in ram and write back you should see a big improvement in speed. I will test this shortly and give you some figures...



This sounds totally doable and will almost certainly dramatically decrease flashing time. The Nef flasher already does this to some extent (but NOT bootmode!)
« Last Edit: November 12, 2020, 10:34:21 PM by nyet » Logged

ME7.1 tuning guide (READ FIRST)
ECUx Plot
ME7Sum checksum checker/corrrector for ME7.x

Please do not ask me for tunes. I'm here to help people make their own.

Do not PM me technical questions! Please, ask all questions on the forums! Doing so will ensure the next person with the same issue gets the opportunity to learn from your experience.
Tohmerdis
Newbie
*

Karma: +0/-0
Offline Offline

Posts: 1


« Reply #38 on: December 09, 2020, 04:05:25 PM »

Wonderful work!
Do you put full source to Github or somewhere similar?
Logged
darklet
Newbie
*

Karma: +1/-0
Offline Offline

Posts: 5


« Reply #39 on: September 11, 2022, 05:34:57 PM »

did the source code ever get made open, i cant see it on your github Sad


Update:

I reversed it, and added a me7.4.5 95320 read/write function...
Well hardcode IMMO off write function that just updated bytes 40h-60h
Switching it to use XSSC bus was a right pain.
« Last Edit: September 25, 2022, 11:08:48 AM by darklet » Logged
ecuprog7
Jr. Member
**

Karma: +1/-0
Offline Offline

Posts: 31


« Reply #40 on: January 29, 2023, 03:14:59 AM »

Hi to all!
I can´t find the source code for this tool and has there been work on integrating it into nefmoto flasher?
Logged
fragolas
Jr. Member
**

Karma: +15/-0
Offline Offline

Posts: 39


« Reply #41 on: February 24, 2023, 07:35:29 PM »

@360trev Will you ever release the source code? Besides the me7/edc15 , I have a airbag ecu with c164 and I could use bsl to read and write the eeprom without desolder . I could probably write driver for minimon, but this would also be helpful.
Kwp services could also work, but that's beside the point.
I also wonder which cpu does Bosch abs 5.7 uses...

Enviado do meu M2102J20SG através do Tapatalk

Logged
ecuprog7
Jr. Member
**

Karma: +1/-0
Offline Offline

Posts: 31


« Reply #42 on: February 26, 2024, 09:31:05 AM »

Hi,
done a rework of argdubs tool, eeprom driver is a adapted version of post from gremlin. Tested on Me7.5 and ME7.1.
The tool reconnects to running minimon core, so need to restart ecu after one operation (read or write). Source code of eeprom drivers are included.
Eeprom read and write on C167 and St10 ( XSSC module ) for type 0 95080 - 95320 and type 1 95040 / 95p08 supported, type 2-4 are 93cxx versions, read internal Rom/IFlash . Read of ext Flash not working.

Please try and report.

update 28.2.2024:
Now works with psa ME7.4.5 (ME745) with ST10 . Cs pin is P6.2 , XSSC module is used.

update 09.3.2024:
works now on Simos 3 with 93Cxx eeprom (only ssc module)


« Last Edit: March 09, 2024, 03:55:26 AM by ecuprog7 » Logged
Pages: 1 2 [3]
  Print  
 
Jump to:  

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Page created in 0.024 seconds with 18 queries. (Pretty URLs adds 0s, 0q)