There is a dozen of map lookup functions in me7. Just identify they and you'll understand where is lookup call. Some functions use single register for address. In such case DDP approach is used. Other functions use two registers for address. In this case one register contains page offset and other - page. To get absolute address you need page * 0x4000 + offset. Also some functions pass arguments by stack. Because number of arguments is huge.

To identify axis you have to find where axis value is set. And you'll saw map lookup function call with axis value.

Some maps has size and axis before data. WinOLS automatically identify some of such bosch maps.

Python dumper for Denso SH7055 with SBL attached. The SBL sends(spams) the contents of the specified address over CAN. Fast, but in some cases there could be dropped bytes due to certain edge cases, such as entirely absent frames to a protocol error. The SBL is not aware of those and continues to send data.

The code could be optimized more by utilizing the 29 bit extended ID to cram more data, potentially getting up to 11 bytes per can message. Or it can be used a pointer to the address and contents being sent.
Further optimization could be employed similar to compressors where repeatable data is marked as <size>#repeatedbyte saving even more time, but only for very large data.

The code from 50QHHJ is different to 50WRHJ. So you still need to analyze memory variables with logger during drive. Constants are you need placed inside this function
Here is IDA project with some needed variables https://cloud.mail.ru/public/eqsu/ocRSX3WmP

i had on my drive. lmk. i didnt check it tbh

Actually I missed his zip file, rkam is a saviour I can at least label some data.

He has his ways. Has been around Volvo much longer, has better tools. Is pretty much the father of the whole volvo tuning scene.

Anyway, I am abusing the ECU a bit by writing custom interrupt routines. I have an SBL and can overwrite the internal FLASH at any point in time, but any and I mean any problem, and I am left with a bricked ECU. An alternative is to abuse the available tools, the PBL's write-what-where functions and my own custom SBL and the internal debug peripherals, such as UBC and AUD. One problem is that the reset vectors when called will disable reset the chip, reset the UBC, possibly clear out RAM and my SBL goes the way of the dodo.

When the chip is reset, it will disable AUD, we need to steer the execution such, that we skip the instruction that updates the MSTCR register. The AUD is not very powerful, but it will output every branch address and then we can correlate this with the main event loop that streams ECU data and/or handles the A6 command, although I am more interested how CAN is accessed indirectly. This technique may yet work with just UBC, but it means we have to get creative.

However there are several ways for the ECU to reset itself(I obviously cannot verify this), pointers to poweron and main are laid out in many many locations, part of function pointer tables, bypassing the VBR.

Also, no wonder the CAN registers are hidden. My own SBL when compiled with GCC had the offset "obfuscated" by taking one unrelated address, adding an absurdly large number such as 3F7C5243 producing my intended address. This had me confused for a while and running in circles debugging my code only to find out it was working just fine.

Is this the same methodology you used for my A6 param list in Denso?

I looked around and yes I see the A6 param list, but the algorithm for parameter discovery is a bit more complicated. It does not seem to be a linear table where every parameter such as 1000 then 1001 corresponds to the next function pointer. In fact parameter 1001 is further in the list than param 1005, according to your zip file.

Hehe, needlessly complicated. Look at what my GCC outputted.

Address FFFFB000. My original vector table is at address 7FC58 and it needs to lay in FFFFB000. How do we calculate the address?

We take this seemingly random constant, 0x3FF7EFA8 then we do 3FF7EFA8 + 7FC58 = 0x3FFFEC00 looks close. 0x3FFFEC00  << 2 = 0xFFFFB000.

The constant isn't random you can easily see this, but imagine this kind of code in the whole ROM. Offsets for all mmio registers are hidden like this, probably.