FR2901949A1 - Procede de mise en veille d'un decodeur de television numerique et decodeur numerique a mode veille basse consommation - Google Patents

Abstract

La présente invention concerne un procédé de mise en veille d'un décodeur de télévision numérique. Elle concerne également un décodeur de télévision numérique.Le décodeur exécutant les instructions d'un logiciel embarqué en mode marche (21), au déclenchement d'un mode veille, la mémoire restant alimentée en tension, le décodeur effectue :- l'exécution du logiciel embarqué est suspendue en l'état ;- le contexte d'exécution du logiciel embarqué est mis à jour et conservé en l'état dans une mémoire ;l'exécution du logiciel embarqué restant suspendue en l'état jusqu'à un déclenchement du mode marche, l'exécution du logiciel embarqué continuant avec le contexte d'exécution mis à jour, une ré-initialisation (23) du logiciel embarqué étant effectuée en fonction d'au moins une condition.L'invention s'applique notamment pour les décodeurs ayant un mode de veille à basse consommation.

Description

PROCEDE DE MISE EN VEILLE D'UN DECODEUR DE TELEVISION NUMERIQUE, ET

DECODEUR NUMERIQUE A MODE VEILLE A BASSE CONSOMMATION

La présente invention concerne un procédé de mise en veille d'un décodeur de télévision numérique. Elle concerne également un décodeur de télévision numérique. Elle s'applique notamment pour les décodeurs ayant un mode de veille à basse consommation.

Dans un terminal de sélection de chaînes de télévision, communément appelé décodeur ou STB selon l'expression anglo-saxonne Set Top Box , le mode veille ou standby permet de commuter le décodeur dans un mode basse consommation afin de respecter les réglementations en vigueur sur la consommation des équipements électriques. Généralement, ce mode basse consommation consiste à stopper le logiciel embarqué et à éteindre la plupart des composants matériels, notamment la mémoire vive appelée RAM par la suite.

Ainsi dans un décodeur ne disposant ni d'un stockage de masse, du type disque dur, ni d'une RAM alimentée en permanence, l'ensemble des données stockées sont perdues lorsqu'un abonné met le décodeur en mode veille. Ces données numériques stockées sont notamment des données de programmes, des applicatifs ou encore des données de configuration.

Cependant dans un système embarqué de décodeur, les téléchargements de mémoire cache comme le cache stockant les informations EIT (Event Information Table) servant au guide des programmes, de l'image de l'interactivité ou d'applications de type DVB MHP (Digital Video Broadcast - Media Home Platform), ou autres, peuvent prendre un temps non négligeable. Ces téléchargements peuvent durer, par exemple de 5 à 15 minutes, pour le seul cache destiné aux informations EIT. Ces divers chargements sont en général sauvegardés sur un disque dur lorsque l'architecture le permet. Néanmoins, une telle architecture à disque dur est coûteuse et pas toujours adaptée à des applications grand public.

Pour un décodeur sans disque dur, le problème se complique lorsque le système passe en standby , ou mode basse consommation . En effet, le système est alors arrêté, la mémoire est réinitialisée et le redémarrage du système implique alors à nouveau d'attendre plusieurs minutes pour recharger les différentes mémoires cache.

Un but de l'invention est notamment de pallier les inconvénients précités. A cet effet l'invention a pour objet un procédé de mise en veille d'un décodeur de télévision numérique comportant une mémoire contenant des données d'un logiciel embarqué et exécutant les instructions de ce logiciel en mode marche. Au déclenchement d'un mode veille, la mémoire restant alimentée en tension - l'exécution du logiciel embarqué est suspendue en l'état ; le contexte d'exécution du logiciel embarqué est mis à jour et conservé en l'état dans la mémoire ; l'exécution du logiciel embarqué restant suspendue en l'état jusqu'à un déclenchement du mode marche, l'exécution du logiciel embarqué continuant avec le contexte d'exécution mis à jour, une ré-initialisation du logiciel embarqué étant effectuée en fonction d'au moins une condition.

