RomRaider Logo

RomRaider

Open Source ECU Tools
 FAQ •  Register •  Login 

RomRaider

Documentation

Community

Developers

It is currently Sat Feb 21, 2026 9:58 pm

All times are UTC




Post new topic Reply to topic  [ 42 posts ]  Go to page 1, 2, 3  Next
Author Message
 Post subject: CEL Flashing as warning for knock, lean condition, etc.
PostPosted: Tue Oct 25, 2011 5:39 am 
Offline
Experienced
User avatar

Joined: Thu Jul 23, 2009 5:46 pm
Posts: 863
So, I've located the IO ports for the CEL and cruise lights on my ecu (a8dh20*x).

Locating the CEL/cruise light ports is pretty easy to do by hijacking an existing SSM routine. Thanks to Mart and acamus.

After opening the rom in IDA and identifying all the SSM routines with XMLtoIDC, find the cylinder roughness PtrSSMget subroutines.
Code:
ROM:0004F0F0 SsmGet_Roughness_Monitor_Cylinder_1_P63:
ROM:0004F0F0                                         ; DATA XREF: ROM:PtrSsmGet_Roughness_Monitor_Cylinder_1_P63o
ROM:0004F0F0                 mov.l   #unk_FFFF8C5D, r3
ROM:0004F0F2                 rts
ROM:0004F0F4                 mov.b   @r3, r0
ROM:0004F0F6 ; ---------------------------------------------------------------------------
ROM:0004F0F6
ROM:0004F0F6 SsmGet_Roughness_Monitor_Cylinder_2_P64:
ROM:0004F0F6                                         ; DATA XREF: ROM:PtrSsmGet_Roughness_Monitor_Cylinder_2_P64o
ROM:0004F0F6                 mov.l   #unk_FFFF8C5E, r3
ROM:0004F0F8                 rts
ROM:0004F0FA                 mov.b   @r3, r0
ROM:0004F0FC ; ---------------------------------------------------------------------------


Highlight the ram location FFFF8C5D and scroll down to find it in ROM:

Code:
ROM:0004F1C4 off_4F1C4:      .data.l unk_FFFF8C5D    ; DATA XREF: ROM:SsmGet_Roughness_Monitor_Cylinder_1_P63r
ROM:0004F1C8 off_4F1C8:      .data.l unk_FFFF8C5E    ; DATA XREF: ROM:SsmGet_Roughness_Monitor_Cylinder_2_P64r


Then open the rom in a hex editor, and move to those locations (0x4F1C4, 0x4F1C8).

Replace these ram locations with the Port address from the renesas manual for your ecu (sh7058 in this case)

Code:
H'FFFFF746 — — PD13DR PD12DR PD11DR PD10DR PD9DR PD8DR
H'FFFFF747
PDDR
PD7DR PD6DR PD5DR PD4DR PD3DR PD2DR PD1DR PD0DR


Since the hijacked SSM routines only return bytes, and the P*DR (Port * data register) is 2 bytes in length, you have to use two SSM routines to read the entire port.

After replacing the addresses with the P*DR you want to examine, open the rom in ECUflash or RR to fix the checksum, and flash.

The cruise light can be observed by simply pressing the cruise button.

To observe both CEL and cruise lights in action:
Start the car, and begin logging the SSM parameters you changed
Pop the hood, and unplug the BCS solenoid
Stop logging, examine the logs.

It's best to use two separate CEL triggers to be sure you aren't seeing the pin state of the BCS or whatever else you're using to trigger a CEL. Ie, first try the BCS, then reset and try something else like an air pump, evap solenoid, maf, etc.

As you can see in the attached image, the cel light matches up with roughness monitor 2 (byte 2 of PDDR) changing by d'128 = h'80 = MSB of the second byte of PDDR (PD7DR in the manual), and the flashing cruise light matches up with roughness monitor 3 (byte 1 of PEDR) changing by d'2 = h'02 = bit 1 of the first byte of PEDR (PE9DR).

Now, after examining the logic that triggers these lights, I found two different styles. To find usage of P*DR, you need to perform a byte sequence search in IDA for the last word of the port address (F754 for 0xFFFFF754 = PEDR). High rom usage is usually for CEL triggers, check pin states, if they're bad, call CEL_EVAL routine. Lower rom usage contains the writes.

