Connecteur J04 - Page 3

Ok, je pensais que c'était plus sur l'emission que la reception ^^

hwti (./58) :
Oui, mais sur les 89 la fréquence du CPU n'est pas stable (oscillateur RC, dépend notamment de l'état des piles, et varie d'une calc à l'autre).
Il me semble que la tolérance pour du RS232 est de l'ordre de 2%.

En réalité, c'est +/- 2% (soit 4.

C'est peut-être faisable, du moins après l'avoir calibré pour une calc donnée tant que les piles ne s'usent pas trop.

Effectivement, il faut calibrer et là, j'ai pas de solution miracle car il n'y a aucun moyen de prévoir la suite de bit qui va être envoyée...

tu peut pas calibrer avec un PC par exemple en envoyant une serie de 0xAA (ou 0x55) a la bonne vitesse ?

si, on peut, mais pas à mettre dans le protocole
plutot avoir une routine de test, et se baser sur la réception de 0b10000001, soit 0x81, ce qui donne un délai de 6 bits entre le front descendant et le front montant suivant, comme ça le délai d'un bit est le 1/6e de la mesure, c'est plus précis

roms (./62) :
En réalité, c'est /- 2% (soit 4.

Ca représente la tolérance de qui pour quoi ?
On ne pourrait pas dire que 8 bit + 1 bit start + 1 bit stop = 10 bit avec une marge d'erreur de 1/2 bit ça donne 1/20 d'erreur possible, soit 0,6Mhz pour du 12 Mhz ? Est-ce que les 68k ont plus de variation que ça en fonction des piles pour un modèle d'HW donné ?

>> Ca représente la tolérance de qui pour quoi ?
Pour la fréquence de l'horloge de transmission

>>On ne pourrait pas dire que 8 bit + 1 bit start + 1 bit stop = 10 bit avec
>>une marge d'erreur de 1/2 bit ça donne 1/20 d'erreur possible, soit 0,6Mhz
>>pour du 12 Mhz ?
ça doit faire ça

>>Est-ce que les 68k ont plus de variation que ça en fonction des piles pour
>>un modèle d'HW donné ?
bin tu vas nous le dire

squalyl (./66) :
>>On ne pourrait pas dire que 8 bit 1 bit start 1 bit stop = 10 bit avec
>>une marge d'erreur de 1/2 bit ça donne 1/20 d'erreur possible, soit 0,6Mhz
>>pour du 12 Mhz ?
ça doit faire ça

1/20, soit 5%, ce qui donne +/- 2,5% (la tolérance est valable à l'émission et à la réception, d'où la division par 2)
On peut tolérer +/- 5% si le baudrate d'émission est précis (mais difficile de savoir de quelle source c'est dérivé sur la nspire, si c'est un quartz ou un RC).

si c'est un SoC ce sera dérivé de l'horloge principale, qui doit être basée sur un quartz+PLL... oui on voit un oscillateur de 27 MHz sur le PCB #1 de bloo.

ExtendeD (./20) :
X (affiche "Ready to install test image") : Une option pour le boot 2 au lieu du boot 1 cette fois. Boot 1 indique "Boot option: Normal (3 keys pressed)". Boot 2 indique "Boot option: Download Temp" et boot normalement.

J'ai fait les tests moi même : j'ai finalement quelque chose qui se rapproche plus de ce que moi et geogeo voyions, peut-être parce qu'il faut garder les touches appuyées au moment du chargement de Boot 2 et pas seulement de Boot1.

Le Boot 2 émet :

Keypad request, preparing to load a test image.
Checking the battery level.
Battery level is OK.
Begin XMODEM file transfer.
§§§§§§§BOOT2 Error: donwload failed

(les § apparaissent petit à petit)
La calc affiche d'abord "Ready to install test image", puis "System Error" avec le petit panneau.

Je n'arrive pas à envoyer un fichier en X-Modem.

En fait HyperTerminal échoue lamentablement avec X-Modem. Tera Term arrive à réaliser des transferts lui.
Maitenant j'ai un "File saved. Loading temp image... Error loading temp image"

ah, ok.
sinon, sous ht, essaye avec le protocole 1K-XModem
Au boulot on doit prendre ça pour uploader le soft de nos modems, pas le xmodem normal.

ExtendeD (./69) :

