[komarkus]

Próba upgrade do ACCST D16 2.1.0 (z karty SD) kończy się komunikatem "Firmware update error, Data refused". Problem raczej nie jest banalny. Próbowałem różnych rzeczy - inna karta SD, kolejne ściąganie firmware, rozpakowywanie zip-a różnymi pakerami, wgranie firmware na SD poprzez USB i bezpośrednio z komputera, na uruchomionym OpenTX i na bootloaderze, wersja LBT, FCC, inne kabelki itd. Chyba wykluczyłem wszystkie możliwe zwykłe przyczyny problemu. Robiłem takie rzeczy na Horusie i wiem o co chodzi. Próbowałem również metody z programatorem STK i "frsky_update_sport_rev14.exe" - podłączałem S.Port i GND (od góry w X9E) do programatora (z pominięciem "+"). Dochodziłem do "Download" i po kliknięciu dostawałem komunikat "device timeout" i zrestartuj program.

Nabieram przekonania, że Taranis ma jakieś niespecyficzne uszkodzenie. Do momentu próby upgrade modułu XJT nie sprawiał żadnych problemów. Radio ma najnowszy OpenTX. Jest kupione w 77hobby (po gwarancji). Na module jest napis: X9DP_BK_RF_REV0.2  i 151217 (chyba data prod.).

Przychodzi mi pomysł, żeby porozpinać tasiemki i złączki, poczyścić IPA.

Może ktoś potrafi podsunąć jakiś pomysł, co można jeszcze by spróbować, zrobić, przetestować.

[MAK]

Chyba faktycznie zrobiłeś wszystko co można było sprawdzić. Spróbuję podpytać w FrSky.

Tylko się upewnię - moduł wewnętrzny jest aktywny w konfiguracji modelu OpenTX? (inaczej nie będzie zasilony po włączeniu radia)

[komarkus]

32 minuty temu, MAK napisał:

Tylko się upewnię - moduł wewnętrzny jest aktywny w konfiguracji modelu OpenTX?

Na tym nadajniku się lata, uaktualnia OTX. Problemów nie było. Moduł RF nie był wcześniej uaktualniany. Nigdy nie był wkładany żaden moduł zewnętrzny. W konfiguracji RF jest "internal" w D16.

Nie mam schematów nadajnika, raczej jest to niedostępne, ale coś mi mówi, że któryś sygnał programujący znika po drodze, nie dochodzi do procesora RF. I nie ma to wpływu na zwykłe działanie nadajnika.

[MAK]

8 minut temu, komarkus napisał:

Na tym nadajniku się lata, uaktualnia OTX. Problemów nie było. Moduł RF nie był wcześniej uaktualniany. Nigdy nie był wkładany żaden moduł zewnętrzny. W konfiguracji RF jest "internal" w D16.

Właśnie o to "internal" w D16 pytałem. Gdyby przypadkiem było na OFF, to tłumaczyło by sprawę.

[komarkus]

Hmm, ja nie lecę po pomoc, gdy nie sprawdziłem banalnych rzeczy ;)

Trochę znam AVR-y, a używana w tx rodzina STM32 to mocniejsi bracia. Myślę, że procek od RF da się zmusić do zaprogramowania, ale trzeba wiedzieć jak to działa i wtedy szukać rozwiązania problemu. A dokumentacji (serwisówki) nie ma.

[komarkus]

Sprawdziłem możliwość flashowania modułów external za pomocą Taranisa. To działa bez zająknięcia.

[MAK]

19 godzin temu, komarkus napisał:

Hmm, ja nie lecę po pomoc, gdy nie sprawdziłem banalnych rzeczy ;)

Trochę znam AVR-y, a używana w tx rodzina STM32 to mocniejsi bracia. Myślę, że procek od RF da się zmusić do zaprogramowania, ale trzeba wiedzieć jak to działa i wtedy szukać rozwiązania problemu. A dokumentacji (serwisówki) nie ma.

Wiem, że nie szukałbyś pomocy, gdybyś wszystkiego nie sprawdził. Ale czasem wszystkim nam umyka coś oczywistego, dlatego zawsze wolę zapytać.

