NspireCX ne laisse JAMAIS la batterie à plat sans OS ni Diag

[critor]

Les TI-Nspire CX et CM, disposent d'une alimentation par batterie rechargeable qui est d'ailleurs leur seule et unique source d'alimentation.

Cette batterie se recharge uniquement lorsque le système d'exploitation TI-Nspire est démarré et fonctionne (une fois passé l'écran grisé après que la barre de progression ait atteint 100%).

Or, il arrive parfois que le système TI-Nspire ne démarre pas correctement, notamment:

• avec un blocage sur l'écran grisé de chargement, bug de l'OS qui arrive au redémarrage après l'utilisation de certains programmes Ndless, mais que j'ai déjà expérimenté également sur des calculatrices non Ndlessées
• avec une erreur "System Error" au redémarrage, que j'ai déjà obtenue notamment suite à des tentatives un peu top exagérément 'poussées' avec mon programme Ndless d'overclocking Nover
• avec une calculatrice qui redémarre en boucle suite à un effacement du fichier 'ndless_ressources' sans avoir désinstallé Ndless, mais que j'ai obtenu aussi après avec utilisé Ndless avec un périphérique branché sur le connecteur Dock (module WiFi TI-Nspire Navigator Cradle, ou station d'acquisition TI-Nspire Lab Cradle - c'est une configuration apparemment instable en présence de Ndless)

Dans tous ces cas, la calculatrice est donc soit figée sur un écran, soit en train de tenter indéfiniment de redémarrer.
Le système Nspire n'est donc pas lancé, ce qui veut dire que même si la calculatrice est alimentée via la prise USB sa batterie ne se recharge pas, et qu'au pire si la calculatrice n'est pas branchée en USB la batterie est même en train de se décharger!

Or, nombre de ces situations de panne nécessitent tout bonnement la suppression du système Nspire via le menu de maintenance et sa réinstallation.
Mais en dessous d'un certain pourcentage de charge de batterie, l'accès au menu de maintenance et l'installation d'un système Nspire vous seront refusés, et ce même si la calculatrice est alimentée via la prise USB!

Vous vous retrouvez donc alors dans un cercle vicieux:

• vous avez besoin de charger la batterie pour pouvoir dépanner le système Nspire
• mais vous avez besoin du système Nspire pour recharger la batterie...

Et c'est une situation qui n'est pas rare, ayant déjà été rapportée plusieurs fois sur TI-Planet et sur Omnimaga.

Heureusement, il existe un autre moyen de recharger la batterie en utilisant le logiciel de diagnostics:

Nous avons justement sorti deux tutoriels afin de te sortir des situations de panne ci-dessus en utilisant le logiciel de diagnostics.



Toute situation avec un système TI-Nspire CX ou CM qui ne démarre pas constitue donc une urgence vitale à traiter immédiatement, sans quoi vous allez vous retrouver avec une batterie déchargée et une procédure de dépannage encore plus compliquée voire même parfois impossible à réaliser!

Si vous n'avez pas le temps de vous en occuper immédiatement, dans une telle situation retirez le couvercle de la batterie et débranchez-la afin d'éviter qu'elle ne se décharge en dessous du point critique.



Car... imaginez que le logiciel de diagnostics soit manquant sur votre TI-Nspire CX ou CM?
Oui c'est parfaitement possible: il suffit de maintenir les touches lors d'un redémarrage pour l'effacer. C'est également possible après un bug ou une mauvaise manipulation de programme Ndless.

Avec une batterie à plat, un système Nspire qui ne démarre pas, et un logiciel de diagnostics manquant, vous n'avez plus aucun moyen de recharger la batterie sans ouvrir la calculatrice.
Les deux seules solutions sont alors de retirer la batterie pour:

• la brancher directement sur un chargeur externe, si tant est que vous en ayez un avec une prise adéquate
• la brancher dans une autre TI-Nspire à clavier tactile fonctionnelle

Ce ne sera pas à la portée de tout-le-monde, et en l'absence de ces deux possibilités il ne restera que le SAV de TI, si ils prennent en charge les situations avec batteries déchargées...



Mieux vaut prévenir que guérir et heureusement, TI-Planet t'offre depuis plusieurs semaines un outil Ndless qui te permettra de vérifier la présence d'un logiciel de diagnostics dans ta calculatrice: nsNandMgr:

Ici, le logiciel confirme que la TI-Nspire CX CAS est bien munie d'un logiciel de diagnostics 3.1.0.20 pour TI-Nspire CX!

Et si jamais tu n'as pas de logiciel de diagnostics sur ta TI-Nspire CX ou CM, TI-Planet en a plusieurs à ta disposition et tu pourras les programmer avec nsNandMgr!

TI-Planet: toujours une longueur d'avance!