The first style looks like an initialization, with no fancy business messing with the status register SR, also seems to agree with the CEL being on with the key at 'on'.

Code:
ROM:00005100 SBR_CEL_Light_2_ign_on?:                ; CODE XREF: ROM:00004C0Ep
ROM:00005100                 mov.w   #h'5100, r3
ROM:00005102                 mov.w   #PortA_PADR_W, r2
ROM:00005104                 mov.w   r3, @r2
ROM:00005106                 mov.l   #off_E500, r1
ROM:00005108                 mov.w   #PortB_PBDR_W, r0
ROM:0000510A                 mov.w   r1, @r0
ROM:0000510C                 mov.w   #PortC_PCDR_W, r1
ROM:0000510E                 mov     #5, r3
ROM:00005110                 mov.w   r3, @r1
ROM:00005112                 mov.w   #h'1887, r2     ; CEL BIT HIGH, for ignition on???
ROM:00005114                 mov.w   #PortD_PDDR_W, r3
ROM:00005116                 mov.w   r2, @r3
ROM:00005118                 mov.w   #h'761, r0
ROM:0000511A                 mov.w   #PortE_PEDR_W, r2 ; Cruise light off
ROM:0000511C                 mov.w   r0, @r2
ROM:0000511E                 mov     #0, r4
ROM:00005120                 add     #h'10, r1
ROM:00005122                 mov.w   r4, @r1
ROM:00005124                 add     #h'1E, r3
ROM:00005126                 mov.w   r4, @r3
ROM:00005128                 mov.w   #PortH_PHDR_W, r0
ROM:0000512A                 mov     #1, r2
ROM:0000512C                 mov.w   r2, @r0
ROM:0000512E                 mov.w   #h'C7, r1 ; '¦'
ROM:00005130                 mov.w   #PortJ_PJDR_W, r2
ROM:00005132                 mov.w   r1, @r2
ROM:00005134                 add     #h'14, r3
ROM:00005136                 mov.w   r4, @r3
ROM:00005138                 mov.w   #h'540, r1
ROM:0000513A                 add     #h'32, r0 ; '2'
ROM:0000513C                 rts
ROM:0000513E                 mov.w   r1, @r0
ROM:0000513E ; End of function SBR_CEL_Light_2_ign_on?


The second makes some changes to the status register SR, specifically bits 4-7 (interrupt mask bits).

Code:
ROM:0001CBB2 LOC_Cruise_Light_1:                     ; CODE XREF: sub_1C9F0+16Cj
ROM:0001CBB2                                         ; sub_1C9F0+176j ...
ROM:0001CBB2                 mov     r15, r4
ROM:0001CBB4                 mov.l   #sub_2088, r2
ROM:0001CBB6                 mov.w   #h'E0, r5 ; 'a'
ROM:0001CBB8                 jsr     @r2 ; sub_2088
ROM:0001CBBA                 add     #4, r4
ROM:0001CBBC                 mov.l   #sub_4AE4, r12
ROM:0001CBBE                 mov     r14, r0
ROM:0001CBC0                 mov.w   #h'100, r5      ; changes bit 8
ROM:0001CBC2                 mov.w   #PortE_PEDR_W, r13
ROM:0001CBC4                 mov.b   @r0, r0
ROM:0001CBC6                 tst     #h'80, r0
ROM:0001CBC8                 movt    r6
ROM:0001CBCA                 jsr     @r12 ; sub_4AE4
ROM:0001CBCC                 mov     r13, r4
ROM:0001CBCE                 mov.l   #sub_2098, r3
ROM:0001CBD0                 jsr     @r3 ; sub_2098
ROM:0001CBD2                 mov.l   @(4,r15), r4
ROM:0001CBD4                 mov.w   #h'E0, r5 ; 'a'
ROM:0001CBD6                 mov.l   #sub_2088, r2
ROM:0001CBD8                 jsr     @r2 ; sub_2088
ROM:0001CBDA                 mov     r15, r4
ROM:0001CBDC                 mov.w   #h'200, r5      ; changes bit 9 CRUISE BIT
ROM:0001CBDE                 mov     r14, r0
ROM:0001CBE0                 mov.b   @r0, r0
ROM:0001CBE2                 tst     #h'40, r0
ROM:0001CBE4                 movt    r6
ROM:0001CBE6                 jsr     @r12 ; sub_4AE4
ROM:0001CBE8                 mov     r13, r4
ROM:0001CBEA                 mov.l   #sub_2098, r3
ROM:0001CBEC                 jsr     @r3 ; sub_2098
ROM:0001CBEE                 mov.l   @r15, r4
ROM:0001CBF0                 add     #h'1C, r15
ROM:0001CBF2                 lds.l   @r15+, pr
ROM:0001CBF4                 mov.l   @r15+, r10
ROM:0001CBF6                 mov.l   @r15+, r11
ROM:0001CBF8                 mov.l   @r15+, r12
ROM:0001CBFA                 mov.l   @r15+, r13
ROM:0001CBFC                 rts
ROM:0001CBFE                 mov.l   @r15+, r14
ROM:0001CBFE ; End of function sub_1C9F0