Avantageusement, le décodeur recevant dans un flux de données un ensemble d'applications et de données cohérentes entre elles formant une image d'interactivité, la mise à jour du contexte d'exécution est réalisée par une phase d'acquisition de l'image d'interactivité. Si le mode marche est enclenché avant la fin de la phase d'acquisition de l'image d'interactivité, l'exécution du logiciel embarqué continue par exemple avec un contexte d'exécution antérieur, stocké en mémoire.

L'invention a également pour objet un décodeur de télévision numérique mettant en oeuvre le procédé précédent. Une condition de ré-initialisation du logiciel embarqué est par exemple que le temps passé depuis la ré-initialisation précédente dépasse une durée 30 donnée. Le décodeur compte par exemple le temps passé au moyen d'une horloge interne, en effectuant un recalage du temps pour tenir compte du ralentissement de la fréquence d'horloge en mode veille. Dans un autre mode de réalisation, il peut compter le temps passé au moyen d'un signal 35 d'horloge extérieur.

Une autre condition de ré-initialisation du logiciel embarqué est par exemple un nombre donné de mises à l'état suspendu du logiciel embarqué. Avantageusement, la mémoire étant une mémoire vive RAM, cette mémoire comporte par exemple une zone sécurisée pointée par une adresse fixe, et une zone de sauvegarde de données du logiciel embarqué. La zone de sauvegarde contient alors des zones de stockage des données de contextes d'exécution, la zone sécurisée contenant des zones décrivant chacune les caractéristiques d'une zone de stockage de la mémoire de sauvegarde. La zone de la zone sécurisée mémorise, par exemple, un checksum calculé sur sa zone de sauvegarde associée. Dans ce cas, avantageusement, après une phase de ré-initialisation, le décodeur recalcule, par exemple, les checksums des différentes zones de la zone de sauvegarde et les compare avec les checksums mémorisés dans les zones de la zone sécurisée. Lorsque le checksum recalculé d'une zone de sauvegarde correspond au checksum sauvegardé dans sa zone associée de la zone sécurisée, le contexte sauvegardé dans la zone de sauvegarde est alors disponible pour l'exécution du logiciel embarqué. Avantageusement, la partie de la zone sécurisée mémorise aussi par exemple l'adresse de pointage de la zone de stockage associées dans la mémoire de sauvegarde, le type de données contenues dans cette zone de stockage ou encore la taille de mémoire allouée.

D'autres caractéristiques et avantages de l'invention apparaîtront à l'aide de la description qui suit faite en regard de dessins annexés qui représentent : la figure 1, une illustration d'un contexte d'utilisation de l'invention ; la figure 2, une illustration de la gestion du mode veille selon l'invention ; - la figure 3, une présentation détaillée des opérations effectuées lors d'un passage en mode veille ; - la figure 4, un exemple d'organisation d'une mémoire contenue dans un décodeur selon l'invention ; - la figure 5, une présentation des éléments d'architecture logicielle contenue dans un décodeur selon l'invention.

