NefMoto

 sub_87C532:                             ; CODE XREF: sub_87F562+126P
seg017:87C532                 mov     [-r0], r8
seg017:87C534                 mov     [-r0], r7
seg017:87C536                 mov     [-r0], r6
seg017:87C538                 movb    rl4, CW_NO_ROM_CHECK_RESET_byte_811A24
seg017:87C53C                 cmpb    rl4, #55h ; 'U'
seg017:87C540                 nop
seg017:87C542                 nop
seg017:87C544                 movb    byte_382B5A, ZEROS
seg017:87C548                 mov     r4, word_383D98
seg017:87C54C                 and     r4, #0DFFFh
seg017:87C550                 or      r4, #4000h


This is from the M rom.  It would appear there is a capability to ignore checksum errors, by setting the byte 0x811a24 to 0x55.  However Bosch have broken the capability by puting NOPs over the jump instruction that was underneath.

Has anyone worked out where it goes / done any testing on this?

The function you mentioned is executed once during system startup. The ECU checks here
for correct EGAS functionality and in case there is some problem, the FLASH system
won't be started.
For the example image you gave, the code instead of the NOP's would be:
87'C540: EA20 76C7      JMPA    cc_Z/EQ, L_skip_checks (87'C776)

This jumps to the following place:
...
87'C774: 0D04           JMPR    cc_UC, L_continue (87'C77E)
L_skip_checks:
87'C776: E6F4FFDF       MOV     R4, #DFFFh
87'C77A: 64F498BD       AND     [BD98], R4
L_continue:
87'C77E: F78E36B4       MOVB    [B436], ZEROS
...

In damos/a2l you can see that the codeword CW_NOROMCHKRESET is used only
in the function URROM which is named "EGAS

seems like my last post was cut when hitting a german letter ...

In damos/a2l you can see that the codeword CW_NOROMCHKRESET is used only
in the function URROM which is named "EGAS Ueberwachungskonzept: ROM-Test"
(electronic power control supervision concept: ROM-test).

By patching the NOP's and setting the codeword to "55" you could skip the EGAS-checks,
but the data checksums which are calculated/checked when the flash system is running can
not be disabled using the codeword CW_NOROMCHKRESET.

I think the data checksums can be disabled by coding your ECU as test model in the EEPROM.

Thanks for that!  Non starter then.

Do you know anymore about the ecu = 'test model' idea?

Coding the ECU as test model is done in the eeprom, you have to change some data values:
in pages 1 and 2 you will find  69,C1, and A5, replace these by 8E,5A, and D2,
then update the checksums of both pages. I believe you (or other experienced users)
can manage this without more detailed instructions (and the noob's anyway shouldn't
do).

I do not know what could be changed by setting to test model besides the following:
 - the data checksum results will be ignored by the ECU,
 - you can start a programming session even if the ECU is locked for some time after
   sending a wrong security key,
 - you can download data to the flash without ciphering and compressing.

On ME7.5 images, when you have started a programming session (85) and
are requesting ecuIdentification with param 9B, the last string you get has 5 characters.
If the last character of this string shows a '*', this indicates your ECU is coded as test model. I think this is not done for ME7.1 images.

Be aware: this results from code reading and simulations, not yet tested by me on real hardware.

Thanks.  This will go in to a bench ecu with a desoldered flash.  I have an eprom emulator but I am yet to write a stimulator for this ecu.  This might be the reason to do so.

Very interesting things you're doing ... stimulator ...
Are you trying to "let the engine run" for the bench ecu?
I thought always an eprom emulator is used in the car, but lets see
what you can achieve. Don't forget to disable immo if present ... hehe.

I have a 32 channel ADC/DAC card in an old PC.  It shouldn't be hard to do most of the signals.  Crank and cam synchoronicity during the ecu initiated phase change will be a challenge!

I've not done this for about 5 years, since I had my subaru, so I hope it all still works. :)

The alternative is to write an emulator to run the code on a PC, but that's probably beyond me.