ExtendeD (./20) :
X (affiche "Ready to install test image") : Une option pour le boot 2 au lieu du boot 1 cette fois. Boot 1 indique "Boot option: Normal (3 keys pressed)". Boot 2 indique "Boot option: Download Temp" et boot normalement.

J'ai fait les tests moi même : j'ai finalement quelque chose qui se rapproche plus de ce que moi et geogeo voyions, peut-être parce qu'il faut garder les touches appuyées au moment du chargement de Boot 2 et pas seulement de Boot1.

Le Boot 2 émet :

Keypad request, preparing to load a test image.
Checking the battery level.
Battery level is OK.
Begin XMODEM file transfer.
§§§§§§§BOOT2 Error: donwload failed

(les § apparaissent petit à petit)
La calc affiche d'abord "Ready to install test image", puis "System Error" avec le petit panneau.

Je n'arrive pas à envoyer un fichier en X-Modem.

&

./70

Faut encore trouver le format, mais c'est un sacré bon en avant !

squalyl (./71) :
sinon, sous ht, essaye avec le protocole 1K-XModem

Marche pas mieux.

Apparemment le diags software doit faire 377 octets et la test image 554 octets.
Ce qui me fait dire ça c'est que si on en envoie moins la nspire réagit pas, et si on envoie plus elle acquitte avant d'avoir attendu la fin de la réception (ça montre aussi que les transferts X-Modem sont toujours actifs même quand ils n'ont pas de sens).
Mais peut-être que les tailles attendues dépendent du contenu du fichier...

tu envoies quoi là ? des 0x00 ?

Du texte qui n'a rien à voir.
Finalement effectivement, la taille dépend bien du contenu.

sans doute un champ taille.

ça fait quoi si t'envoies que des zéros?

Un joli écran tout abîmé (et il acquitte jamais la fin de la réception de l'image) : http://picasaweb.google.fr/olivier.armand/JTAGAndRS232OnTINspire/photo#5230410117269616194
Tiens, on va le secouer sec leur format.

Integer overflow? Peut-être que les données à envoyer commencent par la taille, y compris les k octets de taille. Donc si on envoit une taille nulle, il attend -k octets restants, c'est-à-dire en pratique UINT_MAX-k+1. Et il est probable que ça engendre un buffer overflow, qui cause l'écran abîmé.

Essaie d'envoyer 4 octets nuls, puis un bon paquet de nops, puis des instructions ARM valides.

Non, même avec une grosse en-tête de zéro je n'ai pas réussi à la faire réagir, elle ne plante pas ni n'acquitte l'image (mais nop sont des boucles sur elles-mêmes).
Y'a certains jeux de données qui ralentissent bizarrement fortement le transfert.

La réception d'un DIAGS Software plein de zéros n'abîme pas l'écran, le format de fichier ne doit pas être le même.

Hum, je crois que j'ai été un peu ambitieux, j'ai tenté de charger un boot2.
Evidemment il reste maintenant coincé dans le boot1, l'image du boot2 est invalide.

arg !

Il y a un boot2.img dans les TINspire.tnc, il m'avait tenté.

Je ne connais pas les nspires : tu crois que tu vas pouvoir réinitialiser quand même, ou à priori c'est mort ?

Bah là c'est mal barré, un moins que le JTAG fonctionne, où qu'on trouve un jour le format et le contenu de ce boot 2.

Par curiosité est-ce que quelqu'un qui aurait installé l'OS 1.4 sur une Nspire standard aurait une nouvelle version de boot 2 (genre 1.4.1571 au lieu de 1.1.8981) ? Je crois qu'on voit ça dans le menu d'infos.

Tu peux tenter la garantie, ou l'échange au magasin ?

En espérant qu'ils ne regardent pas le dock plein de soudure.
Je vais continuer d'abord les tests JTAG avec celle-ci pour éviter une resoudure.

non mais c'est positif quand même. ca veut dire que l'image à charger contient une adresse de chargement en plus de la taille

ça coute combien une nspire? ptet on peut se cotiser

sinon, elle a l'air mûre pour passer à l'étape 2

Bah peut-être bien, si ça peut faire avancer...

squalyl (./88) :
ca veut dire que l'image à charger contient une adresse de chargement en plus de la taille

Pourquoi ?

ben en uploadant un fichier "boot2" t'as viré le truc correspondant, mais en uploadant n'importe quoi, t'as pas tout cassé. donc y'a un truc qui lui a dit "écrase le boot2" (c'est bien ça qui s'est passé?)