8811 Backlight Malfunction with Extender-V3.2 an new 8811

nevolc · Post by **nevolc** » Sun Apr 24, 2005 11:38 pm

I've been in the process of migrating from the Cinema7 platform over to 8810/8811 using Extender V3.1 which I love. For my development, I used a cheap 8810w I picked up at WalMart a year or so ago. Now that I completed the migration and my Cinema7's are wearing out, I decide to haul off and order several 8811s from BlueDo so I could have an 8811 in each room with a TV plus a store a couple of spares. I download my image using IRv6.0 into the first new 8811 only to find the Extender quits after a few keystrokes. Fortunately, I found thread:

"8810 Extender 3.1 problem--new report" at http://www.hifi-remote.com/forums/viewtopic.php?t=29 .

Towards the end of this thread, it was concluded timing issues were causing problems with some new 8810/8811 hardware and Extender V3.2 generally fixed this. I converted to Extender V3.2 (a bit painful) and everything works right now except the BACKLIGHT. If the BACKLIGHT is enabled, it occasionally stays on for the four seconds I requested via IR but most of the time it lights for fours seconds, goes off for a few milliseconds, light another fours seconds, etc. until approximately 35 seconds go by and the BACKLIGHT finally turns off. Occasionally I'll get two or three intervals of four seconds light. This backlight problem was mentioned at the end of the thread referenced above but I haven't found a fix. My question finally, has anyone found a fix for the BACKLIGHT problem on the "new" 8810/8811s? Does this sound like and RDF problem or a minor problem with the Extender? I've tried both RDF V1.20 as well as the RDF packaged with the Extender V3.2.

Thanks for any help,
-Cliff

mtakahar · Post by **mtakahar** » Wed Apr 27, 2005 12:09 pm

I don't see anything obviously wrong in the RDF packaged with ex3.2, and the one in the RDF package is basically the same as far as the extender aspects are concerned.

Is the extender still working after the backlight gone erratic? Have you tried fresh batteries?

Hal

nevolc · Post by **nevolc** » Thu Apr 28, 2005 10:23 am

Yes, the extender continues to work fine on the new 8811 even though the red BACKLIGHT acts erratic. My older 8810W remote and it's green BACKLIGHT behaves normal regardless (i.e. Extender V3.1, V3.2, etc.). The reason I mentioned the backlight colors is I saw another post where Rob indicated newer 8810/8811s use red backlighting.

The batteries were brand new in the new 8811 when I started (around 6.4V). I have been doing a lot of testing trying to fix the problem (hacking RDFs, etc.) when it suddenly started working ! I wasn't sure what I did to "fix" it so I tried to reproduce the problem (original .IR, .RDF) and could not. So at this point I have blown a fuse.

