Custom P04 OS... going off the deep end

Disassembly, Reassembly, Tools and devleopment. Going deep with Hardware and Software.
kur4o
Posts: 948
Joined: Sun Apr 10, 2016 9:20 pm

Re: Custom OS... going off the deep end

Post by kur4o »

Some shared memory is within a8000-affff region. You can configre disassembler for such a segment, so you dont have out of range references in the code.
Cincinnatus
Posts: 305
Joined: Fri Jul 30, 2021 5:49 pm
cars: 97 Corvette
92 Camaro
2005 Silverado
2001 Savana 2500
1998 c3500hd
1998 tahoe

Re: Custom OS... going off the deep end

Post by Cincinnatus »

Thanks DWS, I appreciate you sharing your knowledge. Just wondering what your programming background is? Also wondering what the logs of hptuners or gm sps to a p04 when requesting a read or write would look like, since from reading here the struggle is to get a kernel loaded. I wish I had the equipment to log coms between devices, though I wouldn't know how to decipher what all that data meant.
Cincinnatus
Posts: 305
Joined: Fri Jul 30, 2021 5:49 pm
cars: 97 Corvette
92 Camaro
2005 Silverado
2001 Savana 2500
1998 c3500hd
1998 tahoe

Re: Custom OS... going off the deep end

Post by Cincinnatus »

Also, since you guys have figured out how the gm Motorola pcms work to a high level, wouldn't it be possible to mod the code for self tuning using a wideband input to change ve tables. Anyone figure out how hptuners utilizes rtt? It's accessing tables from PC, which could certainly be changed by an automated process (self tuning).
DWS
Posts: 129
Joined: Tue Oct 12, 2021 10:04 am
cars: Tons of Toyotas, 2003 cavi derby car, ford trucks, etc.
Location: USA
Contact:

Re: Custom OS... going off the deep end

Post by DWS »

I have zero experience with the OBD2 communication so no clue there. PCM Hammer has a log that shows a lot of hex so I suspect that's the raw communication, clearly HP Tuners has a process that works.

Programming back ground goes back to when I was about 10 years old and my mom dug up her old college books for GW Basic (1986 release date if I remember right). Later progressed up to VB6 and later VB.net. Saw all the bad comments about VB online and got over the learning curve of C#. In College I took C/C++ classes as well as C# classes as electives but the degree was for pc repair (real generic degree that says I know a little about everything on a computer). Since then I've hit php pretty hard building my own sites from the ground up for as long as I can remember and also hit mysql pretty hard. I Worked as a database administrator purely based on my hobby experience and they happened to have mssql (Microsoft SeQueL) as their main database and mysql (Free/Open Source) as a secondary.

All along the way I poked at a LOT of different langs, TI calculators in JR High, Auto It, AutoHotKey, building my own macro code, Selenium Webdriver, Java, etc. Programming kind of boils down to the VB style or C/C++ style or some combo of their styles. I've touched a little into assembly because I've always been the one to ask why and how things work. The jumps directly translated in my brain to the old GW Basic GOTO command, the rest I could kind of get but not super amazing. I later messed around with compiled Java code (Byte code) and learned how code injection worked and how to manipulate a compiled program which almost directly translates to editing the code in a PCM except the assembly language is different since it's Motorola's 68k CPU32 based instructions (for this exact PCM).

As far as hardware hacking, I've read/wrote to P11, P05, P04 via BDM, and P04 is the first one I'm digging into for modding the code and attempting a custom OS. If you haven't noticed in my background, I'm normally not scared to jump into a new thing that I'm basically clueless about. If the project is a success, great I learnt a new skill that might be valuable, if not, well I'm out some time but I still learned something and will have a better grasp what goes on at the circuit board level on a computer (or micro controller).

