NefMoto

Hey everyone,

Hope the new year is treating you all well, thought I would share something of value.

I am just in the midst of some studying of the Tricore system and thought you guys would benefit from this analysis of how a call is made in these ECUs.  As most of you may know in ME7 a call is pretty easy to setup and requires little to no thinking.  In MED17 the system works a lot differently from what I have seen so far.  I hope what I say next can be easily understood by most of you and it helps you along your way.  If any of the below information is inaccurate or can be expanded upon I welcome you all to join in on the discussion. :)


Ok, so I want to initiate a call towards a blank flash zone to implement some custom code. How the call function works in MED17 (or at least the certain BIN I am dissassembling) is that it uses the call function address location as the starting point and offsets itself accordingly based off of the information just following the instruction. (It will be easier to understand in a minute).

For simplicity, we will say that we are starting at address 0x80000000.

The "CALL" function is intiated by the Hexadecimal code "6D" where anything placed in the next three bytes are automatically used towards the processors calculation of the intended address offset (your target address). It does look like any address called will have to be that on an even number address if the call is starting from an even number address...

Example 1:

0x80000000 start address : (6D 00 00 00)

*You can see here how when there are only zeros following the "CALL" instruction we will end up calling the location from where we are calling from!*

RESULT: 0x80000000

Example 2:

0x80000000 start address + 2h   : (6D 00 01 00)
*When we add a 1 to the second entry point the "CALL" is now shifted two addresses forward. This would finish my rationale of the above statement where you need to call an even number target address when calling from an even number start address!* (Also, worthwhile to mention that through dissassembly I didn't see any instances (so far) of any uneven numbered calls).

RESULT: 0x80000002

      
Example 3:

0x80000000 start address + 200h  : (6D 00 00 01)
*In this example we can see when adding a 1 to the last entry point that we will shift now 200 addresses forward*

RESULT: 0x80000200

      
Example 4:

0x80000000 start address + 20000h : (6D 01 00 00)
*In this final example we can see when adding a 1 to the first entry point that we will shift now 20000 addresses forward*

RESULT: 0x80020000

In conclusion:

Using this logic and some practice can help you implement some custom code in your MED17 projects!

This is just my interpretation of what I have seen/played with so this is a topic that is definitely open for debate!  If any of you have any more to add on this subject please feel free :)

Christian

Interesting information. Thanks for sharing!

Thanks :)

Furthermore I have found this to be true for location calls from a JUMP command.

The jump call works in a similar way except instead of 3 bytes of entry data for the jump location there is only 2.

for instance:


JLT  d15, d0, 0x80000000

format-- > 3F 0F XX XX (3F = JLT and 0F = the data registers being used in function)
trial1-- > 3F 0F 01 00 = 0x80000002
trial2-- > 3F 0F 10 00 = 0x80000020
trial3-- > 3F 0F 00 01 = 0x80000200
trial4-- > 3F 0F 00 10 = 0x80002000

To summarise, you are finding relative call and j instructions. calla and ja are the absolute equivalents. calli and ji are the versions using an address register. I use them all in my code, as does the ECU.

Thanks for the input jcs :)

I have yet to use CALLA or JA but will definitely be looking into them further.

edit: As per your recommendation on CALLA and JA (which actually looks to be a much easier way to call to an address without having to worry about the relative offset from call instruction) I have found the following to be true.

CALLA - Hexadecimal form = $ED

ED xx xx xx will be the format in which to set up your absolute target address.

TRIAL 1 --> ED 80 00 00 = Address: 0x80000000
TRIAL 2 --> ED 81 00 00 = Address: 0x80020000
TRIAL 3 --> ED 80 00 10 = Address: 0x80002000
TRIAL 4 --> ED 80 00 01 = Address: 0x80000200
TRIAL 5 --> ED 80 10 00 = Address: 0x80000020
TRIAL 6 --> ED 80 01 00 = Address: 0x80000002

JA - Hexadecimal form = $9D

9D xx xx xx will be the format in which to set up your absolute target address.

TRIAL 1 --> 9D 80 00 00 = Address: 0x80000000
TRIAL 2 --> 9D 81 00 00 = Address: 0x80020000
TRIAL 3 --> 9D 80 00 10 = Address: 0x80002000
TRIAL 4 --> 9D 80 00 01 = Address: 0x80000200
TRIAL 5 --> 9D 80 10 00 = Address: 0x80000020
TRIAL 6 --> 9D 80 01 00 = Address: 0x80000002

As you can see it's the exact same format for both CALLA and JA other than the actual instruction ($ED/$9A).

Christian

You have looked in the Tricore instruction set manual? The disadvantage of absolute addressing is that the code is not relocatable but calla/ja has an advantage over call/j in reaching the early parts of any segment, which are out of reach of a relative call/j. The calli/ji can go anywhere, but uses more space and execution time, and there is a silicon bug on TC1796 and earlier that needs a nop between loading the register and the calli/ji.

Yep I have the instruction set manual, just a little hard to digest sometimes but I am piecing it together.  Thanks for the tip on that bug I'm sure that will come in handy for me.

Also worth reading the Tricore EABI as it tells you which registers are used as parameters and return from a call, which are preserved, which are clobbered.

Appreciate the input greatly :)

you can save and restore too so that is what you actually need to do to preserve what is needed

Use :

  svlcx   to save (Save Lower Context) saves registers A[2] through A[7] and D[0]
through D[7]

  rslcx    to restore (Restore Lower Context) restores the lower context. It loads
registers A[2] through A[7] and D[0] through D[7] from the CSA. It also loads A[11]
(Return Address) from the saved PC field.

thanks for that gt!

Watch out for another TC1796 silicon bug on rslcx. Needs a NOP.

So I have seen! It looks as if the same rule applies for svlcx as well.

You happen to have hit the main relevant ones :) If you use good tools they will fix them for you or alert you but you don't want to crash an ECU and have to pull it from the stupid place it might be mounted to boot it because of one of them.

Which ones are you using?

http://free-entry-toolchain.hightec-rt.com/

Sorry HelperD, I am not keeping up with all the PMs, but contribute and learn from the forum where I can.

Thanks for the link jcs :)

I know this thread is a little old but just thought I would share a tool I made to facilitate a quicker result when calculating CALLA or JUMPA in hex.  Hope this helps someone. If there are bugs please let me know...

Christian