HerbGreen III
02-07-2003, 10:05 AM
ECMs, triggers, and the ATmega
There have been multiple posts here and elsewhere about what's going on with ATmega support. Isn't a fix being coded? Afterall, didn't an AVR fix come out right away? My one view is that the AVR fix isn't what you think it is, and that we have yet to identify the current ECM triggers in any sort of credible way. That makes it very difficult to design a reliable fix. Still, though, I have some thoughts on the matter which I will share, below.
Observations:
(1) Two weekends ago, AVRs and ATmegas seemed to be being targetted by an ECM. Plastic and emulation with good tiers seemed to be fine.
(2) Plastic or emulation with bad tiers would get hit.
(3) Scanning through megabytes and megabytes of IRD/CAM logs revealed no EMM $64 commands, neither plain nor imbedded.
(4) Scanning through megabytes and megabytes of IRD/CAM logs revealed no unusual message sequences of any kind.
(5) The so-called AVR fix was fundamentally just toadcode plus somewhat restricted tiers plus the EMM $64 signature set from ExpressVu.
(6) ExpressVu EMM signatures are no value with Dishnetwork.
(7) This past weekend, AVRs were up with the new fix but failed with the old ways.
(8) ATmegas were again hit, even with the most basic tiers.
(9) Emulation might occasionally lock up or display Error 005 (not authorized) briefly.
(10) The ATmega, in standard usage, uses its own clock, separate from the clock supplied by the IRD.
(11) The clock for the ISO socket in the IRD is under software control. It is generated by the STi5500 procesor chip in most model IRDs.
Conclusions:
(1) There were/are multiple ECM triggers being used. There is certainly a tier-based trigger and maybe something specific to AVRs, and clearly something specific to ATmegas.
(2) With the signature set from Expressvu being a meaningless red herring in the AVR fix, either (a) the toadcode base is sufficiently different in some command response from the MCG base to side-step the ECM trigger (unlikely), -or- (b) prior AVR support generated some sort of substandard tier data (for example 0000/0000 for the tier range of one $08 data record), -or- (c) something else entirely.
(3) In all likelihood, one of the ECM triggers is very ATmega specific (and not AVR specific at all).
A viable explanation is that the IRD-supplied clock to the ISO socket is being changed. Since both the AVR and plastic base all timing on the IRD clock, they would be oblivious to any change. Most emulation adapters also base their timing on the IRD clock, so adapter-to-IRD communication would be fine, however, the adapter-to-PC communcation would be corrupted. The expected result would be consistent with Observation #9. The ATmega, on the other hand, typically runs off its own 18MHz clock and assumes the IRD is at 4.5MHz. Were the IRD to significantly change the clock, the result would be framing errors for all data between IRD and ATmega.
The ECM involves adjusting the clock a little. If excessive framing errors result from subsequent communication, trigger the TSOP write to disable the receiver...at least that is the theory at this point.
A very reasonable thing to try, then, if and when the ATmega ECM returns would be to configure the ATmega to use the IRD clock. In jEEPers that would mean setting the Board field to CLKexternal (or 4.5000MHz in older versions of NAwapo), and then leave the jumper in place (or in the PROG position) when trying it in the IRD. (This approach cannot be used on those non-standard ATmega cards without any sort of jumper or switch to feed the IRD clock directly to the ATmega128.)
x-15
There have been multiple posts here and elsewhere about what's going on with ATmega support. Isn't a fix being coded? Afterall, didn't an AVR fix come out right away? My one view is that the AVR fix isn't what you think it is, and that we have yet to identify the current ECM triggers in any sort of credible way. That makes it very difficult to design a reliable fix. Still, though, I have some thoughts on the matter which I will share, below.
Observations:
(1) Two weekends ago, AVRs and ATmegas seemed to be being targetted by an ECM. Plastic and emulation with good tiers seemed to be fine.
(2) Plastic or emulation with bad tiers would get hit.
(3) Scanning through megabytes and megabytes of IRD/CAM logs revealed no EMM $64 commands, neither plain nor imbedded.
(4) Scanning through megabytes and megabytes of IRD/CAM logs revealed no unusual message sequences of any kind.
(5) The so-called AVR fix was fundamentally just toadcode plus somewhat restricted tiers plus the EMM $64 signature set from ExpressVu.
(6) ExpressVu EMM signatures are no value with Dishnetwork.
(7) This past weekend, AVRs were up with the new fix but failed with the old ways.
(8) ATmegas were again hit, even with the most basic tiers.
(9) Emulation might occasionally lock up or display Error 005 (not authorized) briefly.
(10) The ATmega, in standard usage, uses its own clock, separate from the clock supplied by the IRD.
(11) The clock for the ISO socket in the IRD is under software control. It is generated by the STi5500 procesor chip in most model IRDs.
Conclusions:
(1) There were/are multiple ECM triggers being used. There is certainly a tier-based trigger and maybe something specific to AVRs, and clearly something specific to ATmegas.
(2) With the signature set from Expressvu being a meaningless red herring in the AVR fix, either (a) the toadcode base is sufficiently different in some command response from the MCG base to side-step the ECM trigger (unlikely), -or- (b) prior AVR support generated some sort of substandard tier data (for example 0000/0000 for the tier range of one $08 data record), -or- (c) something else entirely.
(3) In all likelihood, one of the ECM triggers is very ATmega specific (and not AVR specific at all).
A viable explanation is that the IRD-supplied clock to the ISO socket is being changed. Since both the AVR and plastic base all timing on the IRD clock, they would be oblivious to any change. Most emulation adapters also base their timing on the IRD clock, so adapter-to-IRD communication would be fine, however, the adapter-to-PC communcation would be corrupted. The expected result would be consistent with Observation #9. The ATmega, on the other hand, typically runs off its own 18MHz clock and assumes the IRD is at 4.5MHz. Were the IRD to significantly change the clock, the result would be framing errors for all data between IRD and ATmega.
The ECM involves adjusting the clock a little. If excessive framing errors result from subsequent communication, trigger the TSOP write to disable the receiver...at least that is the theory at this point.
A very reasonable thing to try, then, if and when the ATmega ECM returns would be to configure the ATmega to use the IRD clock. In jEEPers that would mean setting the Board field to CLKexternal (or 4.5000MHz in older versions of NAwapo), and then leave the jumper in place (or in the PROG position) when trying it in the IRD. (This approach cannot be used on those non-standard ATmega cards without any sort of jumper or switch to feed the IRD clock directly to the ATmega128.)
x-15