Elektroda.pl
Elektroda.pl
X
CControls
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

LPC2138 [ZL6ARM] programowanie - programowanie przez jtag, ISP[UART], bootloader

nonor 22 Mar 2014 21:03 2649 11
  • #1 22 Mar 2014 21:03
    nonor
    Poziom 12  

    Witam,
    najprawdopodobniej coś źle zrozumiałem podczas poznawania ARMów i powstał u mnie mętlik, który musze w jakiś sposób wyprostować.
    Posiadam zestaw ZL6ARM, możliwość programowania przez jtag oraz UART [rozumiem, że to ISP].
    Przez długi czas wgrywałem programy przy pomocy jtag, nagle zacząłem otrzymywać komunikat Id core: 0x000000 [ARM9], oraz brak sygnału RTCK i straciłem możliwość programowania przez jtag. Uruchomiłem LPC2000 Flash Utility i mogę dalej programować (reset przy niskim stanie na P0.14), ale nadal brak możliwości przez jtag (mimo zwierania-rozwierania linii RTCK przez rezystor do masy i resetowania przy wysokim stanie na P0.14).
    Moje pytania są takie:
    1. co się w ogóle stało że straciłem jtag?!
    2. czy bootloader zajmuje się wyłącznie programowaniem przez ISP czy także obsługuje jtag.
    3. co zrobić, żeby mieć możliwość "przełączania się" pomiędzy ISP i jtag?

    Będę wdzięczny za rozjaśnienie sprawy i z góry dziękuję.

    0 11
  • CControls
  • #2 22 Mar 2014 22:37
    mickpr
    Poziom 39  

    nonor napisał:
    P0.14
    ??? LPC2138? Co z pinami P0.31 ? P1.26? P1.20?
    Stosujesz pull-upy i pull down'y na liniach JTAG?

    0
  • CControls
  • #3 22 Mar 2014 23:29
    nonor
    Poziom 12  

    Tak, czytam z obudowy kontrolera: LPC2138FBD64

    Piny:
    P0.31 - patrząc na schemat - bezpośrednio podłączona do lini RS wyświetlacza LCD na HD44780
    P1.26 RTCK (ściągnięty do masy przez 10K ustawiany zworką) - testowałem każdą kombinacja ze zworką lub bez.
    P1.20 - (TRACESYNC) - hmmm, faktycznie "wisi w powietrzu" przez cały czas ( jest możliwośc ściągnięcia do masy przez rezystor 10k).......niby tak "wisi" od nowości (kilka miesięcy), ale zaraz sprawdę podpięcie do masy

    Co do pull-up/down - jest to płtyka 'demonstracyjna' z fabrycznie zamontowanymi rezystorami (TRST, TDI, TMS, TDO -> 3,3V, oraz TCK i RTCK ('sterowany' zworką)-> masa).

    (Sprawdziłem P1.20 - po ściągnięciu do masy proc się 'zblokował' (nic nie dało))

    0
  • #4 23 Mar 2014 10:05
    mickpr
    Poziom 39  

    A co jeśli w FlashMagic-u wykonasz kasowanie całego Flash ? Czy w tym momencie możesz połączyć się przez JTAG?
    Czy na linii RST (JP18) jest stan wysoki? (zworka JP18 zdjęta)

    0
  • #5 23 Mar 2014 10:47
    nonor
    Poziom 12  

    Użyłem LPC2000 Flash Utility i za jego pomocą wykasowałem cały flash (opcja entire chip) - bez żadnej zmiany dla jtaga (czyli nadal bral RTCK, a core id = 0x0000000).

    RST działa (procek się resetuje po wciśnięciu przycisku RES a potem rusza, program wgrany przez ISP działa), a zworkę JP18 sprawdziłem na wszelki wypadek w każdym położeniu.

    0
  • Pomocny post
    #6 23 Mar 2014 11:01
    mickpr
    Poziom 39  

    Ze schematu i opisu ZL6ARM wynika, że JTAG powinien być aktywny przy ustawieniu zworki JP23 w pozycji 2-3.
    Z datasheet wynika ponadto, że:
    - P0.31 nie może być zewnętrznie ściągnięty do LOW w momencie RESET-u (musi być HIGH, lub niepodłączone).
    - RTCK (P1.26) jest dodatkowym pinem JTAG. Wg datasheet stan niski na tym pinie w momencie RESET-u pozwala na użycie linii P1.26...P1.31 jako linii interfejsu DEBUG (po wyjściu ze stanu RESET).

    Jakiego debugger'a (JTAG'a) używasz? Jakiego programu używasz do programowania przez JTAG?
    Czy bufory wejściowe (jeśli są) JTAG-a są zasilane?

    Jeszcze co do konfiguracji - JTAG może być zablokowany przez CRP.
    http://www.nxp.com/documents/user_manual/UM10120.pdf strona 248.
    Dlatego mówiłem o pełnym wykasowaniu LPC2138.
    Natomiast ISP powinno być wyłączone (P0.14=HIGH).

    0
  • #7 23 Mar 2014 11:52
    nonor
    Poziom 12  

    Zworką JP23 ściągam RTCK do masy.
    P0.31 jest fizycznie podłączone do linii RS wyświetlacza LCD (na wszelki wypadek wyjąłem LCD więc po porstu wisi w powietrzu) - faktycznie na tej linii jest cały czas zero z wyjątkiem momentu resetu (wszystkie linie w stanie wysokim), ale nic do niej nie jest podłączone, więc to sam kontroler ściąga do masy (na takiej konfiguracji wcześniej dawałem radę programować jtagiem).

    Używam J-linka i raczej jest sprawny, bo bez problemu łączy się z innym kontrolerem i programuje (STM32F100).
    Program to J-Flash ARM ( też działa z STM32F100)
    Nawet nie próbuję debuggować - JTAG wykłada się już w momencie zrobienia 'connect' (komunikat o RTCK i id = 0x00..).
    Co do zasilania buforów - na ZL6ARM nie ma ich, natomiast ewentualne znajdują się na płytce programatora i są zasilane (programator i program sprawdziłem na STM32F100.
    Odnośnie CRP:
    Nie ustawiałem żadnych zabezpieczeń, żeby nie mieć problemów jakie właśnie mam :). Jedyna rzecz jaka była zmieniana to suma kontrolna którą zawsze wymuszał J-Flash ARM przed wgraniem programu.
    Wcześnej przez ISP wyczyściłem pamięć (erase entire device) - bez efektu dla JTAG.

    (jeszcze raz wyzerowałem, a potem sprawdziłem czy cały się skasował (komunikat device is Blank). Potem jeszcze sprawdziłem czy nie ma jakiegoś zabezpieczenia CRP dla 0x00 (po wykasowaniu) - JTAG nadal 'leży'. Zaczynam myśleć o egzorcyście... :| )

    0
  • #8 25 Mar 2014 20:52
    nonor
    Poziom 12  

    Panowie, macie jeszcze jakieś pomysły co się stało, że zablokowało mi JTAG-a?
    1. wyzerowałem FlashMagic-iem procesor (przy sprawdzaniu zabezpieczeń mam "CRP disabled"?!)
    2. sprawdzone fizyczne połączenia JTAG-programator
    3. Wszystkie linie portów wyglądają na działające (podczas resetu zmieniają stan)
    4. wszystkie podciągnięcia góra/dół przy JTAG-u zamontowane.
    5. przez uart0 mogę bez problemu programować
    6. Linie mające wpływ na JTAGA-a ustawione tak jak pisał mickpr (klikam 'pomógł' bo dowiedziałem o kilku nowych rzeczach - dzięki mickpr)

    Pozostało chyba tylko fizyczne uszkodzenie, albo wgranie jakiejś 'cudownej' kombinacji do pamięci.
    Jeśli macie pomysł co dziwnego mogłem wgrać do flasha - dajcie znać, bo szkoda tak co chwilę wylutowywać procesor nie wiedząc co się stało.
    P.S. Dzieki mickpr za dotychczasową pomoc.

    0
  • #9 27 Mar 2014 09:31
    Badmaneq
    Poziom 23  

    Proponuję napisać program, którego zadaniem będzie zmaina stanu 0-1 na pinach od JTAG'a oczywiście częstotliwość odpowiednio mała. Następnie zaprogramować przez ISP, po czym sprawdzić np. multimetrem napięcia na tych pinach. Jeżeli na, któryś brak zmiany stanu należy mierzyć bezpośrednio na wyprowadzeniu mikrokontrolera.
    W ten sposób odkryłem u siebie zimny lut po około pół rocznym bezproblemowym użytkowaniu mojej płytki testowej...
    Gdy to nie pomoże to mikrokontroler do wymiany :(

    0
  • #10 01 Kwi 2014 12:54
    nonor
    Poziom 12  

    (o, widzę, że dostałem 'administratora systemowego' wraz z przyciskiem 'Moderacja'. Dziękuję - czuję się doceniony :)) )

    @Badmaneq - wyprowadzenia wyglądają na sprawne.
    Nie mam drugiego LPC2138, więc przerzuciłem się na STM32f100.
    I tu niespodzianka:
    - po około 10 bezproblemowych zaprogramowaniach stopniowo zaczęły się te same numery: za każdym następnym razem pojawiało się więcej różnych błędów z jflash-arm (za 11 razem jeden błąd, za 13 ze cztery itd), aż wgranie programu wymagało czasem nawet 20 prób.

    Zupełnie przypadkiem podmieniłem plik startup*.s na nowy i stopniowo ale wyraźnie(!) liczba błędów zaczęła się zmniejszać i po czwartym programowaniu wszystko działa bez żadnego błędu.

    Zbieg okoliczności 'autonaprawy' i podmiany startupa wykluczam, bo po prawie 500 próbach programowania (w ciągu kilku dni), ciężko mi uwierzyć, że jakakolwiek usterka naprawiła się dokładnie w momencie podmiany pliku.
    Przeskanowałem komputer dwoma programami - wirusa brak. Pracuję na Vista, ale ciężko mi podejrzewać, że system uszkodził akurat ten plik.
    Dywersja seggera czy keila, żeby użytkownicy nie korzystali przez wieczność z wersji 'testowej'?!

    0
  • #11 01 Kwi 2014 13:09
    Badmaneq
    Poziom 23  

    Z tym administratorem systemowym to wygląda na błąd forum :)
    Z powyższego faktycznie wynika, że wina leży po stronie programatora lub oprogramowania do niego.
    BTW. To, że wyprowadzenia wyglądają ok nic nie oznacza, kiedy jest zimny lut gołym okiem wydaje się być w porządku, ba nawet większość czasu działanie "systemu" jest poprawne...

    0
  • #12 01 Kwi 2014 13:43
    nonor
    Poziom 12  

    Spotykałem się z kllkoma problemami spowodowanymi lutem bezołowiowym, tak więc zimnych lutów spodziewałem się jak tylko zobaczyłem płytkę i przetopiłem wszystko jeszcze raz cyną z ołowiem - nie było ani lepiej ani gorzej.
    W rozpaczy nawet przeniosłem dalej fluorescencyjny kompas dziadka z II W.Ś. żeby promieniowanie nie zmieniło flasha (wygląda na to, że promieniuje samym beta, bo zamknięcie obudowy całkiem go 'ekranowało' ) - oczywiście brak zmian.

    Wyczerpały się pomysły, więc chyba temat zamknę małym podsumowaniem:
    - problem zniknął (stopniowo) po podmianie pliku startup w projekcie
    - przyczyna uszkodzenia pliku - nieznana. (osobiście podejrzliwie patrzę na Vistę)

    0