Keil uVision MDK-Lite, scheda di rilevamento STM32F072B e API flash

Sto utilizzando MDK-Lite Versione 5.23 con una scheda "Discovery" STM32ro0BB-Disco STMicroelectronics e sto cercando di utilizzare l'esempio Flash fornito dagli esempi di Discovery.

Ho usato questa scheda e toolchain per altri esempi e ho codificato alcuni lavori SPI e GPIO. L'IDE funziona come un campione. Tuttavia, per questo particolare progetto posso creare il codice ed eseguirlo scaricando e utilizzando il pulsante di ripristino. Non riesco a utilizzare il debugger sul progetto non appena utilizzo la routine HAL_FLASHEx_Erase (). Una volta eseguita quella routine, l'IDE apre una finestra di dialogo "Impossibile accedere alla destinazione. Chiusura della sessione di debug".

Per quello che vale, so che non è un errore di programmazione perché se scarico il codice e quindi eseguo il codice premendo il pulsante di ripristino funzionerà. Ho usato questo stesso debugger con una scheda TI ed è stato in grado di programmare flash ed eseguire anche routine di flash. Sono abbastanza sicuro di non cancellare la parte di flash in cui è memorizzato il codice, quindi non è così.

Se passo oltre questa linea in main.c

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

quindi rilascia la sessione di debug. Se invece passo nella stessa linea e passo su ciascuna delle chiamate nella routine di cancellazione flash, allora funzionerà e alla fine uscirò dalla routine e posso eseguire il debug del resto del codice.

La mia ipotesi è che si tratti di un alimentatore collegato ad un certo livello. L'alimentazione esterna o la commutazione a bordo delle rotaie di alimentazione.

Per chiarire lo scenario, il debug funziona correttamente dopo un ripristino hardware, ma quando la destinazione cancella un blocco di flash, la connessione di debug viene interrotta?

Il debug non si preoccupa del corretto funzionamento del codice: puoi essere in stato di blocco e arrestare il debug dovrebbe comunque funzionare. L'unica cosa sul lato CPU che blocca il debug è un accesso AHB deadlock. Ciò significa che il problema riguarda l'interfaccia SWD tra STM32F7 e il chip di interfaccia USB-SWD di bordo (anche un STM32, presumo). Questo dispositivo ha alcuni switch di power rail a bordo che mi hanno confuso la prima volta che ho usato la scheda.

Vale la pena notare che la cancellazione del flash aumenterà l'attuale consumo del dispositivo: l'alimentatore esterno è all'altezza del lavoro e puoi usare un'alternativa?

Modifica: in base al tuo feedback che il superamento del codice in questione provoca l'arresto anomalo del debugger, mentre il passaggio singolo non lo fa, penso che il tuo problema sia correlato a questa domanda .

Il passaggio è implementato utilizzando un punto di interruzione (e polling per lo stato di arresto), mentre il passaggio singolo è supportato nell'hardware. Questo non spiega ancora perché il debugger sembra essere confuso, ma consente che il debugger stia tentando di accedere al codice (da flash) mentre il controller flash è attivo.

Sulla base di queste osservazioni, suggerirei di impostare un punto di interruzione dopo la cancellazione e di provare a evitare di innescare questo scenario.