sounds interesting. When I think about this, I only see the potential problems,
e.g. how to handle the missing communication with other controllers.
But only the optimistic one's will change something  :D
I was working on a simulator, but it is a mess and only useful for analysing the
communication functionality on K-Line. It's really slow and a lot of things are missing,
since I don't have too much information about the real hardware.

 :P   It beats using spanners outside in the cold for the winter!

For $30 you can buy this full featured simulator that can do many trigger's...

I'm thinking of picking one up for bench testing new features for the standalones.

http://jbperf.com/JimStim/index.html

yeah that saves some time, especially if it can do the cam triggers already...

A long time ago I spent a while talking to a person that setup and ECU simulator for his ME7.5 with the Keil uVision Simulator. He had it setup to simulate all of the inputs, as well as mapping the K-line to his PCs com port so he could test and debug communication code.

http://www.keil.com/uvision/

I played with it for a while as well, but never got passed setting up the different memory chips, and SPI EEPROM emulation.

When I looked into a simulator (must have been also a Keil SW) some years ago, I lost
several days until I found out the thing was not creating even an adc interrupt ...
Now Keil states it simulates the complete CPU hardware. Maybe I was too stupid at that
time to use it correctly.

Does the uVision Simulator provide real speed, so it can be connected to a hardware
serial port? Nearly can't belive this (I have worked on  my own sim which runs 3-4 times
slower than realtime).

Sadly the evaluation software is limited to 8kB code, makes not much sense to play with
it again if you can't load even the 32kB bootrom.

The simulator doesn't run at full speed, but if you slow down the communication over the serial port, I am told it works.

The trial version is only limited by how much code it can compile, and not how much code you can load into the simulator.

Very good , then I might have a look again at this uVision Simulator, of course if I find
some spare time.

wow. this is awesome info and exactly what i was looking for. well, kind of exactly what i was looking for. many many thanks for this!

Thanks from me as well and +rep to setzi62.

I will test this today/tomorrow.

Blast from the past but wanted to add that this is implemented in Volvo ME7 ECU's.

Hello, I changed the data in EEPROM (69,C1, and A5, replace these by 8E,5A, and D2) , flashed in ECU , and received a character (*) in the block description . After I flashed the file with the wrong checksum and after two launches ECU stopped switching on .
I repaired my ECU with flash backup eeprom and firmvare but did not understand what this manipulation gives.
I originally did this to get a working LC in 8E0909518F  0003_363670 , but so far nothing has happened.

Look on the forum in ME7.1.1 emulator thread, I described exactly how to turn everything off.
This only disables running checksums not startup sums.

I understood ! Thank you!

I changed the data in EEPROM (69,C1, and A5, replace these by 8E,5A, and D2) in 4B0906018DJ_366458 and changed  variable 0x384FF0 to 386000 . No errors  (p0601 checksum error) , 3 days cars work perfect , LC work ! Thank you !

I know this is an ancient post but i've just been exploring a ROM file which was given to me which works no problem but had non corrected checksums present. After a little analysis by comparing the rom to the original firmware I discovered;

---------------------------------------------
0x000668b8 (  420024): cc -> ea               jmpa    cc_Z,jmp +244          CW_NOROMCHKRESET Patch
0x000668b9 (  420025): 00 -> 20               
0x000668ba (  420026): cc -> ee               
0x000668bb (  420027): 00 -> 6a               

CC 00  is the machine code 'NOP' (No Operation, i.e. do nothing) and it was replaced with an
EA 20 which is a conditional jump relative based on the previous instruction which does the CMP against 0x55 in hex... which is normally set to 0'...

0x0001165a (   71258): 00 -> 55    CW_NOROMCHKRESET

Which surprise surprise they've set to 0x55 which means it always does the skip...

And then further to that they also set to 0x55 another CODEWORD,

0x00011b21 (   72481): 00 -> 55      CW_NOZYKLROMCHK - disable cyclic rom monitor checksums

I believe this is the one which the OP was interested in all along. I believe this disables the Multipoint Cyclic checksums from being checked by the rom monitor...

And all this was done on a very expensive car without the customer having any idea what they did... WTF! Why didn't they just re-calculate the checksums??!?!?! fine for R&D purposes but there is no way I would do this to anyone's personal car and leave it like that.