Mon objectif est justement de partir d'une feuille blanche.
J'ai comparé avec le travail d'autre personnes mais je n'ai pas trouvé de différence majeur sur la partie compilation ou initialisation.
Le LPC1769 a comme avantage d'être très simple:
* Au reset, il récupère l'adresse du sommet de la stack à l'adresse 0x0000 et la copie dans le registre correspondant
* Il récupère ensuite l'adresse de la première instruction à exécuter à l'adresse 0x0004 et la copie dans le registre correspondant
* Il commence l'exécution
* Au reset, une mémoire, la Boot ROM, est mappée à l'adresse 0x0000:
* Le code qui s'y trouve s'exécute puis "re-mappe" la flash à l'adresse 0x0000
* Le code présent sur la flash prend le relais (chargement de l'adresse du sommet de la stack et de la première instruction)
* Les GPIO sont par défaut alimenté, connecté à une horloge active et connecté à une pin physique du uC
D'ailleurs, si l'écriture dans les registres depuis du code reset le CPU, avec OpenOCD j'arrive à lire et écrire directement dans les registres sans problème.
Ce qui me fait dire que le problème vient du code assembleur généré par GCC. Mais je ne trouve pas pourquoi.
[^] # Re: Pas certain que ça marche comme approche
Posté par Yuul B. Alwright . En réponse au message Code assembleur incorrect généré à partir du code C (ARM Cortex-m3) ?. Évalué à 1.
Merci pour ta réponse. :)
Mon objectif est justement de partir d'une feuille blanche.
J'ai comparé avec le travail d'autre personnes mais je n'ai pas trouvé de différence majeur sur la partie compilation ou initialisation.
Le LPC1769 a comme avantage d'être très simple:
* Au reset, il récupère l'adresse du sommet de la stack à l'adresse 0x0000 et la copie dans le registre correspondant
* Il récupère ensuite l'adresse de la première instruction à exécuter à l'adresse 0x0004 et la copie dans le registre correspondant
* Il commence l'exécution
* Au reset, une mémoire, la Boot ROM, est mappée à l'adresse 0x0000:
* Le code qui s'y trouve s'exécute puis "re-mappe" la flash à l'adresse 0x0000
* Le code présent sur la flash prend le relais (chargement de l'adresse du sommet de la stack et de la première instruction)
* Les GPIO sont par défaut alimenté, connecté à une horloge active et connecté à une pin physique du uC
D'ailleurs, si l'écriture dans les registres depuis du code reset le CPU, avec OpenOCD j'arrive à lire et écrire directement dans les registres sans problème.
Ce qui me fait dire que le problème vient du code assembleur généré par GCC. Mais je ne trouve pas pourquoi.