Your question on batteries (thanks for responding) reminded me of the voltage discussion in the thread referenced above so I checked the batteries and they had dropped down to 5.7V (probably due to the BACKLIGHT running for extended periods while I've been doing a lot of testing). I can put fresh batteries in the 8811 and the BACLKIGHT problem returns. So at this point, it does appear voltage related which I realize sounds bazaar.

I'll try some more battery testing. If I get brave enough, I may try inserting a dropping diode into the power feed to the ATMEL EEPROM. I haven't seen the 8811 circuit board yet so I don't know if there is plenty of room for this type mod.

-Cliff

Nils_Ekberg · Post by **Nils_Ekberg** » Thu Apr 28, 2005 10:35 am

This finding leads me to believe that there is something in the extender that is more sensitive to the interrupts that are being set when the batteries are fresh. They could simply be set very rapid and and at the same time the extender is trying to change it confusing the extender.

When the batteries wear down a little it must be acting more like the old remote. All of this also assumes that without the extender it never behaves this way.

I have taken a quick look through 3.2 and nothing jumps out at me so I will have to look deeper unless John gets to it before me.

johnsfine · Post by **johnsfine** » Thu Apr 28, 2005 10:37 am

nevolc wrote:it does appear voltage related which I realize sounds bazaar.

I'm sorry I haven't had time to investigate these issues nor even to just track down exactly which source code is being used.

But, if it is voltage related, that fact is not bazaar at all. Rather it gives us a very good understanding of the problem.

We've known for quite some time that something about the process of going into or out of the STOP'ed state depends in a weird way on voltage. At the high end of the voltage range (4 new batteries) it does something strange. The result is that the instructions directly after the STOP instruction might or might not get executed.

Randomly skipping an instruction or two in ordinary ASM code can have almost any strange symptom you might imagine. So we're supposed to put enough NOP instructions right after the STOP so it doesn't matter whether they're executed or not.

I don't know if you're using a version of extender from before we figured all that out, or if there's another STOP somewhere in a special protocol, or whether the NOPs that were put in after figuring this out still aren't enough. But in some form I'm confident the strange behavior of the STOP instruction at high voltage is responsible for the symptoms you describe.

If you do experiment with changing the number of NOP instructions, remember that some values in the RDF depend on the position in eeprom where some parts of the extender get stored. Changing the size of any part of the extender can change those positions and "close" is useless. The positions must be exactly right or else they're wrong.

Nils_Ekberg · Post by **Nils_Ekberg** » Thu Apr 28, 2005 11:19 am

The 3_2 2K version of the extender currently has 2 NOP's in it after the stop so it may be worth trying to add one more and see what it does.

Cliff, if you want to experiment make the following changes and assemble the .asm file. If you don't want to get into the assembly process I will try to find time to do it but I don't have a remote to try it on.

If you add a third NOP after line 356 of the 6012-2K-3.asm file you will need to change the following 3 lines in the RDF

FROM

Shift Button Keycode=$7E4.7.8.2.0
Alt Shift Button Keycode=$7E9.7.8.2.0
Alt Shift=$7EE.6.1.0.1 (Xshift;Ordinary)

TO

Shift Button Keycode=$7E5.7.8.2.0
Alt Shift Button Keycode=$7EA.7.8.2.0
Alt Shift=$7EF.6.1.0.1 (Xshift;Ordinary)

NOTE: Make sure bot the .asm and RDF are from the current RDF and extender distribution zip files
NOTE 2: If one more does not do it you can try a 4th and just increment the hex values by one more in the RDF.

If this solves the problem I will be happy to update the 3_2 extenders.

mtakahar · Post by **mtakahar** » Thu Apr 28, 2005 1:10 pm

How many NOPs you really need depends on how long the resonator takes to get stabilized. Perhaps the resonator is generating a little too big initial "swings" at high voltage and taking longer in these remotes.

Hal

mtakahar · Post by **mtakahar** » Fri Apr 29, 2005 1:12 am

Nils_Ekberg wrote:If you add a third NOP after line 356 of the 6012-2K-3.asm file you will need to change the following 3 lines in the RDF

FROM

Shift Button Keycode=$7E4.7.8.2.0
Alt Shift Button Keycode=$7E9.7.8.2.0
Alt Shift=$7EE.6.1.0.1 (Xshift;Ordinary)

TO

Shift Button Keycode=$7E5.7.8.2.0
Alt Shift Button Keycode=$7EA.7.8.2.0
Alt Shift=$7EF.6.1.0.1 (Xshift;Ordinary)

Well, actually, these three addresses stay the same because the extender is aligned at the highest address of the eeprom.
What need to be changed are:

AdvCodeAddr=$401..$XXX

and

Backlight timer=$YYY.7.8.0.0

The best way to figure out the values of XXX and YYY is to look at the .lst file generated by the assembler.

XXX: Subtract 1 from the value xxxx below.
(xxxx) xorg ee_main

YYY: The same value as yyyy below.
(yyyy) timeout_patch = $$-1

I previously said nothing seemed to be wrong with the RDF, but I was wrong. The end of AdvCodeAddr for ex3.2 should be $796 or a part of the extender image can be overwritten by a key move/macro.

Hal

Nils_Ekberg · Post by **Nils_Ekberg** » Fri Apr 29, 2005 7:11 am

That will teach me to look fast at something

.

Your right that:

Backlight timer=$7XX.7.8.0.0 - XX decrements by one for each NOP added.

nevolc · Post by **nevolc** » Fri Apr 29, 2005 2:25 pm

I tried 3, 4, and 5 NOPs last night. I saw in the "6012-2K-3.lst" file that only the Backlight timer=$YYY.7.8.0.0 value was decrementing. I did not know to make corresponding changes to the AdvCodeAddr=$401..$79X so read the next paragraph with a "grain-of-salt".

Using 3 NOPs reduced the manifestation which is the backlight repeating the 5 second timer value I have set in IR. When it repeats another 5 seconds of light, it may do so anywhere from 2 to 6 times - it is not consistent. Some keys seem much more prone to cause a high repeat count. It is significant that approximately 50% of the time it now works correctly (just the desired 5 seconds of light). Using 4 NOPs seemed to improve this a little more but this may have been wishful thinking. I saw no difference between 4 and 5 NOPs.

I'll correct the AdvCodeAddr=$401..$79X section tonight and post the results. I'll also open another 8811 that I received with the first one and verify it's behavior matches the first one.

One other point worth mentioning is the Extender in the new 8811 is rock solid except for the backlight - I have not had any problems with strange behavior, lockups, etc. I've been using it every night since I received it (I do my development from from a lazy-boy using a laptop in front of the "home theater" system

).

