DT
Full Member
Karma: +20/-1
 Offline
Posts: 184
|
 |
« on: November 18, 2015, 12:58:18 PM »
|
|
|
I'm adding code to an me7 ecu but cannot get my jmps or calls to work. I think I've completely missed something and hope that someone can help.
Example: A list of calls and in one of the sub routines I've made a succesful local jmps but the long jmps or calls to another segment makes the ecu hang.
loc_800xxx:
CALLS 80h, loc_802000
CALLS 81h, loc_812000
CALLS 82h, loc_821000
CALLS 80h, loc_807000 (this routine is where I changes seen below)
CALLS 83h, loc_838000
=======================================================
sub_807000:
807000 jmps 80h, loc_807008 (this jmps within the sub works well)
807004 nop
807006 nop
807008 mov word_3810xx, r5
80700c ...
=======================================================
sub_807000:
807000 JMPS 87h, loc_87e000 (this jmps with a jmps to return to 807004 does not work and seems to hang ecu)
807004 mov word_3810xx, r5
807006 add ...
807008 mov .....
80700c ....
87e000:
NOP
NOP
JMPS 80h, loc_807004
=======================================================
sub_807000:
807000 CALLS 87h, loc_87e000 (this CALLS with a RETS to return to 807004 does not work and seems to hang ecu)
807004 mov word_3810xx, r5
807006 add ...
807008 mov .....
80700c ....
87e000:
NOP
NOP
RETS
|
|
|
|
« Last Edit: November 20, 2015, 06:21:55 AM by DT »
|
Logged
|
|
|
|
DT
Full Member
Karma: +20/-1
Offline
Posts: 184
|
|
« Reply #1 on: November 20, 2015, 04:26:53 AM »
|
|
|
Is there anyone with enough C16x knowledge here? Problem with DPP due to probably beeing inside an interrupt or trap?
edit: I edited a couple of digit errors above in OP but nothing significant to the problem explained.
|
|
|
|
« Last Edit: November 20, 2015, 06:23:06 AM by DT »
|
Logged
|
|
|
|
|
elRey
|
|
« Reply #2 on: November 20, 2015, 07:49:54 AM »
|
|
|
Sre you sure 87e000 doesn't get called outside of 807000 (in main loop) thus causing an infinite loop?
|
|
|
|
|
Logged
|
|
|
|
DT
Full Member
Karma: +20/-1
Offline
Posts: 184
|
|
« Reply #3 on: November 20, 2015, 07:55:46 AM »
|
|
|
Sre you sure 87e000 doesn't get called outside of 807000 (in main loop) thus causing an infinite loop?
finally someone who has something to say If I understand your concern correctly this is my answer to that: 87e000 is a new routine made by me, it was empty space FF before |
|
|
|
|
Logged
|
|
|
|
|
elRey
|
|
« Reply #4 on: November 20, 2015, 09:24:27 AM »
|
|
|
It may have been empty space, but it could have been included in the main loop. doubtful, but best to confirm. you can do that by reverting your first jmps to NOT jmp to 87e000 and replace jmp in new func with setting a varible u can log to see if ur new func is being called/ran without u jmping to it.
|
|
|
|
|
Logged
|
|
|
|
DT
Full Member
Karma: +20/-1
Offline
Posts: 184
|
|
« Reply #5 on: November 20, 2015, 10:10:26 AM »
|
|
|
It may have been empty space, but it could have been included in the main loop. doubtful, but best to confirm. you can do that by reverting your first jmps to NOT jmp to 87e000 and replace jmp in new func with setting a varible u can log to see if ur new func is being called/ran without u jmping to it.
Well 87e000 is part of ~8kb of empty space filled with FF . I don't really understand what you mean with jmps from main loop to this empty area? I'm well aware of the the method of writing to a ram variable and log, preferably with an add to be able to log how often it is running. I'm using a Roadrunner emulator in the ecu, it's really easy to try different things. |
|
|
|
|
Logged
|
|
|
|
fknbrkn
Hero Member
Karma: +177/-18
Offline
Posts: 1405
mk4 1.8T AUM
|
|
« Reply #6 on: November 20, 2015, 10:12:33 AM »
|
|
|
calls #87h, #0E000h
( DA8700E0 )
do not use jmps to call your routine from main loop
|
|
|
|
|
Logged
|
|
|
|
DT
Full Member
Karma: +20/-1
Offline
Posts: 184
|
|
« Reply #7 on: November 20, 2015, 10:41:37 AM »
|
|
|
calls #87h, #0E000h
( DA8700E0 )
do not use jmps to call your routine from main loop
It is not in main loop but rather an interrupt subroutine. CALLS/RETS or JMPS/JMPS both give same result. calls 87h, #e000h (loc_87e000 is the IDA label with offset), DA8700E0 is the hex like you say |
|
|
|
« Last Edit: November 20, 2015, 10:45:31 AM by DT »
|
Logged
|
|
|
|
fknbrkn
Hero Member
Karma: +177/-18
Offline
Posts: 1405
mk4 1.8T AUM
|
|
« Reply #8 on: November 20, 2015, 11:34:27 AM »
|
|
|
well
whats the original string you replaced by call?
i think there is something else. im using a few calls to a new routines in my file without any issue. but ive placed it to the 8Bh seg
|
|
|
|
|
Logged
|
|
|
|
DT
Full Member
Karma: +20/-1
Offline
Posts: 184
|
|
« Reply #9 on: November 20, 2015, 11:44:21 AM »
|
|
|
well
whats the original string you replaced by call?
i think there is something else. im using a few calls to a new routines in my file without any issue. but ive placed it to the 8Bh seg
One move and one add, third is replaced with a MOV mem, ZEROES . Unfortunately there is no clue in that either since the local JMPS 80h, loc_807008 works well. (within same segment and also within same subroutine in example1 above) |
|
|
|
|
Logged
|
|
|
|
DT
Full Member
Karma: +20/-1
Offline
Posts: 184
|
|
« Reply #10 on: November 21, 2015, 04:24:40 PM »
|
|
|
I've done more testing now and I think it might be a bug in TunerPro or worst case the Roadrunner Emulator causing my problem.
I will do some more testing and report what I find out.
|
|
|
|
|
Logged
|
|
|
|
DT
Full Member
Karma: +20/-1
Offline
Posts: 184
|
|
« Reply #11 on: November 22, 2015, 10:55:25 AM »
|
|
|
After todays testing I'm convinced that there is a problem with TunerPro or the Roadrunner emulator at word 0x7dffe and word 0x7e000.
The ecu seems to hang while executing code at those two words, download from emulator to binary file shows correct information.
I've not tried moates tool to download binary yet. If that also show correct binary information it would indicate a problem with the Roadrunner, if not there is an upload/download problem with TunerPro.
Could anyone else with a Roadrunner try to execute something at 7dffe or 7e002? Prj?
Red code does not work. Green code works fine.
==============================
calls 87h, sub_87dffe
...
sub_87dffe:
0x87dffe rets
==============================
calls 87h, sub_87e000
...
sub_87e000:
0x87e000 rets
==============================
calls 87h, sub_87dff8
...
sub_87dff8:
0x87dff8 nop
0x87dffa nop
0x87dffc nop
0x87dffe nop
0x87e000 nop
0x87e002 nop
0x87e004 nop
0x87e006 rets
==============================
==============================
calls 87h, sub_87dffc
...
sub_87dffc:
0x87dffc rets
==============================
calls 87h, sub_87e002
...
sub_87e002:
0x87e002 rets
==============================
|
|
|
|
|
Logged
|
|
|
|
DT
Full Member
Karma: +20/-1
Offline
Posts: 184
|
|
« Reply #12 on: November 22, 2015, 04:43:24 PM »
|
|
|
From what I can tell after testing to download emulator memory with emutility the contents of emulator is correct, but the emulator does not like to execute at those words.
I cannot find anything in C167 errata documents indicating that the problem is within CPU. I will need to contact Moates and check with them.
It would still be interessting if someone with a Roadrunner could try to put some code at the mentioned 2 words and see how their ECU reacts.
|
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #13 on: November 24, 2015, 02:06:04 AM »
|
|
|
Don't have time to test, too much work atm. If you don't solve it, bug me in 2 weeks.
|
|
|
|
|
Logged
|
|
|
|
|