Wysłałem zapytanie do FrSky. Może jutro dostanę odpowiedź.

Procek jak procek. Jeśli się ma narzędzia i wiedzę dot. wgrywania firmware do rodziny STM32 można to zrobić bezpośrednio.

[komarkus]

3 godziny temu, MAK napisał:

Jeśli się ma narzędzia i wiedzę dot. wgrywania firmware do rodziny STM32 można to zrobić bezpośrednio.

Można  ;)

Sprawdziłem tasiemki, są optycznie i elektrycznie w porządku. Oględziny płyty głównej pod szkłem powiększającym pokazują to:
 

W czerwonym jest miejsce, gdzie ewidentnie po automacie montażowym ingerował człowiek. Pod lupą dokładnie widać słabą ręczną robotę (nie u mnie). Rezystor R171 prawdopodobnie był wymieniany, a w miejscu R172 rezystora nie ma, ale postrzępione ślady cyny i spalona kalafonia wskazują, że mógł kiedyś być. Pod lupą widać dużo lepiej niż na zdjęciu, ale ścieżki i tak są trudne do prześledzenia. Przydałby się schemat. To miejsce jest bezpośrednio przy procku RF, na pinie 44 STM32 F103 jest boot0, na pinach 42-43 jest I2C/USART.  Ślad jest, będę drążył. Małe to wszystko. Może starczy chęci, czasu  i samozaparcia.

[MAK]

Dostałem odpowiedź z FrSky:

Cytuj

 

for the X9E forum question, I checked with our production team: both R171 and R172 are SMT added on the board. R172 is for production usage, we remove it after writing a firmware.. so you can see the rosin trace.. 

this is correct..

this is factory done

 

Nie przybliża nas to do rozwiązania, ale przynajmniej wyjaśniła się sprawa z manualną ingerencją na płycie.

 

[komarkus]

Dobre i to.

3 godziny temu, MAK napisał:

R172 is for production usage, we remove it after writing a firmware

Trochę przeanalizowałem i pomierzyłem, i powyższa odpowiedź burzy moje dotychczasowe założenia. Oprogramowanie układowe (np. OpenTX) siedzi  w STM32 F407 144pin. Moduł RF (na osobnej płytce) zajmuje się komunikacją radiową, natomiast "treść" dla modułu RF pochodzi z STM32 F103 48pin na płycie głównej, który to należy zupgradować dla  ACCST D16 v.2.1.0.  Ten procesor przyjmie nowe firmware tylko wtedy, gdy na pinie 44 (BOOT0) pojawi się stan wysoki i procesor przejdzie w stan bootloadera i przyjmie poprzez UART1 nowe firmware. I teraz, R171 10k podaje stan niski na pin 44 z GND. Natomiast w fabryce wlutowują niskoomowy R172, który z R171 tworzy teraz dzielnik napięcia (blisko plusa), aby BOOT0 przeszedł czasowo w stan wysoki i dał możliwość  wgrania firmware. Potem R172 wywalają i procek pracuje normalnie. To teraz jak ma się wgrać nowe firmware z karty SD, jeśli procesor ma to w poważaniu za przyczyną stałego BOOT0=0 V.  Wcześniej myślałem, że BOOT0 jest ustawiany wg potrzeb z "dużego" procesora, ale tam są tylko R171, R172, GND i +3V3 (a może czegoś nie widzę). Przestało mi się zgadzać. Może warto spróbować i wlutować R172 (lub zworkę) i wtedy spróbować aktualizacji? Trochę się obawiam, że jestem w mylnym błędzie i mogę załatwić sprzęt na dobre.

Mój X9E raczej nie jest wyjątkowy, u innych to raczej działa. Gdzieś robię błąd logiczny, coś pomieszałem? Wiem, że problem tylko polizałem, potrzebna jest spora wiedza mikroprocesorowa. Może ktoś ogarnia takie rzeczy? Może ktoś posiada dokumentację, jakieś schematy tego nadajnika?

 

 

[MAK]

