Stlink: Tenter de flasher sur STM32L052K8 corrompt la mémoire flash

C'est un problème étrange, je ne pouvais pas dire immédiatement ce qui cause le problème. Je pense que le chargeur L1 est compatible avec les puces L0 car elles sont presque les mêmes.

Cela semble un peu étrange - faites-moi savoir s'il y a des indicateurs de débogage ou quelque chose que je devrais activer pour fournir plus d'informations.

Essayez de flasher un binaire plat avec st-flash plutôt qu'un elfe.

Essayez de relire le flash dans un fichier et de le comparer, ou de l'examiner avec gdb, ou par exemple
x/32x 0x8000000

Vous devriez voir le début de votre table vectorielle...
D'où vient votre binaire et comment savez-vous qu'il est bon ?

De plus, étant donné que votre adresse semble être en RAM, quel est l'état de votre broche BOOT ?

Je vais jeter un œil - je voulais apprendre à flasher des fichiers .bin au lieu de télécharger des fichiers .elf avec un débogueur, de toute façon.

Le code était l'un des exemples de ST, mais je vais jeter un autre coup d'œil à l'emplacement de la table vectorielle.

La broche BOOT0 est mise à la terre, donc je ne pense pas qu'elle devrait démarrer dans la RAM.

Je reviendrai sur ces questions dans un jour ou deux - merci pour les conseils !

D'accord, j'ai essayé de flasher le programme de test L0 (en particulier, l'exemple d'initialisation LSI de ST) sur une carte L031K6 Nucleo-32, et cela fonctionne bien.

Sur le L051K8, cependant, j'observe toujours le problème. La principale différence est que j'utilise un dongle USB générique pour programmer la carte L051K8 et le débogueur ST-Link/V2-1 intégré pour la carte Nucleo L031K6. J'ai essayé de mettre à jour le firmware sur le débogueur USB, mais cela n'a pas aidé.

J'ai vérifié que la table vectorielle est correctement placée avec arm-eabi-none-nm dans les deux cas : 08000000 R g_pfnVectors

Flasher un fichier .bin sur le L051K8 avec st-flash write main.bin 0x08000000 génère une erreur mais signale toujours le succès. La connexion à la puce par la suite montre que le programme est bloqué à 0xFFFFFFFE, cependant.

Voici le résultat de st-flash :