Thanks for all your input,
-Cliff

mtakahar · Post by **mtakahar** » Sat Apr 30, 2005 12:52 am

Hey Cliff,

Can you try inserting "DI" at the label L50, before calling LightOff?

I previously thought your remote may have a poor quality resonator or other parts, but it doesn't sound right inserting 5 NOPs not fixing the problem, but you would see the problem even without the extender if the parts are that bad.

Hal

nevolc · Post by **nevolc** » Sat Apr 30, 2005 2:27 am

I did try correcting the "AdvCodeAddr=$401..$79X" and it didn't help (I do realize this counter needs to be correct though). I finally opened the second 8811 (bought five) and to my dismay it worked fine with Extender V3.1. So did the 3rd and 4th. The 5th had the same problem as the first one. I still feel better at this point - I had assumed they all five had the same problem.

I just tried adding the "DI" instruction:

Code: Select all

L40:	EI
	LD	RFB, A5		;Enable stop
	STOP
	NOP
	NOP
	NOP

L50:	DI
	CALL	LightOff
	CALL	DebounceKeys	;Keypad scan
	DEC	R_Closures	;Exactly one key pressed?
	JRNE	L10		;No

It reduced the Backlight from repeating to the point it only happens an estimated 20% of the time and the number of repeats is generally less - the "DI" instruction did help. One other "clue" to the problem is I have noticed hitting a key multiple times in quick succession causes the misbehavior to manifest more often. The battery voltage is currently right at 6.0 volts.

I'll continue to test this weekend. If you have any other code suggestions, I'll be glad to try them!

Thanks,
-Cliff

mtakahar · Post by **mtakahar** » Sat Apr 30, 2005 3:13 pm

nevolc wrote:One other "clue" to the problem is I have noticed hitting a key multiple times in quick succession causes the misbehavior to manifest more often.

It may have something to do with uncleared key interrupt or key sense line states. They will be cleared if you add "JR L10" after "CALL HandleTimeout".

Edit: Then, the backlight-turning-on code has to be moved somewhere else or the backlight wouldn't go off.

Also, you can get rid of the "DI" between "JREQ L30" and "JRC L50" since you added it at L50.

So, the changes are:

Code: Select all

--- 6012-2K-3_2.asm     2005-04-30 20:27:52.982033600 -0700
+++ 6012-2K-3.asm       2005-04-30 20:34:05.557771200 -0700
@@ -327,14 +327,15 @@
 
 L01:   LD      R_DevX, WC      ;Turn off temporary DevIndex
 
+L05:   TM      R_Flags, 1      ;Light enabled
+       JREQ    L18             ;No
+       CALL    LightOn         ;Yes: Turn it on
+
 L10:   CALL    WaitNoKeys      ;Wait for no keys pressed
        DI
        LD      RF1, WC         ;Enable button sense interrupts
        CLR     RF2             ;Clear pending interrupts (buttons)
        CALL    LedOff          ;11; Turn LED off
-       TM      R_Flags, 1      ;Light enabled
-       JREQ    L18             ;No
-       CALL    LightOn         ;Yes: Turn it on
 
 L18:   CALL    SelectTimeout   ;Select timeout value
        JRNC    L40             ;No Timeout needed
@@ -345,9 +346,9 @@
 L30:   IDLE
        RL      R_IFlags        ;Test interrupt flags
        JREQ    L30             ;No interrupt flags set
-       DI
        JRC     L50             ;Keyboard interrupt flag set
        CALL    HandleTimeOut   ;Turn off backlight and Clear shift flag
+       JR      L10
 
 L40:   EI
        LD      RFB, A5         ;Enable stop
@@ -355,10 +356,11 @@
        NOP
        NOP
 
-L50:   CALL    LightOff
+L50:   DI
+       CALL    LightOff
        CALL    DebounceKeys    ;Keypad scan
        DEC     R_Closures      ;Exactly one key pressed?
-       JRNE    L10             ;No
+       JRNE    L05             ;No
 
        LD      R_Mac, AR_MacLim-1;Init macro pointer
        LD      R_MacLast, R_Key1 ;Key code

If it works, could you also try reducing the NOPs back to two?

Hal

Nils_Ekberg · Post by **Nils_Ekberg** » Sat Apr 30, 2005 5:51 pm

Hal, I am glad you jumped in on this one since I was pretty sure from my earlier experiments when I updated 3_2 that the 3rd NOP was not going to solve the problem. I was sure something was not getting cleared but could not figure out what it was. I think you nailed it.

mtakahar · Post by **mtakahar** » Sat Apr 30, 2005 9:41 pm

Oops. Sorry, the backlight wouldn't go off with my previous version of the changes.
Please try the revised one.

Hal