Tryb bootloader procesora STM32 jest używany tylko do pierwszego wgrania firmware. Tak wgrany firmware FrSky zawiera swój bootloader, który odbiera i uaktualnia część "roboczą" firmware przez Smart Port.

Chyba pisałeś o tym wyżej, ale czy na 100% działa uaktualnianie zewnętrznych urządzeń Smart Port (np. odbiorników) przez radio / OpenTX? Jeśli tak, to chyba jedyne sensowne wytłumaczenie jest takie, że sygnał Smart Port nie dochodzi lub nie jest poprawnie obsługiwany przez bootloader FrSky modułu XJT.

[komarkus]

Jest prawdopodobne, że bootloader FrSky omija zwykłe procedury flashowania i robi to po swojemu. Ale jak? Co sprawdzić, co pomierzyć, jak to idzie? 

Potwierdzam, że wgrałem z sukcesem 100% firmware do odbiornika S6R (stare, bo nowego nie ma) za pomocą S.Port z nadajnika. To działa. Pójdę śladem S.Port, sprawdzę co się da bez dezintergracji sprzętu. Każda podpowiedź jest cenna. Jeszcze walczę.

[komarkus]

3 godziny temu, MAK napisał:

Jeśli tak, to chyba jedyne sensowne wytłumaczenie jest takie, że sygnał Smart Port nie dochodzi lub nie jest poprawnie obsługiwany przez bootloader FrSky modułu XJT

Gdyby S.Port nie dochodził do procesora, to raczej uaktualnienie odbiornika nie mogłoby się powieść. Tu jeszcze pytanie, do którego procesora. Na moją logikę, kartę SD czy S.Port obsługuje "duży" procesor i jest on pośrednikiem dla "małego" od RF. "Duży" widzi się z S.Port, programuje external, ale w odwrotną stronę nie podaje prawidłowo do "małego".

Bez schematu, choćby blokowego, takie szukanie i gdybanie, to działanie po omacku. Zostaje zrobić kolejne oględziny z lupą i miernikiem, a potem dać sobie spokój.

[MAK]

10 godzin temu, komarkus napisał:

Gdyby S.Port nie dochodził do procesora, to raczej uaktualnienie odbiornika nie mogłoby się powieść. Tu jeszcze pytanie, do którego procesora. Na moją logikę, kartę SD czy S.Port obsługuje "duży" procesor i jest on pośrednikiem dla "małego" od RF. "Duży" widzi się z S.Port, programuje external, ale w odwrotną stronę nie podaje prawidłowo do "małego".

Cały czas chodzi mi raczej o procesor modułu XJT, nie główny procesor radia.

Sygnał Smart Port jako taki dochodzi. Inaczej nie działałaby telemetria. Co najwidoczniej z jakiegoś powodu nie działa, to bootloader FrSky. Tutaj widzę takie opcje: bootloader nie dostaje poprawnego sygnału go aktywującego (mniej prawdopodobne); bootloader uległ uszkodzeniu i nie reaguje na sygnał;  bootloader działa, ale nie jest w stanie poprawnie zapisywać pamięci flash procesora. 

Jeszcze takie pytanie: jak robisz uaktualnienie za pomocą STK i aplikacji pod Windows, to aplikacja wykrywa wersję hardware? (przed naciśnięciem Download)

Apropos aplikacji pod Windows. Nowość z dzisiaj:

   

Do ściągnięcia np. stąd: https://www.frsky-rc.com/stk/

[komarkus]

Moje aktualne przypuszczenia są podobne. Istotny jest obieg sygnałów, co skąd przychodzi, np. S.Port. Bez demontażu płyty głównej taka analiza jest raczej niemożliwa, płyta jest dwustronna i gęsta. S.Port np. z pinu modułu zewnętrznego idzie taśmą na płytę główna, wchodzi pod płytkę RF i do widzenia, bez wylutowania RF nie wiadomo co dalej. Szukam po necie jakichś podpowiedzi, narazie nic pomocnego.

Co do STK, po włączeniu nadajnika i kasacji warningu o failsafe, pojawia się info o wersji hardware i firmware, cyferki z niczym mi się nie kojarzą. Podam je później, jeśli to może być istotne. Po Download dostaję: device time out i zrestartuj program. Po południu sprawdzę, co zrobi nowa wersja tego flashera.

