Postanowiłem ostatnio w końcu zapoznać się z najpopularniejszą od
jakiegoś czasu rodziną mikrokontrolerów. Kupiłem kilka płytek Discovery
i Nucleo. Eksperymenty postanowiłem zacząć od prostej płytki w formacie
Arduino Nano, z uwagi na łatwość wpięcia tego w płytkę prototypową.

Wziąłem kod, który akurat miałem na warsztacie (biblioteka DCF77
przeportowana na PIC32). Bez większego problemu udało mi się go
skompilować i uruchomić na nowej platformie. Wyglądało na to, że
wszystko działa - program prawidłowo odczytywał w przerwaniu impulsy z
wyjścia modułu DCF77, interpretował je i synchronizował wewnętrzny RTC,
wysyłając na bieżąco informacje przez UART podpięty do funkcji printf().

Niestety dość szybko zauważyłem pewien problem, którego jak na razie nie
byłem w stanie zdiagnozować. Podejrzewam, że może to być związane z
jakimiś różnicami hardware'owymi.
Mianowicie w przypadku PIC32 kod działa stabilnie, nie ważne jak długo
zostawiłem go podłączonego. Gdy tylko pojawiały się warunki
propagacyjne, urządzenie odczytywało prawidłowe ramki i synchronizowało
czas.

Natomiast jeśli zostawię Nucleo włączone na dłużej, po jakimś czasie
widzę, że synchronizacje ustały (a przynajmniej nie widać nowych
komunikatów na porcie szeregowym, przy czym funkcja migania diodą w
pętli głównej ciągle działa). Program do obsługi portu szeregowego nie
melduje zerwania połączenia. Po prostu panuje cisza.
Na PIC32 miałem standardowy układ FTDI, w dodatku z galwaniczną
izolacją, tak więc odpinanie i podpinanie USB nie miało żadnego wpływu
na działanie układu, a zasilanie pochodziło z zupełnie innego źródła.

Tutaj jest inaczej. Jeden port USB pełni zarówno funkcję
programatora/debuggera, przejściówki USB-UART, jak również źródła
zasilania. Dodatkowo zauważyłem, że zastosowano tam jakiś dziwny model
włączania zasilania. Płytka wymaga najwyraźniej podłączenia do hosta,
żeby w ogóle napięcie zostało podane do mikrokontrolera - nie da się jej
zasilić z ładowarki albo power banku. W grę wchodzi tylko komputer.

Ktoś wie może o co chodzi? Jest tam więcej takich "pułapek"? Czy
zaobserwowane przeze mnie objawy można wyjaśnić jakimś "usypianiem"
przejściówki USB-UART wbudowanej w ten układ?

do góry

On Fri, 7 Sep 2018 08:39:44 +0200, Atlantis <m...@w...pl>
wrote:
> Po prostu panuje cisza.

Czy mimo braku odbioru przez uart na pinie RX mcu jest aktywność z
układu wysyłającego?

--
Marek

do góry

Atlantis <m...@w...pl> napisał(a):
[CIACH]
> Ktoś wie może o co chodzi? Jest tam więcej takich "pułapek"? Czy
> zaobserwowane przeze mnie objawy można wyjaśnić jakimś "usypianiem"
> przejściówki USB-UART wbudowanej w ten układ?

Podstawowe pytanie, to czy nadal jest transmisja na UARTcie? Trzeba
zweryfikować działanie mikrokontrolera przed szukaniem problemu w
przejściówce, którą jest tak naprawdę programtor ST-LINK. Sprawdź
oscyloskopem lub inną przejściówką czy mikrokontroler na pewno nadaje. Jeśli
nadaje, to wtedy szukamy problemu z ST-LINKiem. Może trzeba mu zaktualizować
firmware albo sterownik?

--
Grzegorz Niemirowski
https://www.grzegorz.net/

do góry

On 9/7/2018 8:39 AM, Atlantis wrote:
> Natomiast jeśli zostawię Nucleo włączone na dłużej, po jakimś czasie
> widzę, że synchronizacje ustały (a przynajmniej nie widać nowych
> komunikatów na porcie szeregowym, przy czym funkcja migania diodą w
> pętli głównej ciągle działa). Program do obsługi portu szeregowego nie
> melduje zerwania połączenia. Po prostu panuje cisza.

Migaj ledem przy wysyłaniu znaków. Dowiesz się czy to wina cpu czy
usb<->uart.

do góry

Dziwna sprawa - okazuje się, że problem nie występuje po zastosowaniu
zewnętrznego konwertera UART-USB (FTDI z izolacją galwaniczną), co
oczywiście wiąże się z przemapowaniem UART-a na inne piny.
Wtedy wszystko zaczyna działać. To znaczy prawie wszystko - bo mam
jakiegoś dziwnego buga związanego z wyświetlaniem czasu na LCD, ale to
pewnie kwestia jakiejś drobnej pomyłki w kodzie.

do góry