La figure 1 illustre un contexte d'utilisation de l'invention. Un terminal 1 reçoit par un canal quelconque 2 des signaux audio-vidéo véhiculant des programmes TV ainsi que des données numériques. Ce terminal décode les signaux reçus puis fournit les programmes sélectionnés à un téléviseur associé 3. Parallèlement au déroulement des programmes de télévision, le décodeur 1 déroule un logiciel embarqué, ce logiciel comprend notamment le programme applicatif, éventuellement une couche logicielle intermédiaire ou middleware, les couches logicielles de pilotage des interfaces avec les composants matériels, et plus généralement toutes les autres couches logicielles nécessaires à l'exécution des process. Une liaison 4 est établie entre le décodeur 1 et un dispositif de commande à distance 5 ou télécommande. La télécommande 5 permet de sélectionner les programmes mais aussi de commander la mise en veille du décodeur 1. Cette mise en veille peut aussi intervenir par une commande directement appliquée sur le décodeur. L'invention utilise avantageusement les modes basse consommation des processeurs pour réduire la consommation mais sans stopper réellement le logiciel embarqué. Ainsi le décodeur ne passe pas alors en un classique mode standy mais dans un mode gel dans lequel l'ensemble des process en cours sont gelés sans pour autant être réellement stoppés. De plus, dans ce mode particulier, la RAM reste rafraîchie par le processeur du décodeur, sans pour autant nécessiter une architecture matérielle de RAM alimentée. La baisse de consommation est ensuite obtenue par une limitation des cadences des horloges et l'arrêt de certains composants matériels non critiques pour la conservation de la RAM. Ainsi, dans ce mode gel, la RAM reste physiquement dans l'état dans lequel elle était juste avant le déclenchement de ce mode, tant au niveau du code programme que des données. II est à noter que la baisse de cadence des horloges du terminal peut fausser le comptage du temps, comptage qui peut être nécessaire comme le montre la description qui suit. Dans la mesure où la baisse de cadence peut être définie, il est possible sans difficulté d'effectuer un recalage du temps.

La figure 2 illustre une gestion du mode veille selon l'invention. Plus 35 particulièrement, la figure 2 illustre en fonction du temps t les différents modes de fonctionnement du décodeur 1. La phase de fonctionnement du décodeur est représentée en traits pleins 21. Dans cette phase, un utilisateur a mis le décodeur en fonctionnement, c'est-à-dire en mode marche. Parallèlement au déroulement des programmes de télévision, le décodeur 1 déroule le logiciel embarqué. Ce programme assure notamment la gestion des données numériques diffusées avec les chaînes de télévision, telles que les informations EIT sur les contenus des programmes, les données interactives affichées à l'écran ou toutes autres données numériques accompagnant les programmes diffusés par les chaînes. io Les phases de gel du décodeur sont représentées en traits discontinus 22. Dans cette phase, un utilisateur a mis le décodeur en mode veille. Concrètement, il a décidé d'arrêter la diffusion des programmes de télévision. Selon l'invention, il ne s'agit pas d'une procédure de veille classique puisque le logiciel embarqué n'est pas réellement arrêté. Il est 15 simplement bloqué dans l'état dans lequel il se trouvait au moment de la commande de mise en veille. Plus particulièrement, l'exécution du logiciel embarqué est suspendue en l'état, le programme restant stocké en mémoire sur l'instruction en cours. Le programme est donc arrêté à l'instruction en cours. De même les 20 périphériques et autres composants matériels commandés restent en l'état. Enfin, le contexte d'exécution logicielle reste aussi en l'état, en particulier les adresses de pointage et les données intermédiaires. Le mode gel reste activé jusqu'à ce qu'une commande de mise en marche parvienne au décodeur. A l'occasion de cette commande de mise en marche, 25 le mode gel est abandonné, le fonctionnement 21 est activé et le programme repart exactement du point où il avait été gelé avec une conservation intégrale du contexte d'exécution précédent la mise en gel. Ainsi, l'ensemble des données précédemment stockées en RAM continue d'être utilisable sans nécessiter leur nouvelle acquisition dans le flux de données transmises au 30 décodeur parallèlement aux chaînes de télévision, ces flux étant transmis par les opérateurs. Cette acquisition est longue comme cela a été indiqué précédemment. Un décodeur selon l'invention fait donc l'économie de cette acquisition.