First, sub_2088 is called, which sets the interrupt priority to the value of incoming r5 most significant nibble (h'E in this case) or higher, and stores the old SR (containing interrupt mask bits only) @r4 on the stack.

Code:
ROM:00002088 ; =============== S U B R O U T I N E =======================================
ROM:00002088
ROM:00002088
ROM:00002088 sub_2088:                               ; CODE XREF: sub_4E90+52p
ROM:00002088                                         ; sub_4E90+B2p ...
ROM:00002088                 stc     sr, r0
ROM:0000208A                 and     #h'F0, r0
ROM:0000208C                 cmp/hs  r0, r5
ROM:0000208E                 bt/s    locret_2094
ROM:00002090                 mov.l   r0, @r4
ROM:00002092                 mov     r0, r5
ROM:00002094
ROM:00002094 locret_2094:                            ; CODE XREF: sub_2088+6j
ROM:00002094                 rts
ROM:00002096                 ldc     r5, sr
ROM:00002096 ; End of function sub_2088
ROM:00002096


Then sub_4AE4 is called, which writes to the P*DR based on inputs r5 (bitmask - selects which bit is written) and r6 (and / or, selects to write the bit 0 or 1)

Code:
ROM:00004AE4 ; =============== S U B R O U T I N E =======================================
ROM:00004AE4
ROM:00004AE4
ROM:00004AE4 sub_4AE4:                               ; CODE XREF: ROM:00006AE6p
ROM:00004AE4                                         ; ROM:00006AFCp ...
ROM:00004AE4                 mov.w   #h'E0, r3 ; 'a'
ROM:00004AE6                 stc     sr, r2
ROM:00004AE8                 ldc     r3, sr
ROM:00004AEA                 extu.w  r6, r6
ROM:00004AEC                 mov.w   @r4, r3
ROM:00004AEE                 tst     r6, r6
ROM:00004AF0                 bf      loc_4AFC
ROM:00004AF2                 not     r5, r5
ROM:00004AF4                 and     r5, r3
ROM:00004AF6                 mov.w   r3, @r4
ROM:00004AF8                 rts
ROM:00004AFA                 ldc     r2, sr
ROM:00004AFC ; ---------------------------------------------------------------------------
ROM:00004AFC
ROM:00004AFC loc_4AFC:                               ; CODE XREF: sub_4AE4+Cj
ROM:00004AFC                 or      r5, r3
ROM:00004AFE                 mov.w   r3, @r4
ROM:00004B00                 rts
ROM:00004B02                 ldc     r2, sr
ROM:00004B02 ; End of function sub_4AE4


Then, the old SR (only containing interrupt mask bits) is restored from the stack.

Code:
ROM:00002098 ; =============== S U B R O U T I N E =======================================
ROM:00002098
ROM:00002098
ROM:00002098 sub_2098:                               ; CODE XREF: sub_4E90+88p
ROM:00002098                                         ; sub_4E90+C8p ...
ROM:00002098                 rts
ROM:0000209A                 ldc     r4, sr
ROM:0000209A ; End of function sub_2098


According to the manual:

Code:
6.4.3 Interrupt Exception Processing
When an interrupt occurs, its priority level is ascertained by the interrupt controller (INTC). NMI
is always accepted, but other interrupts are only accepted if they have a priority level higher than
the priority level set in the interrupt mask bits (I3–I0) of the status register (SR).
When an interrupt is accepted, exception processing begins. In interrupt exception processing, the
CPU saves SR and the program counter (PC) to the stack. The priority level value of the accepted
interrupt is written to SR bits I3–I0. For NMI, however, the priority level is 16, but the value set in
I3–I0 is H'F (level 15). Next, the start address of the exception service routine is fetched from the
exception processing vector table for the accepted interrupt, that address is jumped to and
execution begins. See section 7.4, Interrupt Operation, for further details.


So, its basically blocking out certain interrupts during the write, but also clearing the rest of the SR (true bit, other stuff used by math instructions).


You do not have the required permissions to view the files attached to this post.

_________________
Please do not send me support questions via PM, use the forum instead!


Last edited by Merp on Wed Oct 26, 2011 1:15 am, edited 1 time in total.

Top
 Profile  
 
 Post subject: Re: CEL Flashing as warning for knock, lean condition, etc.
PostPosted: Tue Oct 25, 2011 6:51 am 
Offline
Moderator

Joined: Thu Nov 23, 2006 2:23 am
Posts: 2565
Awesome!

_________________
2005 Legacy GT w/ ATP 3076, IWG, MBC, BCS, BC 272, LC, FFS, OMG
Please don't send questions via PM. Post a thread and send me a link to it instead. Thanks!


Top
 Profile  
 
 Post subject: Re: CEL Flashing as warning for knock, lean condition, etc.
PostPosted: Tue Oct 25, 2011 11:33 am 
Offline
Experienced

Joined: Sun Jun 01, 2008 2:14 am
Posts: 125
Location: Quebec
Sorry about that, I forgot that detail in our discussion. But obviously, you dont need me :)