[komarkus]

Nowy " frsky_update_sport_rev20.exe" zachowuje się identycznie z poprzednią wersją. Po "findig device" i włączeniu nadajnika, a przed Download, pojawia się: "Firm V12.34, hardware V56.78, click download". Identyczne cyferki pojawiają się po podłączeniu odbiorników, więc te wersja firmware i hardware dotyczą raczej samego STK.

[komarkus]

Zapytałem "świata" na RC Groups co o tym problemie sądzi. Raczej znany w kręgach Kilrah napisał:

"A few years ago some X9Es came with modules that can't be reflashed. Seems it might be your case, contact your dealer or FrSky."

Z kolei FJH :

"If flashing cannot be done then this means that you most probably have got a flash protected EU transmitter. You cannot do anything except you go to your FrSky dealer and complain about the flashing protected mainboard which does not allow you to make the necessary and advised RF firmware update. You may request your dealer to replace the mainboard on goodwill basis (or on guarantee basis if still guarantee is valid)."

Zakładam, że wiedzą o czym piszą. Nadajnik złożyłem. Sporo czasu mnie to kosztowało.

Na koniec poproszę Adminów, aby podrzucili problem do FrSky. Chodzi o potwierdzenie wystąpienia takiej możliwości i być może jakiegoś rozwiązania.  Gwarancja już nie działa po 2,5 roku, ale rękojmia tak. Nowa motherboard do X9E kosztuje na tanim horusrc 60 $, nie dużo, ale ...

 

 

[MAK]

Na samym początku firmware EU (jeszcze nie LBT) faktycznie kojarzę dyskusję na forach o potencjalnej możliwości zablokowania upgrade. Ale to było przez krótki czas na początku 2015. Jednak nic nie wiem o tym, żebyśmy takie nadajniki dostali, Nigdy, nawet jednego razu, nie mieliśmy problemu braku możliwości upgrade modułu nadawczego - wbudowanego, czy zewnętrznego. Z tego co napisałeś Kilrach też odwoływał się do kilku lat wstecz, co ewentualnie by się zgadzało ("few" to raczej nie dwa lata). Obaj Kilrah i FJH zwykle wiedzą co mówią, choć wolę to potwierdzić bezpośrednio z FrSky i oczywiście to zrobię.

Jeśli faktycznie jest to opisany przez Kilrah i FJH przypadek, postaram się pomóc niezależnie od gwarancji i rękojmi.

Uwaga na boku, rękojmia - tak samo jak nasza gwarancja - trwa dwa lata. Przy czym w drugim roku w ograniczonym zakresie.

[komarkus]

Nie ma dramatu. Nadajnik ogólnie działa. Być może FrSky ma lub znajdzie jakieś proste rozwiązanie na przywrócenie możliwości flashowania. Może wystarczy  wlutować R172 i wtedy uaktualniać? Mogę poeksperymentować, ale raczej pod dyktando, łatwo jest coś zepsuć nie mając wystarczającej wiedzy. Przeprogramowanie procka też może być możliwe (posiadam pełny konwerter USB - RS232 3,3V, USBasp, BLHeli32 USB Linker).

Płyta główna ma czarny napis "5NMBIL", a moduł RF "X9DP_BK_RF_REV0.2"  i "151217".

 

[komarkus]

Mam zapytanie w sprawie mojego problemu. Próbowaliście coś u FrSky, czy mam sobie radzić?

PS. Próbowałem za pomocą Horusa X12S i w/w Taranisa X9E zrobić "trenera" poprzez BT. Nie mam pewności, czy BT jest już wystarczająco oprogramowany w OTX, ale X9E robi problemy na starcie. Uaktywnienie BT nie powoduje niczego, nie pojawia się adres modułu własnego (jest 000000), smartfon jak i laptop nie wykrywa istnienia tego urządzenia. Horus podaje swój adres, BT jest wykrywalny na innych urządzeniach. Być może w X9E, BT i niemożność flashowania RF mają wspólną przyczynę, np. niedrożność RS232.