Can bad codes have adverse effect on remote (URC-8910B00) ?

[ElizabethD]

When I made a coding error in byte2 in KM, it resulted in a puzzling effect. No big deal, except that curiosity is nagging me.
I suspect that given a bad byte2 from IR, the remote fished out some code from out-of-bounds area. In my imagination, I interpret remote’s cute behavior like this:
1. Shut off button interrupts service (does it run on IRQs?)
2. Turn on the red transmission indicator light on top of 8910 for about 15 seconds (keys disabled)
3. Enable interrupts
4. Turn on all LEDs inside for a glorious, red, light display
5. Wait for the next key press or drained battery, whichever comes first.

Questions:
1. How come?
2. Would it help to anwer if I posted IR file? If I trashed it, I can easily reproduce.
3. Most important - is there a list of internal commands that can fry the remote or batteries?
4. How come in IR you’re allowed to make a mess of everything, yet I have no priviledges to fix a tiny mistake such as this?

[johnsfine]

When I made a coding error in byte2 in KM, it resulted in a puzzling effect. No big deal, except that curiosity is nagging me.
I suspect that given a bad byte2 from IR, the remote fished out some code from out-of-bounds area.

I assume the protocol in question is the Device Combiner. Most protocols won't mess up so badly for a bad byte2 value. The device combiner will.

5. Wait for the next key press or drained battery, whichever comes first.

That's unusually benign for a total loss of control in a protocol. Usually the remote would be hung up until you reset via JP1 or by pressing a key while a battery is out.

1. How come?
2. Would it help to anwer if I posted IR file? If I trashed it, I can easily reproduce.

I think all the experts understand why the device combiner would act that way and we aren't likely to go to the effort (and significant increase in protocol size) needed to protect against it.

If it's some other protocol, you should have mentioned that.

3. Most important - is there a list of internal commands that can fry the remote or batteries?

It takes a while to seriously consume the batteries. I think it would be rather hard for a programming bug like this to fry the remote. But it's not practical to predict or analyze exactly what happens when a protocol transfers control to some wrong place (such as a device combiner invoking a protocol which isn't there).

4. How come in IR you’re allowed to make a mess of everything, yet I have no priviledges to fix a tiny mistake such as this?

I don't understand the question.

[Mark Pierson]

4. How come in IR you’re allowed to make a mess of everything, yet I have no priviledges to fix a tiny mistake such as this?

IR, while a very intricate program, is basically "dumb". It knows nothing about protocols or devices, so it can't tell when you've screwed up in a situation like this.

[johnsfine]

IR, while a very intricate program, is basically "dumb". It knows nothing about protocols or devices, so it can't tell when you've screwed up in a situation like this.

If we were a company making this as a product, hopefully we would take a more integrated approach, so that one part of our software understands another part.

As a bunch of individuals writing software in our free time with incompatible tools (Delphi vs Java vs C++ vs Excel, etc.) it is not practical to reach the desired level of integration.

IIUC, IR now "knows" a lot more than it used to about certain special protocols (KeyMoves that act like macros) and that integration should make those protocols much easier to use. But it doesn't know what the device combiner is.

[ElizabethD]

John,

I assume the protocol in question is the Device Combiner.]

That's correct. It's for some old Denon equipment and its about the only method that works for me at this time.

I think all the experts understand why the device combiner would act that way and we aren't likely to go to the effort (and significant increase in protocol size) needed to protect against it.

Agree. Never expected protection. I understand that experts understand. It's me who doesn't understand, which is why I asked the question.

...device combiner invoking a protocol which isn't there

I figured that's what happened when I put in a value considerably higher than the highest index of devices in KM. I can understand that there might be no way to know where it went. Just was trying to see if there is an answer and whether there are some things that you know of that can break the remote

4. How come in IR you’re allowed to make a mess of everything, yet I have no priviledges to fix a tiny mistake such as this?

I don't understand the question.

Sorry, I wasn't clear. In IR, I can go into just about every tab and edit any data in front of me. Yet on the devices tab, there is the right-click Edit command, so obviously some people have rights, some don't. What gives the rights? What shuts the rights off?

As a bunch of individuals writing software in our free time with incompatible tools (Delphi vs Java vs C++ vs Excel, etc.) it is not practical to reach the desired level of integration.

Couldn't agree more. You might be misinterpreting the drift of my question. And I hope I did not give you an impression that I have a problem with IR. I just wanted to know what happened. The tools for JP1 are incredible and I love using them every chance I get. One of the things that stands out is what you think doesn't - is the level of integration I see. It's quite amazing.

Ok, so is the bottom line answer that we can't really tell what happened when I put in a wrong number and that you can't really fry the remote too badly?

Mark,

IR, while a very intricate program, is basically "dumb". It knows nothing about protocols or devices, so it can't tell when you've screwed up in a situation like this.

Not as dumb as you say. But I just wondered if you guys knew where it goes when I screw up and what else is lurking behind the corner.
So is the only way to know, generally, what's going on to learn the instruction set and understand the assembly for the entire setup and the protocols involved? When I hit a wrong code, did we stay in eeprom? did we go into ram, if so where - that sort of thing.

[Mark Pierson]

Yet on the devices tab, there is the right-click Edit command, so obviously some people have rights, some don't. What gives the rights? What shuts the rights off?

That's a bug... er... feature that hasn't been enabled yet!

It has nothing to do with rights... just something that's not implemented yet. I believe yhe same thing used to happen on the Key Moves tab, but Paul fixed it when adding the special protocol stuff.

[mr_d_p_gumby]

Turn on all LEDs inside for a glorious, red, light display