awesome!

Mart

Quote:
Since the hijacked SSM routines only return bytes, and the P*DR (Port * data register) is 2 bytes in length, you have to use two SSM routines to read the entire port.


Top
 Profile  
 
 Post subject: Re: CEL Flashing as warning for knock, lean condition, etc.
PostPosted: Sun Nov 06, 2011 9:52 pm 
Offline
Experienced
User avatar

Joined: Thu Jul 23, 2009 5:46 pm
Posts: 863
Located the CEL routine used by the high-level software logic, and it uses a RAM switch.

Looks like the RAM switch has a bunch of provisions to automatically reset (turn off CEL), so we'll have to change the RAM reference and test the old one in the knock/overboost/lean CEL trigger routine, or just copy the whole routine and use a new RAM switch.


Code:
ROM:0008C1FC ; =============== S U B R O U T I N E =======================================
ROM:0008C1FC
ROM:0008C1FC
ROM:0008C1FC SBR_CEL_Light_Trigger:                  ; CODE XREF: SBR_CEL_EVAL_JUMPS+Ap
ROM:0008C1FC
ROM:0008C1FC var_14          = -h'14
ROM:0008C1FC
ROM:0008C1FC                 mov.l   r14, @-r15
ROM:0008C1FE                 mov.l   r13, @-r15
ROM:0008C200                 mov.l   r12, @-r15
ROM:0008C202                 sts.l   pr, @-r15
ROM:0008C204                 mov.l   #sub_4AE4, r12
ROM:0008C206                 add     #-8, r15        ; jump off of stack 0x8
ROM:0008C208                 mov.w   #PortD_PDDR_W, r13
ROM:0008C20A                 mov.w   #h'80, r14 ; 'Ç'
ROM:0008C20C                 mov.l   #E_CEL_Trigger_Bit0_high_FFFF930E, r3
ROM:0008C20E                 mov.b   @r3, r0
ROM:0008C210                 extu.b  r0, r0
ROM:0008C212                 cmp/eq  #1, r0
ROM:0008C214                 bf/s    loc_8C22E       ; branch if 930E is zero
ROM:0008C216                 nop
ROM:0008C218                 mov.w   #h'E0, r5 ; 'a' ; SR mask
ROM:0008C21A                 mov     r15, r4         ; current stack location
ROM:0008C21C                 mov.l   #SBR_StatusReg_IntMask, r1 ; set SR interrupt masks to r5 or higher, old SR @r4
ROM:0008C21C                                         ;
ROM:0008C21E                 jsr     @r1 ; SBR_StatusReg_IntMask ; set SR interrupt masks to r5 or higher, old SR @r4
ROM:0008C21E                                         ;
ROM:0008C220                 add     #4, r4          ; go back down 0x4 on stack
ROM:0008C222                 mov     #1, r6
ROM:0008C224                 mov     r14, r5         ; h'80 -> r5
ROM:0008C226                 jsr     @r12 ; sub_4AE4
ROM:0008C228                 mov     r13, r4
ROM:0008C22A                 bra     loc_8C240
ROM:0008C22C                 mov.l   @(4,r15), r4
ROM:0008C22E ; ---------------------------------------------------------------------------
ROM:0008C22E
ROM:0008C22E loc_8C22E:                              ; CODE XREF: SBR_CEL_Light_Trigger+18j
ROM:0008C22E                 mov.w   #h'E0, r5 ; 'a' ; SR mask
ROM:0008C230                 mov.l   #SBR_StatusReg_IntMask, r1 ; set SR interrupt masks to r5 or higher, old SR @r4
ROM:0008C230                                         ;
ROM:0008C232                 jsr     @r1 ; SBR_StatusReg_IntMask ; set SR interrupt masks to r5 or higher, old SR @r4
ROM:0008C232                                         ;
ROM:0008C234                 mov     r15, r4
ROM:0008C236                 mov     #0, r6          ; same as above, only opposite signal here
ROM:0008C238                 mov     r14, r5
ROM:0008C23A                 jsr     @r12 ; sub_4AE4
ROM:0008C23C                 mov     r13, r4
ROM:0008C23E                 mov.l   @r15, r4
ROM:0008C240
ROM:0008C240 loc_8C240:                              ; CODE XREF: SBR_CEL_Light_Trigger+2Ej
ROM:0008C240                 mov.l   #SBR_SR_Restore, r3 ; load r4 -> SR, rts
ROM:0008C242                 jsr     @r3 ; SBR_SR_Restore ; load r4 -> SR, rts
ROM:0008C244                 nop
ROM:0008C246                 add     #8, r15
ROM:0008C248                 lds.l   @r15+, pr
ROM:0008C24A                 mov.l   @r15+, r12
ROM:0008C24C                 mov.l   @r15+, r13
ROM:0008C24E                 rts
ROM:0008C250                 mov.l   @r15+, r14
ROM:0008C250 ; End of function SBR_CEL_Light_Trigger
ROM:0008C250