Custom programming in assembly is slow and painful, if it can be translated into a higher language like C or C++ and compiled then it would make things alot easier/faster. I'm not sure how the self tuning works for HP Tuners, but I suspect with the computer hooked up it might somehow read and change the tuned values in memory or it somehow references the table on the pc instead of the flash chip. It's an area that I don't 100% know how it works. Like does the cpu read the flash chip directly, or does it load the code in ram and run directly off the ram, same for looking up tables, ram based or flash based. I doubt it's writing updates to the flash chip per tweak since the flash chips generally have a write limit of about 1000 times before it's "worn out". Maybe they flash a custom OS onto the PCM to make the self tuning process work, then write the stock code and the updated tuned tables back to the flash memory. Just speculating since it's an area I'm not sure of.

I didn't mention it in my background, but I got pretty deep in network packets and looked at how some games work with their custom protocols (client to server connection, like the login process and such). The USB and also the OBD2 communication I've never seen, but I suspect it's somewhat similar. In networking there's "packets" with a header and such to describe it, it says what the length should be etc. The OBD2 is probably more strict and less flexible but it should work with packets or "frames" I'd think. You'd be looking at PC to PCM and then PCM to PC communication, so you'd be seeing both sides talking.

I put going off the deep end in the title of this thread, because that's kind of exactly what I'm doing. Everyone I've talked to that knows these at all more or less has said it's extremely hard or nearly impossible. My business is at a slow point right now, so it's something to fill my time with. Hope is I can create a new project for the derby world and I'll have a better idea how things work so a full custom OS could be on the table depending what I think of things at that point. My original logic was to modulate the code, like the transmission segment swap logic, but do that for the different temp sensor specs, map sensor, crank sensor, etc. Convert everything to some sort of standard value that the core of the OS can use. If I really got that far on a project, the concept would be that it could be edited pretty easily to make it work for another engine if all the sensor specs are known and add the new module to the collection of possible options for the os (say 7x crank sensor based vs 24x, maybe even 4cyl vs v6, cylinder degree differences etc). In my head the concept should work, but this TPU thing might be a thing that really limits this idea/concept since another platform (say P11) might be completely different so the code wouldn't translate directly to that hardware very well. If the project is a success, I'd probably be looking at making it open source since that would be a HUGE kick start for the open source side of things. Like the transmission segment swapping stuff, convert it to work with the custom os or completely rewrite it and make it an optional module to add. Add all the transmission options to this one os that can effectively run everything, then it would be kind of pointless to use the stock GM code. If I wanted to actually sell the code/os and be 100% legal (I think), I'd have to build everything myself w\o reusing code from GM. The whole OBD2 protocol would be quite a project on it's own so my concept wouldn't have any or much diag/obd2 items coded in atleast at first. It would be amazing to have it possible to port to other hardware though and blow up the tuning world for the open source side. If everyone was working with the same base OS, then special tools and such could be wrote for it as extra "modules" maybe even like the autotuner idea could be added and it could have extra supporting code running on the PCM to assist if needed. I'm sure I'm grossly underestimating a project like this which is why I'm focused on the crank sensor signal and output to the ignition module, it's basically only 2 things to figure out vs 100's for a complete os. Side benefit is if I (or anyone really) truly figures out these computers for how they work, then more options should become possible with the original OS too.

One thing in the custom OS that I'd want to do is strip down the extra tables, or atleast make it a bit simpler to work with. Most people tuning vehicles don't want or need security for example, so that code just doesn't need to exist at all (only enough to make other devices happy if anything, say the radio etc). I'd also assume that the limp modes to protect the engine would be less desired for tuners since I'd think the person tuning it doesn't want the tune tables to be over ridden while pushing the limits and pulling back some for the base tune. Maybe just a simple flag in the OS to disable that stuff and add some of it later. I'd think that would also open up the cpu to process larger tables for more boost and such as long as the supporting sensors are used. Also like the o2 sensor, the wide band I'd think could be dropped in and swap the module out and within the module it would have the calibration info for that exact sensor to make it run correctly, or the main OS reads a flag for the O2 for narrow vs wide band and changes the logic based on that.