La figure 3 illustre de façon plus détaillée les opérations effectuées par le décodeur lors du passage en mode veille. A la réception d'une commande de mise en veille 30, le décodeur lance un programme 31 pour stocker l'image d'interactivité du logiciel embarqué en cours. L'image d'interactivité représente ici un ensemble d'applications et de données cohérentes entre elles diffusées à un instant t donné. Cette image d'interactivité est contenue dans le flux de données transmis vers le terminal 1. Lorsqu'elle est utilisée par le logiciel embarqué elle forme le contexte d'exécution. Ce contexte est composé des données stockées en mémoire, notamment en mémoire vive, et servant dans le contexte opérationnel du logiciel embarqué. L'image d'interactivité peut être cachée en mémoire avant d'être utilisée comme contexte. Le contexte de la séquence 21 d'ordre n est ainsi stocké en mémoire dans la RAM. Une fois l'acquisition de la Hème image d'interactivité effectuée, cette dernière devient le contexte d'ordre n du logiciel embarqué en cours, et le logiciel embarqué passe en mode gel proprement dit. Ce contexte pourra ainsi être disponible lors de la remise en route du programme à la séquence suivante 21 de fonctionnement. L'acquisition d'un contexte d'exécution peut prendre plusieurs minutes, voire dix à vingt minutes. Il est possible qu'un utilisateur lance une commande de mise en marche du décodeur alors que la période 31 d'acquisition du contexte n'est pas terminée. Dans ce cas, le contexte d'ordre n n'ayant pas pu être acquis, le contexte d'ordre n ù 1, conservé en mémoire, peut être utilisé. En pratique, le contexte n ù 1 peut être avantageusement utilisé à la place du contexte n, sans dégradation des performances. La figure 3 montre notamment que selon l'invention, l'acquisition de la n1ème image d'interactivité forme le futur contexte d'exécution d'ordre n. Ce contexte est stocké en mémoire cache et devient le contexte d'exécution qui est remplacé d'un mode gel 22 à l'autre, ou qui est conservé si la phase d'acquisition 31 a été interrompue. L'acquisition du contexte est par exemple commandée par un programme de gestion de la mémoire exécuté par un processeur qui reste, par exemple, lui aussi alimenté en tension.

On revient à la figure 2. Le décodeur 1 commande donc successivement le déroulement 21 d'un programme application, lorsqu'il est commandé en marche, et le gel 22 du logiciel embarqué, lorsqu'il est commandé en veille. Pour des raisons de stabilité du déroulement du logiciel embarqué, il est nécessaire d'effectuer régulièrement un vrai reset logiciel, c'est-à-dire d'effectuer une ré-initialisation du logiciel embarqué. En effet, puisque le déroulement du programme n'est jamais réellement stoppé, celui-ci devient au fil du temps de plus en plus instable, en raison notamment de fuites de mémoires. Pour réduire cette instabilité, une opération ré-initialisation du io programme est par exemple lancée. Cette opération de relance du programme est pénalisante du point de vue de la disponibilité des données, en particulier à cause de la perte des informations en RAM. En particulier, si cette opération de reset est interrompue, il n'y a plus de contexte, même d'ordre n û 1, disponible. 15 Elle est donc réalisée de préférence lors de la mise en veille par un utilisateur selon, par exemple, les critères suivants : le programme n'a pas été relancé, par reset logiciel, depuis N jours ; la mise en veille est réalisée après une heure tardive configurable, 22 heures ou 24 heures par exemple. 20 Le décodeur applique ces critères à l'aide de son horloge interne par exemple, ou de toute autre horloge, notamment par une horloge extérieure au décodeur. Le reset logiciel peut être aussi lancé au bout d'un nombre donné de passages en mode gel, ce critère pouvant se combiner aux précédents. 25 Les périodes de marche 21, correspondant au déroulement du logiciel embarqué, et de veille 22, correspondant au gel du programme, peuvent avoir des durées très variables. Ces durées peuvent aller de quelques minutes à plusieurs heures, voire quelques jours. L'état du décodeur en 30 marche peut être traité différemment de l'état du décodeur en veille. Lorsque le décodeur reste en marche longtemps, cela peut être dû à un oubli de l'utilisateur. Le décodeur reste allumé alors que personne ne regarde la télévision. Pour détecter cet état de marche intempestif, le décodeur peut lancer une série de tests. En particulier si : le décodeur est allumé à une heure tardive, par exemple au-delà de 24 heures ; et que la commande du décodeur reste inactive, ce qui se traduit notamment par le fait que le décodeur ne reçoit pas d'ordre de 5 sélection de chaîne dans une durée prédéterminée ; le décodeur peut se mettre en veille. Deux cas se présentent alors. Dans un premier cas, le programme n'a pas été relancé, par reset logiciel, depuis N jours. Dans ce cas, un reset logiciel 23 est lancé. Dans le deuxième cas, le reset logiciel n'est pas nécessaire. Le décodeur met, par exemple, le 1 o programme en mode gel 22. II est possible de prévoir sur le décodeur 1, une commande inhibant ce type de veille automatique. Lorsque le décodeur reste en mode veille au-delà d'une durée prédéterminée, par exemple lorsque l'abonné est en vacances, le décodeur 15 peut passer en marche le temps d'effectuer un reset logiciel 23 complet. Une fois ce reset logiciel effectué, le décodeur retourne en mode gel 22 après avoir effectué la phase d'acquisition 31.

