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?