Anyway this is all theory and educated guesses. I can't say for sure if I'll even meet my first project's goal, but with enough time and effort I'm pretty sure something like that should be possible and if opened up to the open source community, I'd think expanding it to support more advanced features would be neat as modules. Of course since it would be open source, the memory locations for the settings would be well known. I haven't dug into exactly how XDF's are made, but if they don't support segment + offset references for the memory addresses, then it probably won't work for this OS. Universal Patcher I'm sure could be made to edit the settings though, or a side project for the os would be something to assemble the modules together which clearly could add the option of changing the settings too. I think keeping settings related to a given module would be ideal so there's no conflicting addresses/settings that overlap and each segment address would just plug into the main os core for the reference. There would probably be some "global" settings required as well which would probably make sense to be within the core OS code and give a OS id number to it similar to what the stock ones have.

Btw, I normally jump into projects with no plan, just a goal in mind. The complete os project would probably need some proper planning involved and I suspect it's a years long project vs months for this crank/module project. I'd guess a team of people working together could pull something off a lot faster, but the first major step is figuring out the stock code to create custom new code. I'm told the custom os's out there is just edited stock code which is still super limiting and very "niche". Like why limit all of the dev to only v8's when neat stuff could be done with v6's too, might be a lot less demand for it, but I could see this hitting all the down into the budget cars. Ironically, I want to poke at Toyota computers too, but there's not a big need for it in the derby community, so not too much motivation on that side of things lol.

Anyway, I think that's a small peek into my mind on what I'm thinking, have to start kind of small first and no promises anything will come from this work.
Ford EEC-V Bin Converter (bank swapping and padding): viewtopic.php?f=41&t=8342
Cincinnatus
Posts: 305
Joined: Fri Jul 30, 2021 5:49 pm
cars: 97 Corvette
92 Camaro
2005 Silverado
2001 Savana 2500
1998 c3500hd
1998 tahoe

Re: Custom OS... going off the deep end

Post by Cincinnatus »

Quite the read! I programmed basic as teenager for few years, then quit computers for 10 years until a gifted windows 98 PC appeared. I haven't learned any C language, just build or upgrade PC's for people I know. I'm a repair tech of many things. Cars, PC's, plc's, HVAC, electric, plumbing, electronics, hydraulics, pneumatics, and I enjoy new challenges. I can usually make something work if it's possible to build or repair it.
The real time tuning on hptuners is a custom OS, that references the tables from the program on the laptop, that you can actively change to see the result in real time. You have to manually flash the improvements to your PCM after tuning. All that would need to be done is a wideband and/or accelerometer to alter table data to improve fueling. A custom OS wouldn't have to use same method. I'm not familiar enough with programming to be very useful. I do believe I can find a way to see the data, just wish I knew what it means. Good luck with the derby goals and we'll see what comes of this.
DWS
Posts: 129
Joined: Tue Oct 12, 2021 10:04 am
cars: Tons of Toyotas, 2003 cavi derby car, ford trucks, etc.
Location: USA
Contact:

Re: Custom OS... going off the deep end

Post by DWS »

Thanks, glad you got through the whole post xD. I generally get wordy with anything I'm passionate about.

There's several versions of basic, but assuming more of the later stuff, vb.net and C# can be directly translated from one to the other. C, C++, C# (C++ ++ aka C + 2) is more of a "strongly typed" language, same as java. Signs of that is the {} block usages and ; at the end of lines. Php is the loosest language I know of for syntax while still using the {} and ;. c and c++ are very strict with types and such, PHP just doesn't care lol. Here's a few hello world examples just to compare (I might have the vb.net one a little off, same with GW basic just for the throwback).

GW Basic (later Q Basic or quick basic)

Code: Select all

10 PRINT Hello World
run
VB.net (console program, clearly a gui/window program is different)

Code: Select all

Module Module1
    Sub Main()
        System.Console.WriteLine("Hello world")
    End Sub
End Module
C#

Code: Select all

Module Module1{
    Void Main(){
        System.Console.WriteLine("Hello world");
    }
}
I can't really give a good example in assembly since there's a LOT more to it in assembly, like if it's a micro controller with a screen, serial data communication, what exact hardware the chip is talking to, etc. Very very low level stuff. Assembly = human readable machine language. Here's someone else that shows how crazy low level control assembly is and the page explains it all so maybe you'll learn something off it. It's x86 (desktops, laptops, etc run) instead of 68k CPU32, so it's not even the same chip/lang I'm working with.

