Bug au LINK sur PIC12F629 et 12F675

Bug au LINK sur PIC12F629 et 12F675

1 Le fichier 12F629_G.LKR
1.1 Le fichier d'origine MICROCHIP
1.2 Les enseignements
1.3 Le nouveau fichier 12F629_G.LKR
2 Conclusions

Si vous arrivez directement sur cette page par un moteur de recherche, vous pouvez avoir accès à la table des matières et à chaque article, en page d'accueil.    L'accès se fait par l'un des deux liens en tête de colonne de droite ----->

ATTENTION à compter du 15/09/2019 les commentaires ne seront plus possibles à causes de quelques imbéciles qui font du spam pour le plaisir de nuire ! désolé  !

---

Préambule

C'est pour vous éviter de tomber dans le piège que cet article est destiné. Il concerne la version 8.4 de MPASM, mais peut-être aussi quelques autres releases et seul le constructeur pourrait le dire…

Je pensais avoir assez de place pour mon application de compteur horaire avec un PIC12F629, tout petit PIC qui coûte quelques Euros suivant les fournisseurs et parfois moins d'un Euro, au prix souvent moins cher qu'un traditionnel circuit CMOS.

Je travaillais donc et au gré d'une modif, j'ai eu une erreur au LINKER. ("Error - section ' .org_2' can not fit the absolute section …")
J'ai cherché un bon moment si une ligne n'avait pas "sauté" par mégarde…Mais rien !
Alors je suis revenu en arrière, j'ai enlevé ma dernière modif qui n'était pas trop longue et ce fut à nouveau bon ! (En assembleur)
Puis j'ai cherché une à une les instructions et je suis tombé sur la bonne. Cette instruction était un bsf sur une I/O tout ce qu'il y a de plus banal.
Alors je l'ai enlevé et j'ai ajouté plus loin une autre instruction (nop) et là, de nouveau problème.

Cela a déclenché ma suspicion sur une adresse mémoire.
Il faut dire que lors du développement sur un tel PIC avec une seule banque et seulement 1K de programme, je ne me tracassais pas trop sur les limites de banques et de pages qui n'existent pas ou peu !

J'avais regardé sur le .LST, la MAP et je voyais que j'avais encore pas mal de place pour le programme environ ¼ de disponible, mais vu les croix d'occupation mémoire qui allaient jusqu'à 0x3B0 environ pour les tables, je ne me suis pas véritablement méfié.

C'est en regardant l'adresse indiquée que j'ai eu la puce à l'oreille puisque je restais bloqué en LINK dès que je dépassais l'adresse 0x2FF.
Alors non ce n'est pas le circuit puisque je suis en MPASM et simulateur, c'est bien au niveau programme !

Quelques recherches sur internet me guident un peu vers le fichier de LINK (.LKR) que j'ai toujours ignoré "royalement" puisque tout marchait normalement.

Il est vrai que travaillant essentiellement en assembleur, le fichier de LINK m'est toujours passé inaperçu, car je n'en ai jamais eu besoin !
Mais dans ce cas j'ai été obligé de m'y plonger, ainsi que dans la doc spécifique.
Ce n'est pas toujours très explicite et ce message d'erreur est apparemment fréquent et les causes en sont souvent dûes à des emplois particuliers en langage évolué, en assemblage avec code relogeable et en l'utilisation de sous programmes multiples à lier.
Mais dans mon cas c'était très simple ?

Eh bien le fichier MPASM, pourtant d'origine MICROCHIP est bloqué avec une mémoire programme à 0x2FF maxi.

Après il faut essayer de "bidouiller", mais ce sont des erreurs complémentaires de recouvrement de zones qui apparaissent (overlap) Il faut donc jongler et comprendre à quoi servent tous ces paramètres (et la raison du "protected") au gré des différentes erreurs qui apparaissent.

1 Le fichier 12F629_G.LKR

1.1 Le fichier d'origine MICROCHIP

