Stlink: STM32L422CB : st-flash ne parvient pas à flasher l'image ihex

Qui peut regarder ça de plus près ?

Je suggère une vérification avec la même carte et d'autres outils flash afin que nous puissions confirmer qu'il ne s'agit pas d'un problème matériel.
La vérification a échoué au tout début, donc s'il ne s'agit pas d'un problème matériel, il peut y avoir des problèmes dans les flashloaders. Malheureusement, la vérification du code d'erreur dans les flashloaders (si possible) n'est pas appliquée sur la plupart des modèles. Je suggérerais d'imprimer toutes les valeurs de registre après l'échec du flash, avec st-util et ( gdb ou lldb ).

J'ai essayé avec les deux, un véritable st link v2 et l'une de ces copies bon marché de Chine. Il échoue sur les deux. Je regarderai les registres plus tard quand j'aurai un peu plus de temps.

Les "outils flash" que j'ai mentionnés font référence à openocd ou aux outils officiels de ST. Désolé pour l'expression ambiguë. Lorsque vous vérifiez les valeurs du registre, il serait préférable d'imprimer la valeur du registre STM32_FLASH_SR , située dans STM32_FLASH_REGS_BASE + 0x10. STM32_FLASH_REGS_BASE est 0x40022000 sur STM32L4.

Désolé de répondre si tard.
J'ai essayé de flasher quelques fichiers hexadécimaux différents de différentes tailles, st-flash efface avec succès les pages nécessaires (vérifié en examinant le contenu de la mémoire avec l'utilitaire st link), mais ne parvient pas à flasher comme je l'ai dit dans le message initial.
Flash réussit lors du flashage de l'hexagone avec l'utilitaire st link ou du dfu correspondant avec l'outil st dfu, donc je dirais que ce n'est pas un problème matériel.

Voici ce que lit STM32_FLASH_SR :

L'indice est que FLASH_SR montre que PGSERR et PGAERR sont définis, c'est-à-dire qu'il y a des problèmes d'alignement. Si vous pouvez fournir les valeurs de registre à usage général après un échec de programmation (avec gdb , info registers sans réinitialiser la carte avant de l'attacher) et lancez st-flash avec --debug activé, je pense que nous pourrons approfondir nos recherches avec le journal de débogage et les valeurs d'enregistrement.

Edit : ce serait mieux si vous pouviez fournir la valeur d'origine STM32_FLASH_SR avant de flasher.

ce sont les registres après l'échec du flash (connecté sans reset).

Voici la sortie avec --debug set :
log.txt

@lulle2007200 dans le courrier que j'ai reçu, vous avez dit qu'avec —debug il clignote sans erreur. J'ai remarqué que tu l'avais édité.
Y a-t-il bien eu un flashage réussi, avec le débogage activé ?

Si c'est le cas, il peut s'agir d'un problème de synchronisation, tout comme celui de la série f0.

D'après le journal, les choses semblent aller bien avant de courir. les registres à usage général contiennent des valeurs difficiles à expliquer. Si r0 était zéro au tout début, peut-être des problèmes avec les fonctions qui écrivent des valeurs dans des registres ?

Cela n'a pas fonctionné, j'ai foiré en essayant de rediriger la sortie de st-flash vers un fichier. il s'est avéré qu'il ne fonctionnait pas du tout, mais je l'avais flashé avant d'utiliser l'utilitaire st link ...
De plus, j'ai cliqué sur Fermer et commenter au lieu de commenter par accident, désolé pour la confusion.
Je jetterai un autre coup d'oeil demain.

@lulle2007200 : Une mise à jour à ce sujet ?

J'ai un peu oublié ça, la vie s'est mise en travers du chemin.
st-flash ne parvient pas à effacer et à flasher le fichier hexadécimal fourni.
J'ai plusieurs fichiers de tailles différentes, cela ne fonctionne avec aucun d'entre eux. Notez que les flasher avec l'utilitaire officiel ST-Link fonctionne parfaitement.
J'ai joint un journal de la sortie st-flash et les valeurs des registres à usage général et STM32_FLASH_SR, les deux, avant et après la tentative de flash.
log.txt

Maintenant, nous recherchons un développeur qualifié qui connaît en quelque sorte la série L4 pour avoir la chance de trouver un correctif.