st-flash 1.5.0
2018-04-23T23:26:42 INFO common.c: Loading device parameters....
2018-04-23T23:26:42 INFO common.c: Device connected is: L0x3 device, id 0x10386417
2018-04-23T23:26:42 INFO common.c: SRAM size: 0x2000 bytes (8 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 128 bytes
2018-04-23T23:26:42 INFO common.c: Ignoring 4 bytes of 0x00 at end of file
2018-04-23T23:26:42 INFO common.c: Attempting to write 18404 (0x47e4) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08004780 erased
2018-04-23T23:26:43 INFO common.c: Finished erasing 144 pages of 128 (0x80) bytes
2018-04-23T23:26:43 INFO common.c: Starting Half page flash write for STM32L core id
2018-04-23T23:26:43 INFO flash_loader.c: Successfully loaded flash loader in sram
2018-04-23T23:26:46 ERROR flash_loader.c: flash loader run error
2018-04-23T23:26:46 WARN common.c: l1_stlink_flash_loader_run(0x8000000) failed! == -1
2018-04-23T23:26:46 WARN common.c: 
write_half_pages failed == -1
142/143 pages written
2018-04-23T23:27:03 INFO common.c: Starting verification of write complete
2018-04-23T23:27:04 INFO common.c: Flash written and verified! jolly good!

Mais en regardant la mémoire Flash avec l'utilitaire GUI de ST, je vois l'hex du fichier .bin commençant à 0x08000000 ; cela ressemble à la table vectorielle au début du programme. Et la mémoire écrite semble se terminer à 0x080047E0, ce qui semble correct pour la taille du programme.

Je ne sais pas - si ce n'est pas quelque chose que quelqu'un d'autre peut reproduire, je suppose que cela pourrait être les puces ou les cartes que j'utilise.

Salut,

Même problème avec la carte blue-pill (STM32F103C8X)
Après chaque programme avec 'arm-none-eabi-gdb', j'ai réussi, le programme fonctionne bien dans la carte mais quand j'essaie de le programmer à nouveau, j'ai les problèmes suivants :

st-util

[ abdullatif@Host-001 ~]$ st-util
st-util 1.5.0
2018-05-04T23:47:27 INFO common.c: Chargement des paramètres de l'appareil....
2018-05-04T23:47:27 WARN common.c: Type de flash non valide, veuillez vérifier la déclaration de l'appareil
2018-05-04T23:47:27 INFO gdb-server.c: L'ID de la puce est 00000000, l'ID Core est 00000000.
2018-05-04T23:47:27 INFO gdb-server.c: Écoute à *:4242...
2018-05-04T23:47:40 INFO gdb-server.c: Trouvé 0 registres de point d'arrêt hw
2018-05-04T23:47:40 INFO gdb-server.c : GDB connecté.

gdb

[ abdullatif@Host-001 build]$ arm-none-eabi-gdb Stm32blink.elf
GNU gdb (GDB) 8.1
Copyright (C) 2018 Free Software Foundation, Inc.
Licence GPLv3+ : GNU GPL version 3 ou supérieure http://gnu.org/licenses/gpl.html
C'est un logiciel libre : vous êtes libre de le modifier et de le redistribuer.
Il n'y a AUCUNE GARANTIE, dans la mesure permise par la loi. Tapez "afficher la copie"
et "afficher la garantie" pour plus de détails.
Cette GDB a été configurée comme "--host=x86_64-pc-linux-gnu --target=arm-none-eabi".
Tapez « afficher la configuration » pour les détails de la configuration.
Pour obtenir des instructions sur les rapports de bogues, veuillez consulter :
http://www.gnu.org/software/gdb/bugs/ .
Trouvez le manuel GDB et d'autres ressources documentaires en ligne à l'adresse :
http://www.gnu.org/software/gdb/documentation/ .
Pour obtenir de l'aide, tapez « aide ».
Tapez "à propos du mot" pour rechercher les commandes liées au "mot"...
Lecture des symboles de Stm32blink.elf...fait.
(gdb) cible étendue à distance : 4242
Débogage à distance en utilisant : 4242
0x00000000 dans ?? ()
(gdb) charge
Section de chargement .isr_vector, taille 0x10c lma 0x8000000
Chargement raté
(gdb)

Je dois flasher le bootloader avec 'st-flash' si je veux que la carte fonctionne à nouveau.

Je ne suis pas convaincu que ce problème de F103 soit le même que ce que j'ai vu ; il semble assez bien pris en charge par cet outil, et le problème L0 se produit même sur une puce vierge.

Le titre original de ce numéro était incorrect, désolé; le comportement se produit sur les deux appareils suivants :

• STM32L052K8

• STM32L082KZ

J'ai regardé src/chipid.c et j'ai vu que seuls les manuels de référence pour les puces L0x1 et L0x3 étaient référencés pour les paramètres ; Les puces L0x2 pourraient-elles avoir des différences majeures ?

Le diff suivant semble résoudre complètement ce problème pour moi (avec un STM32L052K8), mais je suppose que ce n'est pas une solution idéale :

diff --git a/src/common.c b/src/common.c
index b9b7382..7d2480d 100644
--- a/src/common.c
+++ b/src/common.c
@@ -1647,7 +1647,8 @@ int stlink_erase_flash_page(stlink_t *sl, stm32_addr_t flashaddr)
 }

 int stlink_erase_flash_mass(stlink_t *sl) {
-    if (sl->flash_type == STLINK_FLASH_TYPE_L0) {
+    //if (sl->flash_type == STLINK_FLASH_TYPE_L0) {
+    if (sl->chip_id == STLINK_CHIPID_STM32_L0_CAT2 || sl->chip_id == STLINK_CHIPID_STM32_L0_CAT5) {
         /* erase each page */
         int i = 0, num_pages = (int) sl->flash_size/sl->flash_pgsz;
         for (i = 0; i < num_pages; i++) {

Ce changement supprime le comportement spécifique à L0 pour l'effacement en masse des puces identifiées avec l'étiquette générique L0x3 associée à l'ID 0x0417 .

Je ne sais pas pourquoi la logique spécifique à L0 pourrait causer des problèmes avec ces puces L0x2 'Catégorie-3' ; cela semble fonctionner correctement avec une carte Nucleo STM32L031, où la puce a un ID de 0x0425 qui s'identifie comme un périphérique de "Catégorie-2".

Avoir des problèmes similaires avec un STM32L151CC.
Il renvoie la même erreur et échoue à l'étape de vérification.
La validation manuelle de la mémoire avec l'utilitaire ST-Link montre que la mémoire flash est correctement écrite.
Aucune protection en lecture/écriture n'est définie sur l'appareil.

st-flash --reset write 'build/bin'/uartbridge-mbiot.bin 0x08000000
st-flash 1.4.0-57-g7651d21
2019-02-28T09:33:08 INFO common.c: Loading device parameters....
2019-02-28T09:33:08 INFO common.c: Device connected is: L1 Medium-Plus-density device, id 0x10f86427
2019-02-28T09:33:08 INFO common.c: SRAM size: 0x8000 bytes (32 KiB), Flash: 0x40000 bytes (256 KiB) in pages of 256 bytes
2019-02-28T09:33:08 INFO common.c: Attempting to write 14376 (0x3828) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08003800 erased
2019-02-28T09:33:08 INFO common.c: Finished erasing 57 pages of 256 (0x100) bytes
2019-02-28T09:33:08 INFO common.c: Starting Half page flash write for STM32L core id
2019-02-28T09:33:08 INFO flash_loader.c: Successfully loaded flash loader in sram
2019-02-28T09:33:12 ERROR flash_loader.c: flash loader run error
2019-02-28T09:33:12 WARN common.c: l1_stlink_flash_loader_run(0x8000000) failed! == -1
2019-02-28T09:33:12 WARN common.c: 
write_half_pages failed == -1
 55/ 56 pages written
2019-02-28T09:33:25 INFO common.c: Starting verification of write complete
2019-02-28T09:33:25 ERROR common.c: Verification of flash failed at offset: 0
stlink_fwrite_flash() == -1

@WRansohoff : Veuillez vérifier si le problème existe toujours dans la version v1.5.1.

Bien sûr, heureux de vérifier si cela se produit toujours avec les puces STM32L0 de catégorie 2.

Cependant, la plupart de mes planches sont stockées dans un distributeur automatique, donc je ne pourrai probablement pas le faire avant d'avoir fini de déménager en mai. Désolé pour ça.

@WRansohoff : Une mise à jour à ce sujet ?

Bonjour, j'ai le même problème avec STM32L433RC.
J'utilise st-util 1.6.1

Essayez d'effacer le flash de votre MCU
Utilisez cet article : https://electronics.stackexchange.com/questions/204996/stm32-st-link-cannot-connect-to-mcu-after-successful-programming

Peut-être avez-vous oublié de marquer les broches SWD/JTAG sur STM32Cube