Liens:
nsNandMgr
Logiciels de diagnostics TI-Nspire CX et CM
Tutoriel de dépannage des TI-Nspire CX/CM bloquées à l'écran grisé de démarrage du système
Tutoriel de dépannage des TI-Nspire CX avec un système qui redémarre en boucle

[yatto]

Wahou, parfait, j'avais effacé le logiciel de diag. Maintenant je peux le remettre. Merci TI-Planet !
En effet, ma Nspire est assez vulnérable, sans Diag, si la batterie tombe (vraiment) à plat.

[critor]

Merci
Si c'est pas indiscret, pourquoi/comment tu l'avais effacé?

[quentin974]

Sauf quand le logiciel de diagnostic une batterie chargée à 100%-102%, alors que quand je la rallume, elle est au point critique, du moins selon l'os. Est-ce un bug du diagnostic, et peut-on y remédier ? Et pour essayer, y a t-il un tuto pour remettre le logiciel diagnostic sur CX CAS ?

[Yamashita Ren]

Tu as nclock installé ?
Si c'est le cas, c'est la faute à nclock.

Cette article me fait d'ailleurs penser que, dans la catégorie "ndless et la batterie", il serait intéressant d'avoir un outil ndless (si c'est possible) indiquant le niveau de charge de la calculatrice avec fiabilité.
L'autre jour j'ai reset (par hasard) la calculatrice avant un DS et je me suis retrouvé avec un niveau de batterie critique

[Levak]

Tu as nclock installé ?
Si c'est le cas, c'est la faute à nclock.

Cette article me fait d'ailleurs penser que, dans la catégorie "ndless et la batterie", il serait intéressant d'avoir un outil ndless (si c'est possible) indiquant le niveau de charge de la calculatrice avec fiabilité.
L'autre jour j'ai reset (par hasard) la calculatrice avant un DS et je me suis retrouvé avec un niveau de batterie critique

J'ai déjà regardé, et non, c'est leur API low level qui utilise seulement 7 niveaux de charge (100, 75, 50, 25, 10, 2, 0%) et les niveaux sont par la suite codés en dur, l'icone de la batterie est un icone en 7 exemplaires, etc ...

Le jour où j'avais cherché à faire ce que tu dis, je n'ai pas réussi à aller plus bas. On se perd dans les allocations dynamiques, les allocations sur la pile etc ... la valeur est mise à jour comme par magie suivant une interruption qu'on arrive pas à rattraper avec GDB... donc j'ai laissé tomber.

Pour éviter que ton problème se reproduise, si tu n'es pas sûr du niveau de la batterie, fait un simple reset. Après ce reset, il devrait afficher (moyennant la précision déplorable) le véritable taux de charge. Idem lorsque tu charges la batterie et que ça change pas.

[le solutionneur]

Mais t'as trouvé l'interruption ?
Tu pourrais pas la hooker pour voir ?

[Levak]

Mais t'as trouvé l'interruption ?
Tu pourrais pas la hooker pour voir ?

Je viens de dire qu'une interruption est déclenchée comme par magie et que je ne peux pas la debuger avec GDB, DONC, je ne connais pas son adresse, DONC je ne peux pas en voir le contenu, DONC je ne peux pas la hooker etc ..

D'autant plus que sur ému, la valeur de la batterie ne change jamais...

C'est vraiment dommage qu'on puisse pas watchdog un emplacement mémoire pour voir qui la modifie (je parle uniquement sur Nspire, GDB ne s'arrête jamais, même après un reset).

[le solutionneur]

Tu peux pas freeze le truc (lors du chargement du module) et faire une analyse du code pour target l'endroit où il crée son interruption ?

[Levak]

Tu peux pas freeze le truc (lors du chargement du module) et faire une analyse du code pour target l'endroit où il crée son interruption ?

Alors soit tu ne comprends pas ce qu'est une interruption, soit tu ne sais pas que l'OS fait 8Mo extrait, dont 5Mo de code assembleur, soit plus de 11000 routines.
Le "module" en question est séparé en deux parties :
- La partie qui met à jour la variable globale qui indique un niveau entre 0 et 6
- La partie qui lit la variable globale et retourne soit 0-6 soit le pourcentage réel (100, 75, 50, 25, 10, 2, 0%).

La partie qui met à jour est inconnue à ce jour car elle est déclenchée par interruption, c'est à dire qu'il n'y a pas de xref possible vers cette fonction (qu'on soit bien clair). Donc s'arrêter sur le "module" voudrait dire qu'il faille tester chaque nanoseconde des 30 secondes du chargement de l'OS ? C'est utopique ...

Le problème des variables globale est bien que ça scinde le code en deux parties complètement indépendantes vis à vis du code généré. Encore les variables statiques, on a une trace, mais pas les variables allouées sur la pile/tas....