Electronic Fuel Injection - Developement & Tuning
https://pcmhacking.net/forums/
I'll probably have a little time this weekend, I didn't end up with a brick yet so I'll volunteer to try 01 if you can tell me which one to try? or where? or which calibration, lol...gmtech825 wrote:ironduke wrote:So is this possible some sort of scaler that was mentioned earlier??
Btw, loving this discussion, showing me how much I am lacking... lol..
yeah exactly. I found one value that looks very interesting. It is 0x0A in the calibration, then is multiplied by 0x14, then divided by 0x14...so essentially it is still 0x0A = 10.
that value (10) gets moved to a ram location, then compared to see if it is <= to another ram value which is incremented by 1 (engine run timer maybe) and seems to trace back to my original function that checks the remote start enable byte.
it requires way more investigation...or maybe I'll change that value and see what happens when I finally get some time.
that byte was in the system segment. I gave it shot last night but no luck...I feel like I'm getting close though. I'm only writing the cal segments not the OS so hopefully that reduces the risk of bricking.ironduke wrote:
I'll probably have a little time this weekend, I didn't end up with a brick yet so I'll volunteer to try 01 if you can tell me which one to try? or where? or which calibration, lol...
someone created a fujitsu processor module that I found. it does have some errors so that might be part of my problem. My file is set up basically the same as irondukes. I have 0xff in the empty areas where ironduke has 0x00.Tazzi wrote:gmtech825, what processor are you selecting in Ghidra? When I tried using one of the RSIC options (For fujitsu), it wasnt disassembling nicely. Well that was on irondukes file he uploaded with all cals implemented.
Code: Select all
void UndefinedFunction_000c49be(void)
{
int in_r13;
/* WARNING: Could not recover jumptable at 0x000c49c6. Too many branches */
/* WARNING: Treating indirect jump as call */
(*(code *)(&switchD_000c49c6::switchdataD_000fa390)[in_r13])();
return;
}oof...there's a whole lot of jumping around for sure.Tazzi wrote:Ill need to read the opcode definitions to understand better.
But it looks like it loads the value FA390 into r12, shifts r13 left by 2 (we do not know the value of r13) then loads data from address (r13+r12) into r12
Then it jumps to the address saved at location r12.
Its a bit of a roundabout way of doing it all. Im pretty sure the '@' sign is being used as a pointer. Meaning you need to look at the address that is saved in that register.