https://towardsdatascience.com/hello-wo ... da6644ff0d
Ford EEC-V Bin Converter (bank swapping and padding): viewtopic.php?f=41&t=8342
DWS
Posts: 129
Joined: Tue Oct 12, 2021 10:04 am
cars: Tons of Toyotas, 2003 cavi derby car, ford trucks, etc.
Location: USA
Contact:

Re: Custom OS... going off the deep end

Post by DWS »

@kur4o

I think I discovered what the first 256 addresses are. I thought they were some sort of interrupt, I guess the proper term is Exception Vector. Here's the table of the first 256 addresses in the flash. In this exact OS, the list continues after 16 addresses then at $440 is where code starts. This table is found in the CPU32 Reference Manual.

I see there's a section dedicated for a coprocessor (not labeled as a slave cpu which is interesting), but my bin file has the same generic handler assigned for all of them in that section.

Image

Also this is an interesting area. I use ulink so I don't think I get super amazing control with the BDM, but it sounds like I can potentially set break points in memory, let the cpu run until it hits the break point and have atleast some level of ability to debug new code. I know I can peek and poke memory addresses and see registrars and such in memory, step through cpu instructions, etc. Maybe setting break points is possible to catch so timing and such shouldn't be a problem, but hard to say for sure with out actually testing it. Still just reading and learning, naming ram addresses etc.
Breakpoint Instruction — An emulator can insert software breakpoints into target
code to indicate when a breakpoint occurs. On the MC68010, MC68020,
MC68030, and CPU32, this function is provided via illegal instructions ($4848–
$484F) that serve as breakpoint instructions. See 6.2.5 Software Breakpoints for
more information.
Ford EEC-V Bin Converter (bank swapping and padding): viewtopic.php?f=41&t=8342
User avatar
antus
Site Admin
Posts: 8238
Joined: Sat Feb 28, 2009 8:34 pm
cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Contact:

Re: Custom OS... going off the deep end

Post by antus »

This is the datasheet for the TPU from MPC500_M68300_CD_ZIP.zip which is the information about the platform from Motorola. This link will probably die over time but the whole documentation kit is here: https://www.nxp.com/docs/en/data-sheet/ ... CD_ZIP.zip Look in MPC500_M68300_CD_ZIP\MC683XX\mc68332\*
When you see 'many' interrupts pointing to the same place its probably because they are not used, and the code is likely something that just resets the PCM with a certain error code. in IDA you can go to that address, hit 'c' to change it too code, hit 'P' to make it a function and you'll probably only see a small amount of code there common to all the unused interrupts. I believe there is a ram location that holds a code from the watchdog last time it restarted, so I think it would likely do something like copy a value to that ram location then go in to an infinite loop to trigger a reset.
Attachments
c7tpu.pdf
(174.8 KiB) Downloaded 134 times
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
DWS
Posts: 129
Joined: Tue Oct 12, 2021 10:04 am
cars: Tons of Toyotas, 2003 cavi derby car, ford trucks, etc.
Location: USA
Contact:

Re: Custom OS... going off the deep end

Post by DWS »

That documentation kit has helped a lot for labeling addresses and trying to make sense of things. I suspect the TPU is in emulation mode to run custom microcode, I haven't quite gotten that far yet though.

Couple interesting things I found that I don't quite understand 100% (well there's a lot of that but it's been slowly clearing up as I read more lol).

The IAT and ECT values in memory ultimately come from the QSM Receive RAM addresses. I haven't cross checked if the settings are the same across OS's but here's what I have currently. I have all Transmit and Command RAM addresses labeled in the code but haven't back tracked to figure out how the code uses them. I have been able to label a few functions though and it seems to make sense following the program flow via BDM.

$FFFFFD19 - IAT
$FFFFFD1D - ECT