_________________
Please do not send me support questions via PM, use the forum instead!


Top
 Profile  
 
 Post subject: Re: CEL Flashing as warning for knock, lean condition, etc.
PostPosted: Thu Nov 10, 2011 4:41 am 
Offline
Experienced
User avatar

Joined: Thu Jul 23, 2009 5:46 pm
Posts: 863
Beta test is working :mrgreen:

Currently running single flash for low IAM, two flashes for overboost, three flashes for overboost + lean, and four flashes for FBKC. Might implement a recall feature to display the last warning.

The CEL_Light_Trigger routine has to be called every time the cel is toggled, as it is normally only called when a cel is first activated.

Time to get the cruise light flashing for a shift light :)

_________________
Please do not send me support questions via PM, use the forum instead!


Top
 Profile  
 
 Post subject: Re: CEL Flashing as warning for knock, lean condition, etc.
PostPosted: Thu Nov 10, 2011 7:55 am 
Offline
Moderator

Joined: Thu May 20, 2010 8:01 am
Posts: 3117
Location: Johannesburg, South Africa
Awesome work! Can't wait to try this out.

Donation sent ;)

_________________
He who dies with the most gadgets wins.

Please do not PM me - use the email option.


Top
 Profile  
 
 Post subject: Re: CEL Flashing as warning for knock, lean condition, etc.
PostPosted: Thu Nov 10, 2011 9:14 am 
Offline
Moderator

Joined: Thu Nov 23, 2006 2:23 am
Posts: 2565
Before I go tweaking my roughness monitor SSM routines, I have to wonder, has anyone found the code that implements the SSM 'read byte' command? Because what I'd really like to do is change that to remove the address range limitation.

Then we could use RomRaider to read any address in memory - no need to tweak the roughness monitors every time we want to investigate a new 'high RAM' register.

