spen
Full Member
Karma: +43/-0
 Offline
Posts: 112
|
 |
« on: November 06, 2010, 01:51:54 AM »
|
|
|
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?
|
|
|
|
|
Logged
|
|
|
|
setzi62
Full Member
Karma: +142/-0
Offline
Posts: 249
|
|
« Reply #1 on: November 08, 2010, 03:46:49 AM »
|
|
|
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
|
|
|
|
|
Logged
|
|
|
|
setzi62
Full Member
Karma: +142/-0
Offline
Posts: 249
|
|
« Reply #2 on: November 08, 2010, 03:52:51 AM »
|
|
|
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.
|
|
|
|
|
Logged
|
|
|
|
spen
Full Member
Karma: +43/-0
Offline
Posts: 112
|
|
« Reply #3 on: November 08, 2010, 09:20:06 AM »
|
|
|
Thanks for that! Non starter then.
Do you know anymore about the ecu = 'test model' idea?
|
|
|
|
|
Logged
|
|
|
|
setzi62
Full Member
Karma: +142/-0
Offline
Posts: 249
|
|
« Reply #4 on: November 08, 2010, 10:42:16 AM »
|
|
|
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.
|
|
|
|
|
Logged
|
|
|
|
spen
Full Member
Karma: +43/-0
Offline
Posts: 112
|
|
« Reply #5 on: November 09, 2010, 02:41:31 AM »
|
|
|
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.
|
|
|
|
|
Logged
|
|
|
|
setzi62
Full Member
Karma: +142/-0
Offline
Posts: 249
|
|
« Reply #6 on: November 09, 2010, 08:16:39 AM »
|
|
|
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.
|
|
|
|
|
Logged
|
|
|
|
spen
Full Member
Karma: +43/-0
Offline
Posts: 112
|
|
« Reply #7 on: November 10, 2010, 01:59:16 AM »
|
|
|
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. |
|
|
|
|
Logged
|
|
|
|
setzi62
Full Member
Karma: +142/-0
Offline
Posts: 249
|
|
« Reply #8 on: November 10, 2010, 03:25:50 AM »
|
|
|
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  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. |
|
|
|
|
Logged
|
|
|
|
spen
Full Member
Karma: +43/-0
Offline
Posts: 112
|
|
« Reply #9 on: November 10, 2010, 03:45:50 AM »
|
|
|
 It beats using spanners outside in the cold for the winter!
|
|
|
|
|
Logged
|
|
|
|
NOTORIOUS VR
Administrator
Hero Member
Karma: +58/-7
Offline
Posts: 1056
|
|
« Reply #10 on: November 10, 2010, 07:33:23 AM »
|
|
|
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 |
|
|
|
|
Logged
|
|
|
|
spen
Full Member
Karma: +43/-0
Offline
Posts: 112
|
|
« Reply #11 on: November 10, 2010, 11:30:55 AM »
|
|
|
yeah that saves some time, especially if it can do the cam triggers already...
|
|
|
|
|
Logged
|
|
|
|
Tony@NefMoto
Administrator
Hero Member
Karma: +130/-4
Offline
Posts: 1389
2001.5 Audi S4 Stage 3
|
|
« Reply #12 on: November 10, 2010, 12:23:18 PM »
|
|
|
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. |
|
|
|
|
Logged
|
|
|
|
setzi62
Full Member
Karma: +142/-0
Offline
Posts: 249
|
|
« Reply #13 on: November 11, 2010, 06:19:23 AM »
|
|
|
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.
|
|
|
|
|
Logged
|
|
|
|
Tony@NefMoto
Administrator
Hero Member
Karma: +130/-4
Offline
Posts: 1389
2001.5 Audi S4 Stage 3
|
|
« Reply #14 on: November 11, 2010, 12:21:28 PM »
|
|
|
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.
|
|
|
|
|
Logged
|
|
|
|
|