La figure 4 illustre la gestion des données acquises dans le flux diffusé, c'est- 20 à-dire l'acquisition de l'image d'interactivité qui permet un redémarrage rapide après un reset logiciel ou ré-initialisation du logiciel embarqué. Plus particulièrement la figure 4 illustre l'organisation des données stockées en mémoire RAM 41. Dans un décodeur selon l'invention, cette RAM 41 reste alimentée en tension 25 lors d'un passage du décodeur en mode veille. Elle reste donc alimentée lors du mode gel, ce qui est nécessaire à l'acquisition et la conservation des contextes, mais aussi lors d'un reset logiciel 23. La structure des données dans la RAM permet de restituer les données de façon instantanée après un reset logiciel. En général, lors d'un reset logiciel appliqué sur une RAM, 30 même si celle-ci reste alimentée, les adresses qui pointent les données du contexte sont effacées ou remplacées par d'autres adresses quelconques de sorte que le contexte est perdu. Dans les systèmes classiques le passage en mode veille implique un reset logiciel qui fait perdre l'ensemble des accès aux données de la RAM, même 35 en conservant la RAM alimentée en tension. II en résulte que l'ensemble des données ayant été téléchargées à partir du flux diffusé et stockées en mémoire RAM sont perdues. Lorsque l'architecture ne présente pas un disque dur, il est alors inéluctable d'avoir recours à des rechargements systématiques des différents caches. Lorsque l'architecture présente un disque dur, il est possible de faire ces différentes sauvegardes de données et de les restituer après une mise en mode veille avec reset logiciel, cependant les données ne sont pas exploitables de façon immédiate car il est nécessaire de faire une passe de recopie et une transformation vers la mémoire vive RAM, ce qui nécessite encore un temps non négligeable.

La RAM 41 contient la mémoire cache stockant les informations EIT, des programmes d'interactivité ou encore des applications de type DVB MHP par exemple, ou autres. Elle comporte aussi les logiciels d'exploitation ainsi que les couches logicielles intermédiaires dites middleware permettant de faire fonctionner les différentes applications à l'intérieur du décodeur. Selon l'invention, la RAM 41 comporte une zone dédiée 42, sécurisée. Cette zone sécurisée 42 est pointée par une adresse fixe 43. Cette zone mémoire sécurisée peut être créée à partir d'une adresse mémoire dédiée au middleware qui est en général fixe. En général, cette adresse de base reste inchangée lors d'un reset logiciel. La zone sécurisée 42 permet de définir, dans des zones 46 dédiées, les caractéristiques des zones mémoires 44 contenant les données à sauvegarder de façon persistante, y compris après un reset logiciel. Ces caractéristiques indiquent par exemple l'adresse de pointage des zones de stockage, le type de données, la taille totale, les blocs mémoires alloués, les blocs mémoires libres et le checksum de zones mémoires précitées. Lors de la mise à jour d'un cache ou d'un chargement d'applications par exemple, notamment dans les phases d'acquisition 31 effectuée en début du mode gel, les données sont sauvegardées dans des zones 54 de la zone de sauvegarde 44 qui leur sont dédiées. Les caractéristiques de ces zones de données 54 ainsi qu'un checksum calculé sur toute la zone de sauvegarde 54 sont alors stockés dans une zone 46 de la zone sécurisée 42. Ainsi, lorsque le décodeur sort du mode veille, après un reset logiciel notamment, un module gérant la mémoire recalcule les checksum des différentes zones 54 de la zone de sauvegarde 44 et les compare avec ceux sauvegardés dans la zone de sécurisation 42. Si les checksum sont corrects, le cache ou les programmes applicatifs sont disponibles. Chaque module de logiciel embarqué n'a plus qu'à récupérer les caractéristiques 46 de ces données via le module gérant la mémoire.

