|
RomRaider
Documentation
Community
Developers
|
| Author |
Message |
|
Merp
|
Post subject: CEL Flashing as warning for knock, lean condition, etc. Posted: Tue Oct 25, 2011 5:39 am |
|
 |
| Experienced |
 |
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 |
|
 |
|
nsfw
|
Post subject: Re: CEL Flashing as warning for knock, lean condition, etc. Posted: Tue Oct 25, 2011 6:51 am |
|
 |
| 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 |
|
 |
|
Mart
|
Post subject: Re: CEL Flashing as warning for knock, lean condition, etc. Posted: Tue Oct 25, 2011 11:33 am |
|
 |
| 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 |
|
 |
|
Merp
|
Post subject: Re: CEL Flashing as warning for knock, lean condition, etc. Posted: Sun Nov 06, 2011 9:52 pm |
|
 |
| Experienced |
 |
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 |
|
 |
|
Merp
|
Post subject: Re: CEL Flashing as warning for knock, lean condition, etc. Posted: Thu Nov 10, 2011 4:41 am |
|
 |
| Experienced |
 |
Joined: Thu Jul 23, 2009 5:46 pm Posts: 863
|
Beta test is working 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 |
|
 |
|
td-d
|
Post subject: Re: CEL Flashing as warning for knock, lean condition, etc. Posted: Thu Nov 10, 2011 7:55 am |
|
 |
| 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 |
|
 |
|
nsfw
|
Post subject: Re: CEL Flashing as warning for knock, lean condition, etc. Posted: Thu Nov 10, 2011 9:14 am |
|
 |
| 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 |
|
 |
|
Merp
|
Post subject: Re: CEL Flashing as warning for knock, lean condition, etc. Posted: Thu Nov 10, 2011 11:35 am |
|
 |
| Experienced |
 |
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 |
|
 |
|
Sasha_A80
|
Post subject: Re: CEL Flashing as warning for knock, lean condition, etc. Posted: Thu Nov 10, 2011 11:47 am |
|
 |
| 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 |
|
 |
|
Merp
|
Post subject: Re: CEL Flashing as warning for knock, lean condition, etc. Posted: Fri Nov 11, 2011 12:03 am |
|
 |
| Experienced |
 |
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 |
|
 |
|
Merp
|
Post subject: Re: CEL Flashing as warning for knock, lean condition, etc. Posted: Fri Nov 11, 2011 6:17 pm |
|
 |
| Experienced |
 |
Joined: Thu Jul 23, 2009 5:46 pm Posts: 863
|
IAM recall and last known warning recall http://youtu.be/7kGFGNmKkZQIAM 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 |
|
 |
|
Mart
|
Post subject: Re: CEL Flashing as warning for knock, lean condition, etc. Posted: Fri Nov 11, 2011 6:29 pm |
|
 |
| 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/7kGFGNmKkZQIAM flashes once when IAM = 1, and 17 times when IAM=0
|
|
| Top |
|
 |
|
Merp
|
Post subject: Re: CEL Flashing as warning for knock, lean condition, etc. Posted: Fri Dec 16, 2011 9:39 pm |
|
 |
| Experienced |
 |
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.. 
_________________ Please do not send me support questions via PM, use the forum instead!
|
|
| Top |
|
 |
|
letsteyr
|
Post subject: Re: CEL Flashing as warning for knock, lean condition, etc. Posted: Wed Feb 06, 2013 10:08 am |
|
 |
| 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 |
|
 |
|
Merp
|
Post subject: Re: CEL Flashing as warning for knock, lean condition, etc. Posted: Wed Feb 06, 2013 12:47 pm |
|
 |
| Experienced |
 |
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 |
|
 |
Who is online |
Users browsing this forum: No registered users and 9 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
|
|