marcjero
Full Member
Karma: +4/-0
 Offline
Posts: 58
|
 |
« on: August 15, 2022, 04:04:57 PM »
|
|
|
Hi, I just found and forked a disassembler written in perl. Here is the forked project : https://github.com/jmarcgit/c166-disI found a tiny bug so use with care but looks like it's a pretty good and easy to use utility. |
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #1 on: August 16, 2022, 12:40:14 AM »
|
|
|
Could probably ask HighTec for the C166 source code, as I think they have the GCC toolchain for it.
They did give me the TriCore source, but only after a phone call...
|
|
|
|
|
Logged
|
|
|
|
marcjero
Full Member
Karma: +4/-0
Offline
Posts: 58
|
|
« Reply #2 on: August 16, 2022, 02:37:55 AM »
|
|
|
Could probably ask HighTec for the C166 source code, as I think they have the GCC toolchain for it.
They did give me the TriCore source, but only after a phone call...
I don't need to compile for now, I'm more interested in injecting symbols from an A2L file. Quite easy for memory addresses but I would like to add the table and axis names as well. Maybe I can add hooks in the code and then it would be possible to create plugins. |
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #3 on: August 16, 2022, 04:40:44 AM »
|
|
|
I don't need to compile for now I think you should probably investigate a little more what the GCC toolchain is. It includes a full assembler and disassembler for every mcu that it supports. Furthermore, it is a fully programmatic interface, so you can write code analyzers. This is how my Logger is able to find ram cells from a similar A2L for PowerPC and TriCore. I just never implemented C166 because it is not financially viable or universal (the DPP config is different between ECU's). I've done exactly what you want to do, but it's like a half a year full time job to get it to a decent place with conflict resolution and false positive rejection. |
|
|
|
|
Logged
|
|
|
|
marcjero
Full Member
Karma: +4/-0
Offline
Posts: 58
|
|
« Reply #4 on: August 16, 2022, 08:03:14 AM »
|
|
|
I have to find some reading about how the dpp works.
I would like to write a script that generates a list of constants from an A2L file. But the adresses are absolute. Is there any way to calculate dpp from addresses listed in A2L file ? I suppose this has already be done.
|
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #5 on: August 16, 2022, 10:02:40 AM »
|
|
|
No, A2L knows nothing about DPP.
DPP are different based on MCU and ECU...
You can technically try to detect them, but there are many ways to set them, and not every compiler does it the same way.
|
|
|
|
|
Logged
|
|
|
|
marcjero
Full Member
Karma: +4/-0
Offline
Posts: 58
|
|
« Reply #6 on: August 16, 2022, 04:48:45 PM »
|
|
|
orse than I thought...
Maybe there is a way to get something working but not perfect...
when a 16 bit address is discovered, first remove the 2 top bits then generate 4 matching patterns. The 4 variants are the potential 4 lower bytes values in the A2L file. Why 4 ?
because the base address (dpp x 0X4000) will end with 0x0000 0x4000, 0x8000, 0xC000
example : If I find adress 0x4300 in code then 0X4300 0x8300, 0xC300 or 0x0300 could partailly match with A2L adresses (A2L adresses are larger than 16 bits)
Once a potential match is found, a dpp value can be calculated. It's a guessestimate approach. I didn't do any calculation but it looks like that chances to get address colisions are quite low.
|
|
|
|
|
Logged
|
|
|
|
locon
Newbie
Karma: +3/-0
Offline
Posts: 5
|
|
« Reply #7 on: August 16, 2022, 09:47:21 PM »
|
|
|
example : If I find adress 0x4300 in code then 0X4300 0x8300, 0xC300 or 0x0300 could partailly match with A2L adresses (A2L adresses are larger than 16 bits)
Not the right approach. It must be understood that the values of constants are not stored throughout the code. For them, a certain area (sometimes two areas) in memory is allocated. Calls are made to this area with an already defined DPP, which does not change during operation. Thus, the address of a constant from an A2L file refers to a specific area of memory. And the value for DPP must be applied based on the ECU version, M7.1 is one value, M7.5 is another, etc. |
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #8 on: August 17, 2022, 03:39:35 AM »
|
|
|
Basically if you have a memory area addressable direct via DPP then the emitted compiler code is different than a fully qualified access...
I mean all this isn't too important. It's possible to detect DPP's quite well for one or the other ECU family, and if you have a close-ish A2L then you're fine.
On TriCore and PPC I have universal detection for a0-a8 and SDA/TOC, which works with pretty much any ECU out there.
But even there you have to do a lot of fine tuning, because CBOOT, SBOOT and ASW are separate applications with their own constants, and you must detect the right one...
What you want to do is possible to do, but as I said, it's a full time job to write, tweak and profile all the algorithms etc. Not to mention that you need an A2L parser, as the commercially available ones are insanely slow.
The advanced part of my logger rests on top of this capability... the thing is close to black magic and took a significant amount of effort. I would say I am about 1000 hours in.
|
|
|
|
|
Logged
|
|
|
|
marcjero
Full Member
Karma: +4/-0
Offline
Posts: 58
|
|
« Reply #9 on: August 17, 2022, 05:03:07 AM »
|
|
|
Parsing the A2L file in order to extract tables, axes, measurements ids and adresses is really not a problem.
I know that dpp0=4 and dpp1=5 for some MEG ecus and these values are shifted (+2) for others. Therefore I could just pass the dpp value as a parameter.
But this will work for the calibration data only.
You are right these adresses are not directly used in code. However (in my case) they are set in the R1 register before calling a subroutine.
Thanks for the insights.
|
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #10 on: August 18, 2022, 02:01:39 AM »
|
|
|
I know that dpp0=4 and dpp1=5 for some MEG ecus and these values are shifted (+2) for others. This just shows lack of understanding. C166 has flexible memory management. Things can be mapped to completely different addresses... It can access up to 16MB of external memory. But none of that is important for A2L matching. You need to correctly detect the global DPP settings, implement full command parsing, then you know at which location what is accessed. Then you need to mask out non-command data and match the area to a different file, and work backwards from that. This is the start, the harder part is false positive rejection. |
|
|
|
|
Logged
|
|
|
|
marcjero
Full Member
Karma: +4/-0
Offline
Posts: 58
|
|
« Reply #11 on: August 18, 2022, 03:24:33 PM »
|
|
|
I know what segmented memory management is.
These dpp values are used to access to the map constants but they are not constant.
For me it's almost impossible to track them because there are increments, shifts, stack push and pop applied in many places.
But worths to try, looks like an interesting and time consuming game.
|
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #12 on: August 20, 2022, 06:17:19 AM »
|
|
|
For me it's almost impossible to track them because there are increments, shifts, stack push and pop applied in many places. You don't need to track them everywhere. They are usually set globally and used the same way globally. You only need to track EXTP and EXTS really. As I said, this is not the hard part. |
|
|
|
|
Logged
|
|
|
|
|
