Il puntatore ha assegnato in modo casuale valori misteriosi (A5A5A5A5 e FFFFFFFF) su uno stm32 utilizzando freeRTOS causando un errore.

Question

Ho un problema con un hardfault che appare in momenti apparentemente casuali in cui un puntatore punta a un indirizzo A5 o FF (il mio spazio di memoria consentito è lontano sotto a 80000000 e oltre). Sembra essere sempre lo stesso puntatore con questi due valori.

sto usando un sistema embedded in esecuzione un processore STM32F205RE che comunica con un/bluetooth/chip GPS fm chiamato cg2900 dove si verifica questo errore.

Utilizzando un debugger, è possibile notare che il puntatore punta rispettivamente all'indirizzo A5 e FF durante alcuni test. Tuttavia sembra accadere a volte casuali, a volte riesco a eseguire il test per un'ora senza un fallimento mentre altre volte si blocca 20 secondi.

Io corro FreeRTOS come scheduler per passare da compiti diversi (uno per radio, una per bluetooth, una per altra manutenzione periodica) che potrebbe interferire in qualche modo.

Quale può essere la causa di questo? Poiché è in esecuzione hardware personalizzato, non è possibile escludere che si tratti di un problema hardware (potenzialmente). Qualche suggerimento (nessun gioco di parole) su come affrontare il debug del problema?

EDIT:

Dopo ulteriori indagini, sembra che sia molto casuale in cui si blocca, non solo tale puntatore specifica. Ho usato un gestore hardfault per ottenere i seguenti valori di questi registri (tutti i valori in esadecimale):

semi-lungo periodo prima di schianto (minuti):

R0 = 1 
R1 = fffffffd 
R2 = 20000400 
R3 = 20007f7c 
R12 = 7 
LR [R14] = 200000c8 subroutine call return address 
PC [R15] = 1010101 program counter 
PSR = 8013d0f 
BFAR = e000ed38 
CFSR = 10000 
HFSR = 40000000 
DFSR = 0 
AFSR = 0 
SCB_SHCSR = 0 

brevissimo termine prima di crash (secondi):

R0 = 40026088 
R1 = fffffff1 
R2 = cb3 
R3 = 1 
R12 = 34d 
LR [R14] = 40026088 subroutine call return address 
PC [R15] = a5a5a5a5 program counter 
PSR = fffffffd 
BFAR = e000ed38 
CFSR = 100 
HFSR = 40000000 
DFSR = 0 
AFSR = 0 
SCB_SHCSR = 0 

un altro corto (secondi):

R0 = 0 
R1 = fffffffd 
R2 = 20000400 
R3 = 20007f7c 
R12 = 7 
LR [R14] = 200000c8 subroutine call return address 
PC [R15] = 1010101 program counter 
PSR = 8013d0f 
BFAR = e000ed38 
CFSR = 1 
HFSR = 40000000 
DFSR = 0 
AFSR = 0 
SCB_SHCSR = 0 

Dopo un lunghissimo periodo (1 ora +):

R0 = e80000d0 
R1 = fffffffd 
R2 = 20000400 
R3 = 2000877c 
R12 = 7 
LR [R14] = 200000c8 subroutine call return address 
PC [R15] = 1010101 program counter 
PSR = 8013d0f 
BFAR = 200400d4 
CFSR = 8200 
HFSR = 40000000 
DFSR = 0 
AFSR = 0 
SCB_SHCSR = 0 

sembra bloccarsi nello stesso punto la maggior parte del tempo. Ho regolato la memoria in base ai suggerimenti precedenti, ma ho ancora lo stesso problema.

Grazie per il vostro tempo!

Cordiali saluti

Answer 1

gira che il problema è stato causato dalla memoria. Poiché eseguivo il processore con la massima velocità (120 Mhz) e un'alimentazione a 1,8 volt (progettata principalmente per 3 volt), avevo alcune condizioni di gara con la memoria. Risolto usando uno stato di attesa più alto.

Answer 2

Nel suo commento si parla che questo puntatore viene esplicitamente assegnato una volta poi mai scritto. In tal caso, dovresti almeno dichiararlo const e utilizzare l'inizializzazione anziché l'assegnazione, ad es.

arraytype* const ptr = array ; 

che consentirà al compilatore di rilevare eventuali scritture esplicite. Tuttavia è più probabile che il puntatore sia corrotto da un errore di codifica non correlato.

Il debug su chip Coretx-M3 supporta i punti di accesso ai dati; dovresti impostare un tale punto di interruzione sul puntatore in questione in modo che tutti gli accessi in scrittura siano intrappolati. Avrai una pausa sull'inizializzazione, poi su quella sulla modifica - intenzionale o meno.

Possibili cause sono l'overrun di un array adiacente o di una pila di fili.

Answer 3

Se si è tentato di spostare l'array e continua con lo stesso problema,

poi qualche compito è straripante.

Come lei ha ricordato, si sta utilizzando FreeRTOS, e perché il comportamento è casuale è probabile che qualcosa non va con le impostazioni STACK_SIZE nelle chiamate a xTaskCreate

Questo di solito accade quando la dimensione allocata è meno di quello che davvero bisogno.

Se si legge la documentazione relativa a usStackDepth, si è notato che rappresenta un moltiplicatore e non il numero di byte.

io personalmente escluderei problemi hardware nel vostro bordo embedded e mi concentrerò sui problemi di configurazione del FreeRTOS