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

Karma: +604/-166
Offline Offline

Posts: 12235


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: 1278



« 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: +68/-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: +68/-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: 12235


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: +68/-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: 186


« 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: 12235


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: 34


« 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: +16/-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: 34


« 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
ejg3855
Full Member
***

Karma: +6/-0
Offline Offline

Posts: 119


« Reply #43 on: Today at 09:31:47 AM »

Tool appears to read properly, but when i go to write back the changed file and read it back out to verify nothing is changed.


I think it wries.....




Code:
Call C_GETSTATE successfull:  True state is  0x80


 *************  start write  *************

Call C_WRITESPI at: 0x0  successfull:  True

********** write successfull!! ***********


 *************  start verify  *************

Call C_READSPI  at: 0x0  successfull:  True
write data not equal verify data at pos:  0x12
write data not equal verify data at pos:  0x1e
write data not equal verify data at pos:  0x1f
write data not equal verify data at pos:  0x22
write data not equal verify data at pos:  0x2e
write data not equal verify data at pos:  0x2f
write data not equal verify data at pos:  0x3e
write data not equal verify data at pos:  0x3f
write data not equal verify data at pos:  0x4e
write data not equal verify data at pos:  0x4f
write data not equal verify data at pos:  0x5e
write data not equal verify data at pos:  0x5f
write data not equal verify data at pos:  0x6e
write data not equal verify data at pos:  0x6f
write data not equal verify data at pos:  0x7e
write data not equal verify data at pos:  0x7f
write data not equal verify data at pos:  0x8e
write data not equal verify data at pos:  0x8f
write data not equal verify data at pos:  0x9e
write data not equal verify data at pos:  0x9f
write data not equal verify data at pos:  0xa0
write data not equal verify data at pos:  0xae
write data not equal verify data at pos:  0xaf
write data not equal verify data at pos:  0xb5
write data not equal verify data at pos:  0xb6
write data not equal verify data at pos:  0xb7
write data not equal verify data at pos:  0xb9
write data not equal verify data at pos:  0xbe
write data not equal verify data at pos:  0xbf
write data not equal verify data at pos:  0xc0
write data not equal verify data at pos:  0xc5
write data not equal verify data at pos:  0xc6
write data not equal verify data at pos:  0xc7
write data not equal verify data at pos:  0xc9
write data not equal verify data at pos:  0xce
write data not equal verify data at pos:  0xcf
write data not equal verify data at pos:  0xd0
write data not equal verify data at pos:  0xd1
write data not equal verify data at pos:  0xd2
write data not equal verify data at pos:  0xd3
write data not equal verify data at pos:  0xd4
write data not equal verify data at pos:  0xd5
write data not equal verify data at pos:  0xd6
write data not equal verify data at pos:  0xd8
write data not equal verify data at pos:  0xd9
write data not equal verify data at pos:  0xdb
write data not equal verify data at pos:  0xde
write data not equal verify data at pos:  0xdf
write data not equal verify data at pos:  0xe0
write data not equal verify data at pos:  0xe1
write data not equal verify data at pos:  0xe2
write data not equal verify data at pos:  0xe3
write data not equal verify data at pos:  0xe4
write data not equal verify data at pos:  0xe5
write data not equal verify data at pos:  0xe6
write data not equal verify data at pos:  0xe8
write data not equal verify data at pos:  0xe9
write data not equal verify data at pos:  0xeb
write data not equal verify data at pos:  0xee
write data not equal verify data at pos:  0xef
write data not equal verify data at pos:  0xfe
write data not equal verify data at pos:  0xff
write data not equal verify data at pos:  0x100
write data not equal verify data at pos:  0x10e
write data not equal verify data at pos:  0x10f
write data not equal verify data at pos:  0x15e
write data not equal verify data at pos:  0x15f
write data not equal verify data at pos:  0x16e
write data not equal verify data at pos:  0x16f
write data not equal verify data at pos:  0x17e
write data not equal verify data at pos:  0x17f
write data not equal verify data at pos:  0x18e
write data not equal verify data at pos:  0x18f
write data not equal verify data at pos:  0x19e
write data not equal verify data at pos:  0x19f
write data not equal verify data at pos:  0x1ae
write data not equal verify data at pos:  0x1af
write data not equal verify data at pos:  0x1be
write data not equal verify data at pos:  0x1bf
write data not equal verify data at pos:  0x1ce
write data not equal verify data at pos:  0x1cf
write data not equal verify data at pos:  0x1de
write data not equal verify data at pos:  0x1df
write data not equal verify data at pos:  0x1ee
write data not equal verify data at pos:  0x1ef
write data not equal verify data at pos:  0x1f0
write data not equal verify data at pos:  0x1f1
write data not equal verify data at pos:  0x1f2
write data not equal verify data at pos:  0x1f3
write data not equal verify data at pos:  0x1f4
write data not equal verify data at pos:  0x1f5
write data not equal verify data at pos:  0x1f6
write data not equal verify data at pos:  0x1f7
write data not equal verify data at pos:  0x1f9
write data not equal verify data at pos:  0x1fa
write data not equal verify data at pos:  0x1fb
write data not equal verify data at pos:  0x1fc
write data not equal verify data at pos:  0x1fd
write data not equal verify data at pos:  0x1fe
write data not equal verify data at pos:  0x1ff

********** verify successfull!! ***********


C:\Users\ericg\Desktop\me2024> ME7BootEeprom 9600 -read -SSC 1 Port3 Pin6.3 512 confirm.ori

Logged
Pages: 1 2 [3]
  Print  
 
Jump to:  

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