(12-11-2016 22:18)SP2GNB napisał(a): [ -> ] (12-11-2016 17:16)SP9FKP napisał(a): [ -> ]A mnie to wygląda na wadliwie ustawioną opcję F_LO_DIV_BY_TWO w konfiguracji. Zawsze warto spróbować sformatować kartę na czysto i zrobić ustawienia jeszcze raz.
Zakupione w Farn... układy Si nie pracują ani w EU1KY, ani w Adafruicie. Natomiast Si przeniesiony z fabrycznego Adafruita pracuje bardzo dobrze... Nie mam pojęcia, dlaczego zakupiony Si generuje jedną częstotliwość nie reagując na I2C - fabrycznie zaprogramowany?
Oczywiście jak przełączę F_LO_DIV_BY_TWO na "YES" prążki znikają, co jest zrozumiałe...
Dzięki Andrzeju za instrukcję step by step - spadła jak z nieba...
Staszek,
odnoszę się do postów #164 i #167.
Mamy prawdopodobnie podobnego pecha. Układy kupione w tym samym miejscu. Zachowanie podobne.
Firma SiLabs potrafi zaskakiwać. Tym razem jest to zaskoczenie negatywne. Trudno mieć tu pretensje do dystrybutora bo prawdopodobnie o tym wszystkim nie wiedział o czym dalej.
Partia kupionych układów (jak zwykle u mnie nieco na zapas) według oznaczeń na układzie pochodzi z produkcji 2016 rok, tydzień 32, Custom Code 04486, obudowa 10-MSOP. Można się domyślać, że to partia przygotowana do jakiegoś konkretnego większego zamówienia z zaprogramowanym wstępnie obszarem NVM (One time programmable memory). Jej zawartość przy bootowaniu jest przepisywana do RAM układu i efekty tego programowania obserwujesz po podaniu zasilania.
Po wlutowaniu układu miałem efekty jak u Ciebie. Wylutowałem i wstawiłem następny - to samo. Oczywiście oba układy nie reagowały na komendy z STMDisco, to że dwa się zachowywały tak samo nie dawało mi to spokoju. W internecie są informacje o zmienionych adresach I2C ale ich użycie też nie dało efektu. Układ nie reagował na nic.
Pewnym nakładem pracy znalazłem przyczynę. Otóż po przeskanowaniu przestrzeni adresowej I2C mojego układu Si5351 specjalnie do tego celu przygotowanym małym programem, okazuje sie, że firma SiLabs dla pewnej partii zmieniła adres I2C na 0x62 w miejsce 0x60 pokazywanego w dokumentacji. Ponieważ adresowanie interfejsu I2C jest 7 bitowe to przesuwając adres w lewo o 1 bit by połączyć go: z bitem 0 (polecenie WRITE) lub 1 (polecenie READ) powstaje wartość C0h znana z menu analizatora antenowego. Z informacji z internetu wynika, że wcześniej już SiLabs zaskoczył klientów wprowadzając dla części układów adres I2C 0x67, stąd reakcja autora oprogramowania analizatora i wprowadzenie opcji adresu CEh.
Korzystając z bibliotek na Github przygotowałem program testowy i po jego użyciu uzyskałem kontrolę nad układem. Właśnie wygenerowałem 15.000.000, 15.100.000, 20.000.000 MHz na CLK0, CLK1 i CLK2 używając adresu 0x62.
Mam nadzieję, że ktoś to jeszcze sprawdzi czy jest to powtarzalne rozwiązanie i czy to koniec niespodzianek SiLabs.
Wydaje się że, mamy dwa wyjścia: reklamować układy lub co może być tańsze ale bardziej kłopotliwe, poprosić Piotra by w naszym imieniu poprosił autora softu o dorobienie jeszcze jednej pozycji w menu konfiguracji adresu Si5351 o wartości C4h.
Niestety nie mam uruchomionego środowiska do wprowadzenia korekty i ponownej kompilacji oprogramowania analizatora.
To menue jest obsługiwane w config.c:
" .....
{
.id = CFG_PARAM_SI5351_BUS_BASE_ADDR,
.idstring = "SI5351_BUS_BASE_ADDR",
.nvalues = 2,
.values = CFG_IARR( 0xC0, 0xCE),
.strvalues = CFG_SARR("C0h", "CEh"),
.type = CFG_PARAM_T_U8,
.dstring = "Si5351 i2c bus base address (default C0h)",
.isvalid = isSi5351,
},
....."
Pozdrawiam wszystkich,
Mirek