STM32F4 & Slackware

[simo85]

Riesci a sapere con quale versione del kernel la board ha funzionato ?

Si, giustamente ieri ho contattato il mio conoscente a cui funziona la board.

Il kernel in uso sulla distribuzione Ubuntu 12.1 è 3.2.0-49-generic-pae.

[simo85]

La cosa strana è che non riesce a leggere il chip id e non riesce a trovalo tra quelli noti.

Si, anche di questo me ne ero reso più o meno conto, anche perché nella cartella del progetto nel file LibUsb.h sono dichiarati gli ID del fabbricante e prodotto.

Codice: Seleziona tutto

~ $ cat LibUsb.h | grep ST
const quint16 USB_ST_VID = 0x0483;
const quint16 USB_STLINK_PID = 0x3744;
const quint16 USB_STLINKv2_PID = 0x3748;


[xyz]

I numeri che hai riportato sono i VID e PID del USB, sono un'altra cosa rispetto all'errore riportato, quello che non rivela è il "chip id". Nel file "res/devices.xml" c'è la base dati con tutte le informazioni dei chip STM32 sopportati. II programma contatta la board per avere il chip id, ritorna 0, cerca 0 nell'entità "chip_id" nel file XML, non lo trova e segnala errore.

C'è un errore di comunicazione tra la tua board e il programma, francamente non si riesce a capire se è colpa del kernel o di qualche altra incompatibilità hardware o software.

[simo85]

C'è un errore di comunicazione tra la tua board e il programma, francamente non si riesce a capire se è colpa del kernel o di qualche altra incompatibilità hardware o software.

Si. Ho lanciato il programma da root e questo è quello che ne è venuto fuori..

Codice: Seleziona tutto

# $ ./qstlink2

(process:5252): GConf-WARNING **: Client failed to connect to the D-BUS daemon:
Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

(process:5252): GConf-WARNING **: Client failed to connect to the D-BUS daemon:
Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

(process:5252): GConf-WARNING **: Client failed to connect to the D-BUS daemon:
Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
QGtkStyle was unable to detect the current GTK+ theme.
Qt: Session management error: Authentication Rejected, reason : None of the authentication protocols specified are supported and host-based authentication failed
Verbose level: 2

(process:5252): GConf-WARNING **: Client failed to connect to the D-BUS daemon:
Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
Info: Devices list loaded.
Info: Found an ST Link V2.
Info: Opening device...
Info: Device Open.
Error: Device not found!
Info: Disconnected.
# $


Che è l'output di dbus-monitor

Codice: Seleziona tutto

# $ dbus-monitor
Failed to open connection to session bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.


Da un'altra sessione shell ho controllato che il processo 4621 fosse il programma qstlink2

Codice: Seleziona tutto

$ ps aux | grep 5252
root      5252  2.2  0.5  59096 15880 pts/0    S+   23:46   0:00 ./qstlink2
simo      5260  0.0  0.0   2720   788 pts/1    S+   23:46   0:00 grep 5252


[xyz]

Quei messaggi di avvertimento sono normali se D-BUS è configurato alla massima sicurezza. Ti sta semplicemente avvertendo di evitare di lanciare programmi grafici, con chiamate poco sicure per la sicurezza del sistema, con l'utente root. La maggior parte dei programmi di sistema utilizzano la linea di comando senza nessuna grafica.

Nessun di quei messaggi di D-BUS (è solo software non è hadware) riguarda i problemi di connessione con la tua STM32F4.

[simo85]

Ho fatto una prova con una Ubuntu 12.1 e neanche con questa funziona.. Ma già me lo immaginavo dato che non funzionava con un 12.04.

[xyz]

Quindi da quello che hai scritto, la scheda funziona col kernel 3.2.0 ma non col 3.2.29 e 3.2.45. Se è così è tutto molto strano.

[simo85]

Si, sul laptop del mio amico funziona..
Appena ho la possibilità farò le dovute prove a suo fianco..

Nemmeno con l'utility stlink sembra voler funzionare. Tra l'altro mi sembra che il chip ID letto sia 0x4220 o qualcosa di simile. Ora non sono al mio computer e non posso copiare l'output.



Appena ho 5 minuti compilo il summon-arm-toolchain e proverò la comunicazione con arm-none-eabi-gdb.

Ho compilato con successo le binutils per l'architettura AVR, avr-gcc, avr-gdb, le avr-libc e avrdude... Tutto funziona, liscio come l'olio, come del resto avevo già fatto mesi fa.

MPLABX ed il PICkit3 anche, nessun problema, funziona tutto alla perfezione.

L' ST Link/V2 no. E sembra che io sia l'unico sfigato a cui non funziona.

[xyz]

Credo che compilare il debug "gdb" sia inutile visto che si appoggia a un programma esterno con un comunicazione via TCP/IP con indirizzo localhost o a una comunicazione seriale, non ha codice specifico per un determinato hardware.

Se il chip id è 0x4220 devi capire per quale motivo non viene letto correttamente.

Comunicare con un AVR è molto più semplice rispetto a un ARM

[simo85]

Se il chip id è 0x4220 devi capire per quale motivo non viene letto correttamente.

Appena sono sul mio provo a compilare abilitando il debugging e ad eseguire il tutto com gdb. Vediamo se riesco ad ottenere qualche info utile. Parlo del software qstlink2.

Comunicare con un AVR è molto più semplice rispetto a un ARM.

Me ne sono reso conto!