This could be UEI's equivalent of the blue-srceen-of-death.

Given the number of variables involved, and that an incorrect byte2 value can, in this case, cause the remote to randomly start executing code somewhere in it's ROM, I don't think you could predict exactly what would happen, nor say that the same thing will always happen. Usually, the remote locks up or resets, but sometimes it will do something interesting. Consider yourself lucky that you were entertained.

As to it damaging the remote, that is very unlikely (but not impossible). About the worst you would normally expect to happen is that it somehow executes some code that causes the EEPROM contents to be corrupted. Leaving it locked up or with LEDs glowing would obviously drain the batteries faster than normal.

[johnsfine]

When I hit a wrong code, did we stay in eeprom? did we go into ram, if so where - that sort of thing.

Executing code in eeprom is never possible. Protocol upgrades are stored in EEPROM but copied to RAM before getting executed. When executed in RAM, they mostly invoke routines in ROM to do the real work. When they incorrectly invoke ROM code, it's not practical to predict the results.

[The Robman]

In IR, I can go into just about every tab and edit any data in front of me. Yet on the devices tab, there is the right-click Edit command, so obviously some people have rights, some don't. What gives the rights? What shuts the rights off?

I'd never thought to right click before, and what do you know, there's an edit option, and I apparently have the rights to use it! But before you start feeling left out, take a look at the botton of the screen, there - right before your eyes - is a great big EDIT button, which does exactly the same thing. Once you click on this button, however, all you will see is some hex. Normally, all you should do now is replace the hex with new hex generated by eithr KM or RM, but if you know what you're doing, you could edit the hex yourself.

I figured that's what happened when I put in a value considerably higher than the highest index of devices in KM. I can understand that there might be no way to know where it went. Just was trying to see if there is an answer and whether there are some things that you know of that can break the remote

Like John said earlier, entering bad hex data in a device upgrade will normally do nothing more than cause the remote to send a bad IR signal. However, if you enter bad data when using a special protocol (such as the device combiner) you can get wildly different results, as you have found. the reason being that this data causes different code in the executor to be executed. If you were to enter bad data in an executor (protocol) there's no telling what would happen. But in all of these cases, I would expect the net result to be that the remote hangs up and becomes unusable, but nothing so bad that a reset (ie, remove the batteries or JP1 load) wouldn't fix. I can't see how any physical damage to the remore could result.

[ElizabethD]

Thanks to all for help. I get the drift now. Just need a bit of follow up:

...if you enter bad data when using a special protocol (such as the device combiner) you can get wildly different results, as you have found. the reason being that this data causes different code in the executor to be executed
...I can't see how any physical damage to the remore could result.

Rob, EDIT button has, for me, the same rights as the right-click Edit. Could be a version thing. Not important, really. Just would be useful for a quick byte fix.

Regarding the special protocol distinction. Clearly, I now see, care needs to be taken, but the decision on which protocols belong to the "be-careful list" turns on the definition of “special”. It’s not obvious to me (a user of black-box tools) without the perspective of JP1 history from point zero. I now know that DC and Pause would be special. But how about combos, hacked combos, built-ins? Do we go by the absence of manuafacturer’s name, perhaps, in the KM dropdown list?

This could be UEI's equivalent of the blue-srceen-of-death.

Nah! Can't be. This BSD is not blue. I think Bill Gates holds a patent on this feature which is why other computers don’t even have it so UEI can't have it either.

[mr_d_p_gumby]

Regarding the special protocol distinction. Clearly, I now see, care needs to be taken, but the decision on which protocols belong to the "be-careful list" turns on the definition of “special”. It’s not obvious to me (a user of black-box tools) without the perspective of JP1 history from point zero. I now know that DC and Pause would be special. But how about combos, hacked combos, built-ins? Do we go by the absence of manuafacturer’s name, perhaps, in the KM dropdown list?

I think the device combiner would be the only one provided by KM or RM that would fall into this category. I don't think you can feed the Pause protocol anything that would crash the remote. The worst that any of the combos, hacked combos, etc., might do is to send out the wrong IR codes.

There might be a possibility that certain data could trigger a latent bug in a protocol, but that's not something that we've seen happen before. I know, for example, that with the P8/740 remotes, a certain combination of flags set in the protocol will lock the remote up continually transmitting the IR code for the first button you hit. In theory, a bug triggered by certain data could set the flags this way, and lock up the remote.

The device combiner is special in this regard because it has a built-in "unchecked buffer overflow" susceptibility (just like Windows ). It's not that something couldn't be done to protect against it, but any fix would reduce the amount of space available for combining protocols, and detract from the upgrade space in the user's remote. In this case, we've opted to keep the extra space so that users can combine as many protocols as possible.

On the other hand, any of the protocols in the special-protocols spreadsheet quite possibly could have problems with invalid values, so I'd reccommend a little extra caution when using them.

I think Bill Gates holds a patent on this feature which is why other computers don’t even have it so UEI can't have it either.

Have you considered the possibility that UEI subcontracted with Microsoft to have them write an RSD for the remote?

[ElizabethD]

...but any fix would reduce the amount of space available for combining protocols...

Sure. I never intended to suggest changes, just fishing for understanding.

On the other hand, any of the protocols in the special-protocols spreadsheet quite possibly could have problems with invalid values, so I'd reccommend a little extra caution when using them.

I interpret what you wrote that the list of "specials" to be careful with is DC, but not combos, rather mostly the stuff in the special-protocols spreadsheet and that's that. Ok, no problem here.

Have you considered the possibility that UEI subcontracted with Microsoft to have them write an RSD for the remote?

Nope. Good point. Hey, thanks a lot!