_________________
2005 Legacy GT w/ ATP 3076, IWG, MBC, BCS, BC 272, LC, FFS, OMG
Please don't send questions via PM. Post a thread and send me a link to it instead. Thanks!


Top
 Profile  
 
 Post subject: Re: CEL Flashing as warning for knock, lean condition, etc.
PostPosted: Thu Nov 10, 2011 11:35 am 
Offline
Experienced
User avatar

Joined: Thu Jul 23, 2009 5:46 pm
Posts: 863
I dug into that code a long time ago looking for some unknown SSM commands, but didn't go into the read/write stuff. Pretty sure I lost that IDB, but I remember it being fairly easy to trace to the master ssm routine.

_________________
Please do not send me support questions via PM, use the forum instead!


Top
 Profile  
 
 Post subject: Re: CEL Flashing as warning for knock, lean condition, etc.
PostPosted: Thu Nov 10, 2011 11:47 am 
Offline
Senior Member

Joined: Mon Jan 19, 2009 6:31 pm
Posts: 1615
Location: Moscow, Russia
NSFW wrote:
Before I go tweaking my roughness monitor SSM routines, I have to wonder, has anyone found the code that implements the SSM 'read byte' command? Because what I'd really like to do is change that to remove the address range limitation.

Then we could use RomRaider to read any address in memory - no need to tweak the roughness monitors every time we want to investigate a new 'high RAM' register.


SSM read\write code is straight forward, there maybe a condition bit to allow reading executable code (calibration is probably readable any time). Byte\Block readings have different bounds.

System registers and stack area should be protected. Otherwise this is a security bug. It takes place for former JECS/Hitachi ecus.


Top
 Profile  
 
 Post subject: Re: CEL Flashing as warning for knock, lean condition, etc.
PostPosted: Fri Nov 11, 2011 12:03 am 
Offline
Experienced
User avatar

Joined: Thu Jul 23, 2009 5:46 pm
Posts: 863
Adding some new logic to the overboost + lean check.

From what I've read, the front o2 is a wide/mid band sensor. However, the readings go to crap when we get significant EGBP. I'm going to try to apply a MAP based compensation and store a new parameter to get the Front o2 reading to match my wideband. I think a 2D table will get close, if not a 3d rpm x map or load x map should be able to get it spot on. It will require tuning on every setup / tune. I think it's a good alternative to hard wiring a wideband into the oem ecu.

_________________
Please do not send me support questions via PM, use the forum instead!


Top
 Profile  
 
 Post subject: Re: CEL Flashing as warning for knock, lean condition, etc.
PostPosted: Fri Nov 11, 2011 6:17 pm 
Offline
Experienced
User avatar

Joined: Thu Jul 23, 2009 5:46 pm
Posts: 863
IAM recall and last known warning recall :)

http://youtu.be/7kGFGNmKkZQ

IAM flashes once when IAM = 1, and 17 times when IAM=0

_________________
Please do not send me support questions via PM, use the forum instead!


Top
 Profile  
 
 Post subject: Re: CEL Flashing as warning for knock, lean condition, etc.
PostPosted: Fri Nov 11, 2011 6:29 pm 
Offline
Experienced

Joined: Sun Jun 01, 2008 2:14 am
Posts: 125
Location: Quebec
you rock :)

you would love my Apex ecu monitoring display :)

Mart

Merp wrote:
IAM recall and last known warning recall :)

http://youtu.be/7kGFGNmKkZQ

IAM flashes once when IAM = 1, and 17 times when IAM=0


Top
 Profile  
 
 Post subject: Re: CEL Flashing as warning for knock, lean condition, etc.
PostPosted: Fri Dec 16, 2011 9:39 pm 
Offline
Experienced
User avatar

Joined: Thu Jul 23, 2009 5:46 pm
Posts: 863
Anyone looking to implement this functionality on their rom, PM me for a test rom.

I've found a method to trace the CEL light pin through the ROM logic, SSM routine hijacking shouldn't be necessary unless there have been major revisions to CEL logic on newer roms.. :mrgreen:

_________________
Please do not send me support questions via PM, use the forum instead!


Top
 Profile  
 
 Post subject: Re: CEL Flashing as warning for knock, lean condition, etc.
