PDA

View Full Version : If you get "cablecard firmware upgrade"...


slimoli
09-23-2006, 06:55 PM
You can be in trouble. I had it twice and the only option was to call the cableco and have the CC replaced. It looks like some CC are too old and from time to time either the cableco or the card manufacturer (SA in my case) will send an upgrade that is never completed. Once the upgrade starts it never finishes and even if you try the same CC on another device (I have 2 TVs with CC) it stil wants the upgrade (same upgrade msg comes up).

This can be a killer and I have already read several posts here where the user had to replace the CC. What is really bad is the fact that the card works for several days and all of a sudden it asks for the upgrade that never ends.

This PITA works like a virus!!

Sergio

megazone
09-25-2006, 11:58 PM
It isn't always bad news though - both of mine got updated just fine.

rubendn
09-26-2006, 12:08 AM
Mine has been doing for approximately 36 hours and I have scheduled an appointment for Saturday to have them both replaced.

slimoli
09-27-2006, 10:49 PM
Mine has been doing for approximately 36 hours and I have scheduled an appointment for Saturday to have them both replaced.

See if you can get NEW cards with recent software version, otherwise they will work for a while and the dreadful "firmware upgrade" will be back. I had this msg 3 times in 20 days, 3 cards replaced and now I gave up. CC will be returned tomorrow and no S3 until I can be sure my small cableco can get new cards from SA. All my ordeal was with my Mitsubishi 73927 and not with the S3.

Roderigo
09-28-2006, 01:57 AM
See if you can get NEW cards with recent software version, otherwise they will work for a while and the dreadful "firmware upgrade" will be back. I had this msg 3 times in 20 days, 3 cards replaced and now I gave up. CC will be returned tomorrow and no S3 until I can be sure my small cableco can get new cards from SA. All my ordeal was with my Mitsubishi 73927 and not with the S3.
Actually, new cards will most likely require a firmware upgrade, regardless of the software that's on them. The way it was explained to me was that the upgrade actually doesn't have anything to do with the version of the software, but rather the version of the upgrade message (or something like that). So, if your headend has done 7 upgrades, a new card will be at version 0, and then immediately think it needs an upgrade to get to version 7. This is why inserting a card will very often go into a firmware upgrade. When it works properly, it only takes 5-10 minutes. The big problem is that the cards don't seem to recover from errors very well. Since the upgrade is relying on the integrity of the signal getting into the box/card, this seems like a poor card design.

alee
09-28-2006, 06:35 AM
I'm pretty sure both my cards are now toast having been in firmware upgrade mode for almost 36 hrs now. Firmware upgrades are no doubt always going to happen; however there are smart and not-so-smart ways of managing the image. It appears now that CC1.0 is very unforgiving.

Roderigo
09-28-2006, 06:11 PM
It appears now that CC1.0 is very unforgiving.
IMHO, this is not a flaw in the CC1.0 spec, but in the SA implementation. They just don't recover from any sort of errors. The CableCARD spec just talks about how a card can request the video tuner, and ask the host to tune to a particular frequency. It's then up to the card to deal with the data coming into it from the tuner.

alee
09-28-2006, 06:28 PM
IMHO, this is not a flaw in the CC1.0 spec, but in the SA implementation. They just don't recover from any sort of errors. The CableCARD spec just talks about how a card can request the video tuner, and ask the host to tune to a particular frequency. It's then up to the card to deal with the data coming into it from the tuner.
I guess I'd design it differently.

The "host" device, whether it be a TV, DVR, etc. "sees" there is an upgrade pending. The upgrade comes down as 2 pieces, a checksum + flash file. This the "queued" into a download area (some flash memory perhaps). Then the host device individually "flashes" the card or cards.

If there is a "miss" (e.g. the download wasn't whole, checksums don't match, or any sort of cable company issue), set a flag to failed, and repeat the upgrade process again in 12 hours (or some predetermined interval).

So this places more responsibility on the host device to validate firmwares prior to commiting them to the device. Additionally this doesn't turn your device into a doorstop when upgrades don't work as planned.

jodell
09-28-2006, 10:12 PM
I guess I'd design it differently.

If there is a "miss" (e.g. the download wasn't whole, checksums don't match, or any sort of cable company issue), set a flag to failed, and repeat the upgrade process again in 12 hours (or some predetermined interval).



Alee,

The problem with your plan is it makes too much sense! :')

I agree, that would be a much more resilient system...

Jeff

sjcbulldog
09-28-2006, 10:22 PM
I guess I'd design it differently.

The "host" device, whether it be a TV, DVR, etc. "sees" there is an upgrade pending. The upgrade comes down as 2 pieces, a checksum + flash file. This the "queued" into a download area (some flash memory perhaps). Then the host device individually "flashes" the card or cards.

If there is a "miss" (e.g. the download wasn't whole, checksums don't match, or any sort of cable company issue), set a flag to failed, and repeat the upgrade process again in 12 hours (or some predetermined interval).

So this places more responsibility on the host device to validate firmwares prior to commiting them to the device. Additionally this doesn't turn your device into a doorstop when upgrades don't work as planned.

Actually what is done in many devices that require "live" firmware upgrades is that you put twice the required flash memory into the device than is required. This is not a big deal because flash is relatively cheap for the few 100s of K required for the firmware to be upgraded. The card updates its firmware by reading the firmware from the live connection (cable, antenna, etc.) and updating the unused half of the flash. When the unused half of the flash is completely updated and a checksum/CRC has been used to validate the update, then a single byte is written to indicate that the previously unused half of the card is now the active half. If when the reboot happens, if the device is non-functional, this can be detected and a single byte written to have the device boot from the previous area.

I have had to put this in place in the past for similiar devices and it is not that diffifcult. The minimal cost of the additional flash is well worth the convenience. Also, this does not rely on the implementation in the TV, TIVO, etc to be sure it is done in a robust way.

Just my $0.02 worth
sjcbulldog

Roderigo
09-28-2006, 10:25 PM
The "host" device, whether it be a TV, DVR, etc. "sees" there is an upgrade pending. The upgrade comes down as 2 pieces, a checksum + flash file. This the "queued" into a download area (some flash memory perhaps). Then the host device individually "flashes" the card or cards.

If there is a "miss" (e.g. the download wasn't whole, checksums don't match, or any sort of cable company issue), set a flag to failed, and repeat the upgrade process again in 12 hours (or some predetermined interval).

Ok - I see your point, though this exact logic could/should be implemented in the card with the current spec. The spec puts the requirement onto the card to handle the upgrade. The only reason the host has to get involved is to tell the user they can't watch video, and to actually move the tuner.

The Motorola cards can upgrade their firmware, but since they don't need the video tuner, the host and user has no clue the card is doing the upgrade. I've never heard any issues with the Motorola cards getting stuck when a firmware upgrade fails.

Roderigo
09-28-2006, 10:27 PM
Actually what is done in many devices that require "live" firmware upgrades is that you put twice the required flash memory into the device than is required.
I agree w/ you here. This is basically how TiVo handles their software upgrades (though, using the hard drive, instead of flash).