|
nyet
|
 |
« 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 guideECUx PlotME7Sum checksumTrim heatmap toolPlease 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 ex
|
|
|
|
Blazius
|
|
« 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
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
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
|
|
« 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 guideECUx PlotME7Sum checksumTrim heatmap toolPlease 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 ex
|
|
|
360trev
Full Member
Karma: +68/-2
Offline
Posts: 235
|
|
« Reply #35 on: November 12, 2020, 08:19:30 PM »
|
|
|
I'm still using JFFS in some Linux project today  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: +134/-1
Offline
Posts: 195
|
|
« 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
|
|
« Reply #37 on: November 12, 2020, 10:30:40 PM »
|
|
|
I'm still using JFFS in some Linux project today 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 guideECUx PlotME7Sum checksumTrim heatmap toolPlease 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 ex
|
|
|
Tohmerdis
Newbie
Karma: +0/-0
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
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  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
Full Member
Karma: +3/-0
Offline
Posts: 55
|
|
« 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: +17/-0
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
Full Member
Karma: +3/-0
Offline
Posts: 55
|
|
« 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 no 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 and write of external Flash now supported on Me7xx and Simos 3.x. 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) update 12.9.2024: read write of ext flash on Me(d)7.xx and Simos 3.x supported command line has changed a little bit (-readeeprom / -writeeeprom instead of only read or write): update 21.102024 V1_2: read write of ext flash and eeprom on EDC15VM/P+ with 29f800BT and 24C04, read internal rom also Help output: BootMode Tool for me(d)7 , Simos 3.x & EDC15VM/P+ Variants inspired by ArgDub , 360trev and Gremlin
***********
type -h for this help
Arguments in [] are optional:
-------------------- Read EEProm--------------------
ME7BootTool baudrate -readeeprom -PeriphType eepromtype Port(of chip select) Pin(of chip select) size(hex or dezimal) [filename]
eg: ME7BootTool 9600 -readeeprom -XSSC 1 Port4 Pin7 0x100 551Eeprom.ori
eg: ME7BootTool 28800 -readeeprom -SSC 1 Port4 Pin7 0x200 551Eeprom.ori
eg: ME7BootTool 28800 -readeeprom -I2C 11 0x200 551Eeprom.ori
----------------------------------------------------
-------------------- Write EEProm--------------------
ME7BootTool baudrate -writeeeprom -PeriphType eepromtype Port(of chip select) Pin(of chip select) filename
eg: ME7BootTool 9600 -writeeeprom -XSSC 1 Port6 Pin3 551ImmoOff.bin
eg: ME7BootTool 28800 -writeeeprom -SSC 1 Port6 Pin3 551ImmoOff.bin
eg: ME7BootTool 28800 -writeeeprom -I2C 11 551ImmoOff.bin
----------------------------------------------------
-------------------- Parameters for R/W EEProm--------------------
type of eeprom is 0 for 95080 to 95320, 1 for 95040 or 95p08,
2 for 93S46 with 6bit address, 3 for 93S56 or 93S66 with 8 bit address, 4 for 93S76 or 93S86 with 10 bit address
10 for 24c02 with 8bit address, 11 for 24c04 with 9bit address
Chip select for eeprom: Port2,3,4,6,7,8 are supported, pins 0-15; ME7.5 & 7.1 P4.7; ME7.1.1 P6.3 ; SIMOS 3.2 is P6.4
-PeriphType : -SSC for C16x or ST10, -XSSC for ST10 and XC167 (only type 0 and 1 supported),
-PeriphType : -I2C for EDC15VM/P+ (only type 10 and 11 supported)
----------------------------------------------------
-------------------- read internal Rom or Flash (IROM, IFLASH) --------------------
ME7BootTool baudrate -readInt size(hex or dezimal) [filename]
eg: ME7BootTool 28800 -readInt 0x8000 551IntRom.ori
----------------------------------------------------
-------------------- read external Flash --------------------
ME7BootTool baudrate -readextflash size(hex or dezimal) [filename]
eg: ME7BootTool 28800 -readextflash 0x80000 551extFlash.ori
----------------------------------------------------
-------------------- write external Flash --------------------
ME7BootTool baudrate -writeextflash filename Ecu/FlashType (ME7, Simos3, EDC15)
eg: ME7BootTool 28800 -writeextflash 551extFlash.bin simos3
eg: ME7BootTool 57600 -writeextflash 551extFlash.bin me7
eg: ME7BootTool 57600 -writeextflash 551extFlash.bin edc15
----------------------------------------------------
-------------------- Baudrate --------------------
standard rates: 9600, 19200, 28800, 38400, 57600, 115200 ; depending on cable 115200 or 57600 may not work |
|
|
|
« Last Edit: October 21, 2024, 08:11:43 AM by ecuprog7 »
|
Logged
|
|
|
|
ejg3855
Full Member
Karma: +6/-0
Offline
Posts: 123
|
 |
« Reply #43 on: May 18, 2024, 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..... 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
|
|
|
|
ecuprog7
Full Member
Karma: +3/-0
Offline
Posts: 55
|
|
« Reply #44 on: May 20, 2024, 11:53:42 PM »
|
|
|
[quote author=ejg3855 link=topic=18686.msg165859#msg165859 date=1716049907]
C:\Users\ericg\Desktop\me2024> ME7BootEeprom 9600 -read -SSC 1 Port3 Pin6.3 512 confirm.ori
[/quote] Call line is wrong, i´m suprised the tool does anything, this should do the job: ME7BootEeprom 9600 -read -SSC 1 Port6 Pin3 512 confirm.ori ME7BootEeprom 9600 -write -SSC 1 Port6 Pin3 immoOff.bin Edit: the Port in call line is not com port of kkl cable, its the pin Port of the Processor. On ME7.5 its Port4 Pin7, Me711 Port6 Pin3. the virtual com port is searched from the tool and if you have connected more than one you can choose which to use |
|
|
|
« Last Edit: May 21, 2024, 05:15:25 AM by ecuprog7 »
|
Logged
|
|
|
|
|