La figure 5 montre des éléments d'architecture logicielle à l'intérieur d'un décodeur 1 selon l'invention. Le module 51 gérant la mémoire commande l'organisation des données à l'intérieur de la RAM 41. Ce module mémoire 51 est un programme logiciel déroulé par un processeur non représenté. Les données de la RAM 41, organisée selon la figure 4, sont donc gérées par ce module mémoire 51. A l'initialisation du middleware, le module mémoire 41 récupère des informations auprès d'un composant logiciel 52 appelé par la suite DLI selon l'expression anglo-saxonne Device Layer Interface . Ce composant 52 assure l'interfaçage entre la couche logiciel middleware et les pilotes des composants matériels 53 du décodeur. Les informations récupérées auprès du DLI sont notamment des caractéristiques mémoires dédiées au middleware pour l'exécution du programme. Ces informations, ainsi que la taille mémoire et l'adresse de base 43 restent en général constantes d'un reset à l'autre, excepté lors du téléchargement d'un nouveau logiciel embarqué où elles peuvent éventuellement changer. Le principe de l'organisation d'une RAM 41 selon l'invention consiste dans un premier temps à réserver un ensemble de zones mémoires 46 dans la zone sécurisée 42 à partir de l'adresse de base 43 et dont les tailles sont définies de façon applicative. Les adresses de ces différentes zones 46 sont identifiées à l'aide d'un identifiant Id qui est fourni par le module mémoire 51 lors de la création de la zone sécurisée. Chaque zone mémoire 46 est dotée d'un en-tête décrivant les caractéristiques de la zone de sauvegarde 54 associée, cet en-tête indique 30 donc notamment par exemple : l'adresse de pointage de la zone de sauvegarde 54 ; le type de données qu'elle contient ; les blocs alloués ; les blocs libres ; 35 - la taille totale de mémoire restante ; - un checksum. Ces en-têtes sont des données propres au module mémoire 51, ils sont stockés à partir de l'adresse de base 43 dans la zone de sécurisation 42. Elles permettent de réaliser une description du contexte. La zone sécurisée 42 a, par exemple, quant à elle une taille de 512 octets. Chaque zone mémoire est dotée d'une fonction générique d'allocation et de libération prenant en paramètre l'identifiant Id caractérisant la zone. Ainsi, chaque module de programme souhaitant sauvegarder ses données peut le faire via ces fonctions. Le module mémoire 51 peut permettre l'allocation de zone mémoires de tailles fixe. Un avantage est notamment de rendre l'allocation beaucoup plus rapide qu'une allocation de base et d'éviter la fragmentation de la mémoire. A l'issue de l'exécution d'une ré-initialisation, donc en cas de reset logiciel, le composant DLI a par exemple la charge d'effacer les données de la zone sécurisée 42. Ainsi, le module mémoire 51 peut considérer les zones mémoires comme obsolètes et n'a plus qu'à réinitialiser ces différentes zones en les considérant comme des zones libres. Par conséquent, lorsqu'un module de programme ayant sauvegardé des données lancera une séquence pour récupérer ces données, le module mémoire indiquera que ces données sont obsolètes. En cas de reset logiciel 23, les modules de programme ayant déclaré des zones mémoire sécurisées sauvegardent les caractéristiques des variables globales et des points d'entrée de ces données, par exemple le point d'entrée de listes chaînées, dans une zone allouée associée à chaque module. Les modules sont alors tenus d'informer le module mémoire 51 pour que celui-ci puisse stocker l'adresse de ces zones allouées dans la zone sécurisée. Lorsque la sauvegarde est effective, le module mémoire 51 calcule alors un checksum sur la zone de données des zones allouées qu'il stocke dans la zone sécurisée 42.