Talking about the BDM, on my PCM if I step it through far enough, it hits an inf loop at $3010-301C. The decomplier couldn't handle the code, D5 holds $F and stepping through the program I see D3 also ends up as $F (raw value is $002F before the bit masking). I read a bit on the register and it seems like the HALTA bit is set which flags when SPCR3 HALT bit is set. I haven't back traced to see where that gets set and why, but that seems to be as far as the BDM route can go in the code before it gets stuck.

Image

Since I'm also building stand alone harnesses for these cars, I had the connectors and terminals to build a more proper bench harness. I'm hoping I can figure out how this works on the hardware side enough to either send a pulse on the ignition module control pin, or even as simple as turning the fan1 pin on.

Some other area's of memory that are points of interest....

FFFFE0C8 relates to RPM, I'm guessing it's some sort of time based value based on last crank pulse signal
I've seen the Exxx addresses a fair amount, I'm guessing that might be to an external chip.

FFFFA790 and FFFFA791 relates to Fan1 and Fan2. It seems to be bit sets and I haven't quite figured out 100% what the bits do. I've seen the Axxx adresses quite a lot through the code though.

Am I on the right track that those addresses might be to external chips?

I've also labeled the TPU addresses, but besides the setup code I haven't seen them pop up yet.

Still a lot of digging to do, but here's some code I've labeled. TPU Setup code (there's more in assembly the decompiler couldn't handle at the while loop). Below that is what seems to be a sensor setup/read code (QSM receive addresses into temp vars depending on a "mode" setting). You can see the IAT and ECU references I've traced back. Would be interesting to figure the other ones out. The MAP sensor code I don't fully get, I have a few addresses that I think are related to MAP, but I've seen one of them pop up for controlling the fans which seems a bit odd, maybe fan off if floored type of logic since alternator turns off too.

I've been focusing mainly on the setup code since that's my main area of interest atm. I also would like to be able to edit the program in memory so I can debug/test ideas in BDM and be able to see what's going on. Is there a known way to have control over the current pointer/line the program is at? I probably should dig into the BDM section of the documentation again. Hopefully this info is atleast interesting to you guys.

Code: Select all

/* WARNING: Removing unreachable block (ram,0x000010d6) */
/* WARNING: Removing unreachable block (ram,0x000010ee) */
/* WARNING: Removing unreachable block (ram,0x000010f4) */
/* WARNING: Globals starting with '_' overlap smaller symbols at the same address */

undefined4 Setup_TPU(void)

{
  FUN_00000ef2();
  _TPU_Config_Register = 0x6003;
  _TPU_Interrupt_Config_Register = 0x650;
  _TPU_Channel_Priority_Register_0 = 0;
  _TPU_Channel_Function_Sel_Reg_2 = 0x66ef6754;
  _TPU_Channel_Function_Sel_Reg_0 = 0xba666766;
  _TPU_C15_P0 = 0x700;
  _TPU_C15_P2 = 0xf4;
  _TPU_C14_P0 = 0x700;
  _TPU_C14_P2 = 0xf4;
  _TPU_C13_P0 = 0xfc93;
  _TPU_C13_P2 = 0;
  _TPU_C12_P0 = 0xfc93;
  _TPU_C12_P2 = 0;
  _TPU_C11_P0 = 0xfcf3;
  _TPU_C11_P2 = 0;
  _TPU_C10_P0 = 0xfc0f;
  _TPU_C9_P0 = 0xfc93;
  _TPU_C9_P2 = 0;
  _TPU_C8_P0 = 0xfc93;
  _TPU_C8_P2 = 0;
  _TPU_C7_P0 = 0xfc93;
  _TPU_C7_P2 = 0;
  _TPU_C6_P0 = 0xfc93;
  _TPU_C6_P2 = 0;
  _TPU_C5_P0 = 0xfc93;
  _TPU_C5_P2 = 0xff584a48;
  FUN_00001102();
  do {
  } while( true );
}

Code: Select all

byte SetUp_Sensors(void)