PostPosted: Wed Feb 06, 2013 10:08 am 
Offline
Newbie

Joined: Wed Jan 31, 2007 12:13 pm
Posts: 39
Hi Merp, as we cannot directly log the IO RAM adresses, i introduced in my code these lines to analyse the ports (in the MAF scaling subroutine).

When i change the inputs "defog", "blower", "light", "powesteering", the adresses (FFFFA800 -> FFFFA829) are not affected. But loggings works (some values always change). Isn't there a problem?

ROM:0007FDDC mov.l off_7FE60, r0 ; PADR
ROM:0007FDDE mov.w @r0, r0
ROM:0007FDE0 mov.l off_7FE64, r2 ; dword_FFFFA800
ROM:0007FDE2 mov.w r0, @r2
ROM:0007FDE4 mov.l off_7FE68, r0 ; PBDR_W
ROM:0007FDE6 mov.w @r0, r0
ROM:0007FDE8 mov.l off_7FE6C, r2 ; dword_FFFFA804
ROM:0007FDEA mov.w r0, @r2
ROM:0007FDEC mov.l off_7FE70, r0 ; PCDR_W
ROM:0007FDEE mov.w @r0, r0
ROM:0007FDF0 mov.l off_7FE74, r2 ; dword_FFFFA808
ROM:0007FDF2 mov.w r0, @r2
ROM:0007FDF4 mov.l off_7FE78, r0 ; PDDR_W
ROM:0007FDF6 mov.w @r0, r0
ROM:0007FDF8 mov.l off_7FE7C, r2 ; dword_FFFFA80C
ROM:0007FDFA mov.w r0, @r2
ROM:0007FDFC mov.l off_7FE80, r0 ; PEDR_W
ROM:0007FDFE mov.w @r0, r0
ROM:0007FE00 mov.l off_7FE84, r2 ; dword_FFFFA810
ROM:0007FE02 mov.w r0, @r2
ROM:0007FE04 mov.l off_7FE88, r0 ; PFDR_W
ROM:0007FE06 mov.w @r0, r0
ROM:0007FE08 mov.l off_7FE8C, r2 ; dword_FFFFA814
ROM:0007FE0A mov.w r0, @r2
ROM:0007FE0C mov.l off_7FE90, r0 ; PGDR_W
ROM:0007FE0E mov.w @r0, r0
ROM:0007FE10 mov.l off_7FE94, r2 ; dword_FFFFA818
ROM:0007FE12 mov.w r0, @r2
ROM:0007FE14 mov.l off_7FE98, r0 ; PHDR_W
ROM:0007FE16 mov.w @r0, r0
ROM:0007FE18 mov.l off_7FE9C, r2 ; dword_FFFFA81C
ROM:0007FE1A mov.w r0, @r2
ROM:0007FE1C mov.l off_7FEA0, r0 ; PJDR_W
ROM:0007FE1E mov.w @r0, r0
ROM:0007FE20 mov.l off_7FEA4, r2 ; dword_FFFFA820
ROM:0007FE22 mov.w r0, @r2
ROM:0007FE24 mov.l off_7FEA8, r0 ; PKDR_W
ROM:0007FE26 mov.w @r0, r0
ROM:0007FE28 mov.l off_7FEAC, r2 ; dword_FFFFA824
ROM:0007FE2A mov.w r0, @r2
ROM:0007FE2C mov.l off_7FEB0, r0 ; PLDR_W
ROM:0007FE2E mov.w @r0, r0
ROM:0007FE30 mov.l off_7FEB4, r2 ; dword_FFFFA828
ROM:0007FE32 mov.w r0, @r2


Top
 Profile  
 
 Post subject: Re: CEL Flashing as warning for knock, lean condition, etc.
PostPosted: Wed Feb 06, 2013 12:47 pm 
Offline
Experienced
User avatar

Joined: Thu Jul 23, 2009 5:46 pm
Posts: 863
Port data registers (PADR, etc) may not always store the actual pin value. Perhaps try reading the port * port registers (PAPR, etc).

Which rom are you working with?

_________________
Please do not send me support questions via PM, use the forum instead!


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 42 posts ]  Go to page 1, 2, 3  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 8 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Style based on FI Subsilver by phpBBservice.nl