A la fin d'une période de reset 23, les différentes zones allouées 54 ainsi que la zone sécurisée 42 sont dans l'état où elles ont été laissées lors de la mise en veille du décodeur. Lors de la sortie de la veille, le module mémoire 51 effectue l'analyse de la zone sécurisée 42 en recalculant en particulier les différents checksums des zones allouées 54 et en les comparant avec ceux stockés préalablement, ce qui permet de garantir la cohérence des données.

Si les checksum sont corrects, le module mémoire 51 réinitialise ces zones telles qu'elles étaient lors de la mise en veille, dans le cas contraire, les zones sont réinitialisées à l'état libre. Lorsqu'un module de programme détenant des données dans une zone mémoire allouée 54 souhaite accéder à ces données, celui-ci demande au module de mémoire 51, à l'aide de son identifiant Id, de lui transmettre les données de sa zone mémoire allouée contenant les caractéristiques des variables globales et points d'entrées de ces données.

De nombreux systèmes embarqués pour décodeurs simulent la veille par un mode veille ou standby dit fake standby ou faux standby qui consiste juste à éteindre les entrées-sorties du décodeur, obtenant notamment un écran noir du côté du téléviseur. Or de nouvelles directives contraignent l'implémentation d'un vrai mode de basse consommation. L'invention permet de passer dans cet état basse consommation, permet de récupérer les données instantanément au format final directement exploitable par les applications, et permet de passer en mode basse consommation sans pertes de données, quelle que soit l'architecture, avec disque dur ou non. L'alimentation en tension de la RAM est maintenue en cas de reset logiciel.

Après un reset, le redémarrage du logiciel embarqué est rapide, il peut prendre de 10 à 15 secondes seulement. Si la gestion de la RAM n'est pas effectuée conformément à la figure 4, le démarrage du logiciel embarqué prend plus de temps lors des resets logiciels, ce problème ne se posant pas pour les mises en veille avec l'application du mode gel.25

Claims (18)

REVENDICATIONS

1. Procédé de mise en veille d'un décodeur de télévision numérique comportant une mémoire (41) contenant des données d'un logiciel embarqué et exécutant les instructions de ce logiciel en mode marche (21), caractérisé en ce qu'au déclenchement d'un mode veille, la mémoire (41) restant alimentée en tension : l'exécution du logiciel embarqué est suspendue en l'état ; le contexte d'exécution du logiciel embarqué est mis à jour et conservé en l'état dans la mémoire (41) ; l'exécution du logiciel embarqué restant suspendu en l'état jusqu'à un 1 o déclenchement du mode marche, l'exécution du logiciel embarqué continuant avec le contexte d'exécution mis à jour, une ré-initialisation (23) du logiciel embarqué étant effectuée en fonction d'au moins une condition.

2. Procédé selon la revendication 1, caractérisé en ce que le décodeur 15 recevant dans un flux de données un ensemble d'applications et de données cohérentes entre elles formant une image d'interactivité, la mise à jour du contexte d'exécution est réalisée par une phase d'acquisition de l'image d'interactivité (31). 20

3. Procédé selon la revendication 2, caractérisé en ce que si le mode marche est enclenché avant la fin de la phase d'acquisition de l'image d'interactivité, l'exécution du logiciel embarqué continue avec un contexte d'exécution antérieur, stocké en mémoire (41). 25

4. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'une condition de ré-initialisation du logiciel embarqué est que le temps passé depuis la ré-initialisation précédente dépasse une durée donnée. 30

5. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'une condition de ré-initialisation du logiciel embarqué est un nombre donné de mises à l'état suspendu du logiciel embarqué.

6. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que la mémoire (41) est une mémoire vive.

7. Décodeur de télévision numérique comportant une mémoire (41) contenant des données d'un logiciel embarqué et exécutant les instructions de ce logiciel en mode marche (21), caractérisé en ce qu'au déclenchement d'un mode veille, la mémoire (41) restant alimentée en tension : l'exécution du logiciel embarqué est suspendue en l'état ; le contexte d'exécution du logiciel embarqué est mis à jour et 10 conservé en l'état dans la mémoire (41) ; l'exécution du logiciel embarqué restant suspendu en l'état jusqu'à un déclenchement du mode marche, l'exécution du logiciel embarqué continuant avec le contexte d'exécution mis à jour, une ré-initialisation du logiciel embarqué étant effectuée en fonction d'au moins une condition. 15

8. Décodeur selon la revendication 7, caractérisé en ce que, recevant dans un flux de données un ensemble d'applications et de données cohérentes entre elles formant une image d'interactivité, il effectue la mise à jour du contexte d'exécution par une phase d'acquisition (31) de l'image 20 d'interactivité.

9. Décodeur selon la revendication 8, caractérisé en ce que, si le mode marche est enclenché avant la fin de la phase d'acquisition de l'image d'interactivité, l'exécution du logiciel embarqué continue avec un contexte 25 d'exécution antérieur, stocké en mémoire (41).

10. Décodeur selon l'une quelconque des revendications 7 à 9, caractérisé en ce qu'une condition de ré-initialisation du logiciel embarqué est que le temps passé depuis la ré-initialisation précédente dépasse une durée 30 donnée.

11. Décodeur selon la revendication 10, caractérisé en ce qu'il compte le temps passé au moyen d'une horloge interne, en effectuant un recalage du temps pour tenir compte du ralentissement de la fréquence d'horloge en 35 mode veille.

12. Décodeur selon la revendication 10, caractérisé en ce qu'il compte le temps passé au moyen d'un signal d'horloge extérieur.

13. Décodeur selon l'une quelconque des revendications 7 à 12, caractérisé en ce qu'une condition de ré-initialisation du logiciel embarqué est un nombre donné de mises à l'état suspendu du logiciel embarqué.

14. Décodeur selon l'une quelconque des revendications 7 à 13, caractérisé 1 o en ce que la mémoire (41) étant une mémoire vive RAM, la mémoire (41) comporte une zone sécurisée (42) pointée par une adresse fixe (43), et une zone (44) de sauvegarde de données du logiciel embarqué, la zone de sauvegarde (44) contenant des zones (54) de stockage des données de contextes d'exécution, la zone sécurisée (42) contenant des zones (46) 15 décrivant chacune les caractéristiques d'une zone (54) de stockage de la mémoire de sauvegarde.

15. Décodeur selon la revendication 14, caractérisé en ce qu'une zone (46) de la zone sécurisée (42) contient l'adresse de pointage de la zone de 20 stockage (54) de la mémoire de sauvegarde (44).

16. Décodeur selon l'une quelconque des revendications 14 ou 15, caractérisé en ce qu'une zone (46) de la zone sécurisée (42) contient un checksum calculé sur la zone de stockage (54) de la mémoire de 25 sauvegarde (44).

17. Décodeur selon la revendication 16, caractérisé en ce qu'après une phase de ré-initialisation (23), le décodeur recalcule les checksums des différentes zones (54) de la zone de sauvegarde (44) et les compare avec 30 les checksums mémorisés dans les zones (46) de la zone sécurisée (42), lorsque le checksum recalculé d'une zone de sauvegarde (54) correspond au checksum sauvegardé dans sa zone (46) associée de la zone sécurisée (42), le contexte sauvegardé dans la zone de sauvegarde est disponible pour l'exécution du logiciel embarqué. 35

18. Décodeur selon l'une quelconque des revendications 14 à 17, caractérisé en ce qu'une zone de sauvegarde contient le type de données et la taille de mémoire allouée de la zone de stockage (54).5