Carte Keil uVision MDK-Lite, STM32F072B-Discovery et API flash

J'utilise MDK-Lite version 5.23 avec une carte STMicroelectronics STM32F072B-Disco "Discovery" et j'essaie d'utiliser l'exemple Flash fourni par les exemples Discovery.

J'ai utilisé cette carte et cette chaîne d'outils pour d'autres exemples et j'ai codé des travaux SPI et GPIO. L'IDE fonctionne comme un champion. Cependant, pour ce projet particulier, je peux créer le code et l'exécuter en téléchargeant et en utilisant le bouton de réinitialisation. Je ne peux pas utiliser le débogueur sur le projet dès que j'utilise la routine HAL_FLASHEx_Erase (). Une fois que j'exécute cette routine, l'EDI ouvre une boîte de dialogue "Impossible d'accéder à la cible. Arrêt de la session de débogage."

Pour ce que ça vaut, je sais que ce n'est pas une erreur de programmation car si je télécharge le code puis l'exécute en appuyant sur le bouton de réinitialisation, cela fonctionnera. J'ai utilisé ce même débogueur avec une carte TI et il était également capable de programmer le flash et d'exécuter des routines flash. Je suis sûr que je n'efface pas la partie de flash où le code est stocké, ce n'est donc pas ça.

Si je enjambe cette ligne dans main.c

if (HAL_FLASHEx_Erase(&EraseInitStruct, &PageError) != HAL_OK)

puis il abandonne la session de débogage. Si au lieu de cela j'entre dans la même ligne, puis que je passe par-dessus chacun des appels dans la routine d'effacement flash, cela fonctionnera et finira par sortir de la routine et je pourrai déboguer le reste du code.

Je suppose que c'est une alimentation liée à un certain niveau. Soit l'alimentation externe, soit la commutation embarquée des rails d'alimentation.

Pour clarifier le scénario, le débogage fonctionne correctement après une réinitialisation matérielle, mais lorsque votre cible efface un bloc de flash, la connexion de débogage est interrompue?

Le débogage ne se soucie pas du bon fonctionnement du code - vous pouvez être dans un état de verrouillage et l'arrêt du débogage devrait toujours fonctionner. La seule chose du côté CPU qui verrouille le débogage est un accès AHB bloqué. Cela signifie que le problème est lié à l'interface SWD entre le STM32F7 et la puce d'interface USB-SWD intégrée (également un STM32, je présume). Cet appareil a une commutation de rail d'alimentation intégrée qui m'a dérouté la première fois que j'ai utilisé la carte.

Il convient de noter que l'effacement du flash augmentera la consommation de courant de l'appareil - votre bloc d'alimentation externe est-il à la hauteur, et pouvez-vous utiliser une alternative?

Edit: Sur la base de vos commentaires, le fait de dépasser le code en question provoque le blocage du débogueur, contrairement à l'étape unique, je pense que votre problème est lié à cette question .

Le basculement est implémenté à l'aide d'un point d'arrêt (et d'interrogation pour l'état d'arrêt), tandis que l'étape unique est prise en charge par le matériel. Cela n'explique toujours pas pourquoi le débogueur semble être confus, mais permet qu'il soit possible que le débogueur essaie d'accéder au code (à partir du flash) alors que le contrôleur flash est actif.

Sur la base de ces observations, je vous suggère de définir un point d'arrêt après l'effacement et d'éviter de déclencher ce scénario.