[STM32F103][HAL_CUBE_IDE] MAX7300 I2C

Witam,
Mam STM32 NUCLEO-F103RB i nie mogę wysterować wyjść ekspandera MAX7300. Wysyłam do niego:

Czy ktoś może wie co robię źle ?

Z tego fragmentu programu dużo wniosków nie wyciągniemy, ale...
Przesłanie kodu 0x55 do układu pod adres 0x0B powoduje ustawienie pinów od 12 do 15 jako wejścia bez pullup'a. Strona 7 DS'a.
Przesłanie kodu 0x55 do układu pod adres 0x09 powoduje ustawienie pinów od 4 do 7 jako wejścia bez pullup'a. Strona 7 DS'a.
Przesłanie kodu 0x55 do układu pod adres 0x0A powoduje ustawienie pinów od 8 do 11 jako wejścia bez pullup'a. Strona 7 DS'a.
Pozostałe zapisy też wydają mi się błędne. MAX7300

Możesz też pokazać konfigurację portów i modułu I2C. Funkcje HAL zwracają zazwyczaj jakieś wartości, które mogą być przydatne. I chyba najważniejsze pytanie - co pokazuje debuger?

no właśnie mi się wydawało okej z powodu tego, że znajduje się taki fragment w DS.


Wydawało mi się, że 0101 0101 to jest liczba 0x55, a chyba właśnie takiej trzeba do skonfigurowania pinów jako outputy.

konfiguracja portów:

To co pokazuje debuger:

Nie napisałeś z którego dokładnie wariantu MAX7300 korzystasz.
Pokazałeś konfigurację UART, a nie I2C. To są różne interfejsy i nie są zamienne.
Pokazałeś infomrację o udanym zaprogramowaniu układu. To nic nam nie daje. Pytając o to co pokazuje debugger miałem na myśli zawartość rejestrów GPIO, I2C czy wartości zwracane przez funkcję wysyłającą dane. Czy MAX odpowiada na wysłany adres układu? Czy MAX odpowiada na wysłany adres rejestru? Czy MAX odpowiada na wysłaną wartość do zapisu w rejestrze?
Czy masz analizator lub oscyloskop, aby sprawdzić komunikację na liniach I2C? To znacznie przyspieszy znalezienie błędu.

sorry za pomyłkę:

To jest MAX7300AAX

Zrobiłem:

i podejrzałem zmienną "cos" w STM Studio, wynosi ona 1 (czyli nie dobrze z tego co wyczytałem)

Dodano po 4 [minuty]:

z funkcji "HAL_I2C_IsDeviceReady" też zwraca 1

Dodano po 9 [minuty]:

Użyłem oscyloskopu i jakieś dane wysyła, SCL też jest.

Dodano po 10 [minuty]:

debuger oczywiście pokazuje HAL_ERROR dla tych "1" z STM Studio

Dodano po 26 [minuty]:

Podłączyłem MAXa do Arduino z jakąś biblioteką znalezioną w necie i działa

Czyli układ nie odpowiada na przesłany adres. Czy obie linie adresowe są przypięte do masy?
Jeżeli tak, to może zamieniłeś SCL z SDA? Co pokazuje analizator? Czy zegar SCL na pewno ma częstotliwość do 400 kHz?

Po pierwsze sorry za zwłokę. Po drugie na pewno linii nie pomyliłem. linie adresowe na pewno są przypięte do masy ponieważ na Arduino działa. Adres też nie powinien się zmienić. zegar ma 100k (standard).

Zauważyłem, że jak zmienię linię z PB9 na PB7 (SDA), a z PB8 na PB6 (SCL) (to się chyba mapowanie nazywa) to zmienia mi się z HAL_ERROR na HAL_BUSY (wartość zwrócona z HAL_I2C_IsDeviceReady).

Przyjrzałem się sprawie i nie ważne na jakiej linii podepnę to i tak muszę nacisnąć przycisk RESET (gdzieś tak wyczytałem) kilka razy i dopiero wtedy pokazuje mi się sygnał na obu liniach (zbadałem przy użyciu oscyloskopu), ale wtedy w funkcja zwraca HAL_ERROR. Na początku funkcja zwraca HAL_BUSY i nic nie wysyła (oscyloskop), ale jak nacisnę kilka razy RESET to dopiero zaczyna wysyłać.

Dodano po 11 [minuty]:


Czy sygnał SCL powinien tak wyglądać ? (ten dolny)

Dodano po 31 [minuty]:

Ten sygnał powinien być ok, a co w dodatku widać bit ACK też jest. To funkcja IsDeviceReady nie powinna zwrócić HAL_OK ?

Dodano po 58 [minuty]:

Nałożyło się kilka błędów.
1. Nie wiedziałem, że trzeba restartować poprzez wciśnięcie guzika STMme
2. Jak tworzyłem HAL_StatusTypeDef to na początku nic mu nie przypisywałem i zaczął mi dawać HAL_OK (chociaż nie było ok ). Później przypisywałem "1" co daje HAL_ERROR. Program nie przechodził przez funkcję która mogła by nadpisać zmienną przez co ja odczytywałem błędne informację.
3. Najważniejszy błąd (strasznie mi wstyd, bo się zapierałem ). Pomyliłem adres ;( myślałem, że funkcja HAL sama robi przesunięcie bitowe a tak nie było.

Dałem adres 0x80 i działa. Działało ;P Bo teraz mam problem z tym, że nawet jak wciskam po naście razy RESET to i tak SCL i SDA nie zaczyna nadawać.

Korzystając z debugera nie trzeba nic restartować, a już na pewno nie trzeba resetować układu kilka razy pod rząd. To jest jakiś poważny błąd w programie, który wskazuje na pewną przypadkowość - program działa przez przypadek.
Korzystając z HAL trzeba się uczyć wszystkiego dwa razy. Najpierw dokumentacji układu, później dokumentacji HAL. Dużo się nauczyłeś w ostatnim czasie. Teraz już wiesz, że struktury należy deklarować, ale też inicjować, nie należy ręcznie modyfikować zwracanych wartości statusowych, trzeba sprawdzić co tak naprawdę jest wpisywane do rejestrów. Nie ma się czego wstydzić, to się nazywa zbieraniem doświadzeń.
Oszczędnie dawkujesz nam infomracje, więc też reakcja jest niewielka. Jeżeli następnym razem umieścisz schemat, program, listę lub opis podjętych działań, to będzie lepszy materiał do analizy i być może trafniejsze podpowiedzi. W tej chwili tylko Ty, z pomocą debugera możesz ustalić dlaczego komunikacja nie działa i dlaczego wielokrotny reset pozwala czasami uzyskać pozory działającego programu.

Dziękuję za pomoc