C'est un fichier ASCII en clair heureusement… J'ai d'abord sauvegardé l'existant après quelques essais infructueux car au bout d'un certain temps on finit par tout mélanger, surtout quand on navigue en "terre inconnue"…
(Je suppose que ce fichier n'est pas modifié suivant que l'on travaille en adressage absolu ou relogeable, auquel cas, cela pourrait peut-être partiellement s'expliquer, mais dans tous les cas il me semble un peu anormal que de 0x300 à 0x3FF on ne puisse pas avoir accès en travail de base, car ce PIC est bien définit pour 1K mémoire !)

Voici le fichier donc le fichier d'origine situé sous :

program files\microchip\MPASM Suite\LKR (pour une installation standard)

// File: 12f629_g.lkr
// Generic linker script for the PIC12F629 processor

#IFDEF _DEBUG
 
  LIBPATH  .
 
  CODEPAGE   NAME=page     START=0x0      END=0x2FF
  CODEPAGE   NAME=debug    START=0x300    END=0x3FE    PROTECTED
  CODEPAGE   NAME=.oscval  START=0x3FF    END=0x3FF    PROTECTED
  CODEPAGE   NAME=.idlocs  START=0x2000   END=0x2003   PROTECTED
  CODEPAGE   NAME=.icdinst START=0x2004   END=0x2004   PROTECTED
  CODEPAGE   NAME=.mfgcode START=0x2005   END=0x2005   PROTECTED
  CODEPAGE   NAME=.devid   START=0x2006   END=0x2006   PROTECTED

etc….etc…

#ELSE
 
  LIBPATH  .
 
  CODEPAGE   NAME=page     START=0x0      END=0x3FE
  CODEPAGE   NAME=.oscval  START=0x3FF    END=0x3FF    PROTECTED
  CODEPAGE   NAME=.idlocs  START=0x2000   END=0x2003   PROTECTED

On constate bien que la première ligne des CODEPAGE "NAME=page" est bien limitée à 0x2FF …! C'est la bonne piste !
On voit également le DEBUG qui ne colle pas non plus en ligne 2 ! Seul L'OSCVAL est correct en ligne 3 !

1.2 Les enseignements

Les "//" sont des commentaires et vous pouvez en ajouter à votre gré.
Des noms prédéfinis commandent les différents paramètres
CODEPAGE définit les différentes zones mémoire programme et mémoire datas et registres.
PROTECTED indique que le Debug ne pourra pas accéder à certaines zones.
Les zones CODEPAGE ne doivent PAS se recouvrir sinon il y un message "overlap"
Je viens de vérifier que le nom du fichier LKR est obligatoire  avec le nom_PIC_g.LKR (Voir le message si absent)

Dans ce cas du 12F629_g.LKR, il y a une instruction conditionnelle de LINK--->  #IFDEF _DEBUG suivie de #ELSE. Mais comme _DEBUG est mentionné, c'est le IF qui l'emporte et non le ELSE !

Pour le reste des instructions de LINK, je ne m'en suis pas occupé, mais cela semble un peu "digeste" surtout en observant d'autres PIC, mais certains n'ont pas d'instructions conditionnelles comme le très connu 16F628.

1.3 Le nouveau fichier 12F629_G.LKR

(En rouge, les modifications réalisées)

// File: 12f629_g.lkr
// Generic linker script for the PIC12F629 processor
// modifié par bricolsec le 19/02/2012 pour franchir la valeur 2FF
// le fichier d'origine est 12F629_g_save.lkr

#IFDEF _DEBUG
 
  LIBPATH  .
 
  CODEPAGE   NAME=page     START=0x0      END=0x3FE
  CODEPAGE   NAME=debug    START=0x0      END=0x3FE     ████████
  CODEPAGE   NAME=.oscval  START=0x3FF    END=0x3FF    PROTECTED
  CODEPAGE   NAME=.idlocs  START=0x2000   END=0x2003   PROTECTED
  CODEPAGE   NAME=.icdinst START=0x2004   END=0x2004   PROTECTED.......etc

2 Conclusions

Si vous êtes comme moi surpris de ne pas pouvoir dépasser 0x2FF, alors prenez votre "bloc-notes" ou tout autre éditeur et faites ces modifications.

Le PIC12F675 est un "grand" frère du 629 ayant quelques entrées analogiques en plus. Il bénéficie de la même maladie d'origine pour la taille mémoire.
Je supposais que MPASM ne modifiait pas ce fichier suivant le mode d'assemblage, ainsi qu'énoncé en début de § 1, et je pense que c'est vrai puisque je n'ai jamais utilisé le 12F675 et que le fichier a la même maladie !
J'en conclu donc que c'est une erreur de MICROCHIP !

Ce problème de LINK peut avoir de si nombreuses origines qu'il est à priori délicat d'incriminer tout de suite le fichier livré, ici MPASM 8.4, mais cela est pourtant le cas dans ce contexte précis d'assemblage.

Je dois dire que j'avais déjà eu des problèmes lors du développement du détecteur de rayonnement, mais ayant pu rester en dessous de la limite (je suppose) j'ai dû considérer que j'avais une "cagatte" inconnue…Ça marchait et c'était bien comme cela !

Cette fois il me fallait un peu plus de place programme, alors il a bien fallu "mettre les mains dans le cambouis" et trouver la raison ! C'est fait.

Allez assemblez / linkez 1 K complet (et non les ¾) !

_____ ( retour en début d'article ) ____

 _____ ( retour accueil lokistagnepas ) ____
_____ ( retour accueil bricolsec ) ____