{
  byte in_D0b;
  undefined4 uVar1;
  undefined4 in_stack_00000000;
  
  if (in_D0b == 0) {
    Source_QSM_R_FD01_3 = QSM_R_FD01;
    Source_QSM_R_FD03_3 = QSM_R_FD03;
    Source_QSM_R_FD05_3 = QSM_R_FD05;
    Source_QSM_R_FD07_3 = QSM_R_FD07;
    Source_QSM_R_FD09_3 = QSM_R_FD09;
    Source_QSM_R_FD0B_3 = QSM_R_FD0B;
    Source_QSM_R_FD0D_3 = QSM_R_FD0D;
    Source_QSM_R_FD0F_3 = QSM_R_FD0F;
  }
  else {
    if (in_D0b == 1) {
      if (QSM_R_Address_Select == 1) {
        Source_QSM_R_FD13_1_or_4 = QSM_R_FD13;
        Source_QSM_R_FD15_1_or_4 = QSM_R_FD15;
        Source_QSM_R_FD17_1_or_4 = QSM_R_FD17;
        IAT_Source_1_or_4 = IAT_QSM_R_FD19;
        Source_QSM_R_FD1B_1_or_4 = QSM_R_FD1B;
        ECT_1_or_4 = ECT_QSM_R_FD1D;
        Source_QSM_R_FD1F_1_or_4 = QSM_R_FD1F;
      }
    }
    else {
      if (in_D0b == 2) {
        if (QSM_R_Address_Select == 2) {
          Source_QSM_R_FD13_2_or_5 = QSM_R_FD13;
          Source_QSM_R_FD15_2_or_5 = QSM_R_FD15;
          Source_QSM_R_FD17_2_or_5 = QSM_R_FD17;
          IAT_Source_2_or_5 = IAT_QSM_R_FD19;
          Source_QSM_R_FD1B_2_or_5 = QSM_R_FD1B;
          ECT_2_or_5 = ECT_QSM_R_FD1D;
          Source_QSM_R_FD1F_2_or_5 = QSM_R_FD1F;
        }
      }
      else {
        if (in_D0b == 3) {
          if (QSM_R_Address_Select == 3) {
            Source_QSM_R_FD13_3 = QSM_R_FD13;
            Source_QSM_R_FD15_3 = QSM_R_FD15;
            Source_QSM_R_FD17_3 = QSM_R_FD17;
            IAT_Source_3 = IAT_QSM_R_FD19;
            Source_QSM_R_FD1B_3 = QSM_R_FD1B;
            ECT_3 = ECT_QSM_R_FD1D;
            Source_QSM_R_FD1F_3 = QSM_R_FD1F;
            Source_QSM_R_FD01_3 = QSM_R_FD01;
            Source_QSM_R_FD03_3 = QSM_R_FD03;
            Source_QSM_R_FD05_3 = QSM_R_FD05;
            Source_QSM_R_FD07_3 = QSM_R_FD07;
            Source_QSM_R_FD09_3 = QSM_R_FD09;
            Source_QSM_R_FD0B_3 = QSM_R_FD0B;
            Source_QSM_R_FD0D_3 = QSM_R_FD0D;
            Source_QSM_R_FD0F_3 = QSM_R_FD0F;
          }
        }
        else {
          if (in_D0b == 4) {
            if (QSM_R_Address_Select == 4) {
              _Source_QSM_R_FD12_4 = _QSM_R_FD12;
              _Source_QSM_R_FD14_4 = _QSM_R_FD14;
              _Source_QSM_R_FD1A_4 = _QSM_R_FD1A;
              if (QSM_R_Address_Select_B == '\0') {
                Source_QSM_R_FD16|FD17_4 = QSM_R_FD17;
              }
              else {
                Source_QSM_R_FD16|FD17_4 = QSM_R_FD16;
                Source_QSM_R_FD17_4B = QSM_R_FD17;
              }
              _Source_QSM_R_FD18_4 = _QSM_R_FD18;
            }
          }
          else {
            if ((in_D0b == 5) || (in_D0b == 6)) {
              if (in_D0b == QSM_R_Address_Select) {
                _Source_QSM_R_FD12_5|6 = _QSM_R_FD12;
                _Source_QSM_R_FD14_5|6 = _QSM_R_FD14;
              }
            }
            else {
              if (((in_D0b != 7) && (in_D0b != 8)) && (in_D0b != 9)) {
                if (in_D0b == 10) {
                  if (QSM_R_Address_Select == 10) {
                    Source_QSM_R_FD11_10 = QSM_R_FD11;
                    Source_QSM_R_FD13_10 = QSM_R_FD13;
                    Source_QSM_R_FD15_10 = QSM_R_FD15;
                    DAT_ffff8eb1 = DAT_ffff8eb1 & 0xbf;
                    SIM_Port_F_Data = SIM_Port_F_Data & 0xbf;
                  }
                }
                else {
                  uVar1 = FUN_000004fe(in_stack_00000000);
                  in_D0b = (byte)uVar1;
                }
              }
            }
          }
        }
      }
    }
  }
  return in_D0b;
}
Image
Ford EEC-V Bin Converter (bank swapping and padding): viewtopic.php?f=41&t=8342
DWS
Posts: 129
Joined: Tue Oct 12, 2021 10:04 am
cars: Tons of Toyotas, 2003 cavi derby car, ford trucks, etc.
Location: USA
Contact:

Re: Custom OS... going off the deep end

Post by DWS »

Small progress, I think I can fully use most/all of the potential of the BDM interface now. Last thing I figured out was how to set code into ram and force the program to jump to that segment of ram. This means I can make test code, throw it in ram and perform unlimited number of tests, flashing the flash chip wears it out after roughly 1000 flashes so I didn't want to go that route. I just need to find a section of ram that's not used, or atleast not used in the code I'm looking to test. I was able to get past the inf loop as well for the 3010 function, it seems like if it step through it, it works fine, if I do say T 10000 it gets stuck for some reason.

Since the coding side of things I'm super new to the hardware programming, I've found the IAT and ECT sensors which are part of the QSM receive ram, so if I setup the QSM registers correctly, wait for the status registers, etc I should be able to read the resistor I added on them. There's a lookup table for reading vs temp output. I don't 100% understand how the command works (TBLS and TBLU), but I have a vague idea what it's trying to do, I'd like to be able to take an input with the known lookup table and calculate the same value I see in memory. Since I can write code to ram and test things, maybe I can poke at it a bit more some time when I really need to understand the table lookup functions.

Besides reading inputs, I need to figure out atleast one output so I can run the code in real time and say have a PWM signal light up an LED based on IAT reading as a proof of my code working.

Anyway, I've mainly focused on how chips are setup, how they are read, etc. The internal stuff on the CPU is reasonable, but the other chips on the board is where the fun truly is lol. I did some tracing and have a rough idea what the chips are/do for some of them. The one labeled as 87847 seems to be a stepper motor controller. The IAC A and B high lines connect to the driver, and I've traced 3 of the pins to the 87847 chip. I haven't quite made sense of the IAC code, so not sure what address range the control is at.

For the temp sensors, I did trace one to the chip labeled as 16238528 which I'm guessing is the Analog to Digital converter. It seems the QSM reads it as serial data from that chip and is received in the ram addresses blow (I think I mentioned them before).

FFFFFD19 - IAC
FFFFFD1D - ECT

The reading from those addresses gets converted using that TBLS command with these two table locations below. Both tables are 17 items long and appear to use the same conversion math (the min/max values are effectively the same).

0006EDDA - IAT
0001C012 - ECT (labeled as ECT Temp vs Voltage in Universal Patcher)

From the little I've seen while digging through the bin and stepping through the setup functions and such, it seems like there's around 3 or so memory ranges used that I think must be the other chips. I don't 100% understand how chip select works, but it seems like once the registers are setup, they are controlled purely through those addresses.

Hopefully my next update will have a nice success story reading sensors from more or less completely fresh code.
Ford EEC-V Bin Converter (bank swapping and padding): viewtopic.php?f=41&t=8342
Post Reply