AT91SAMS764 - błąd?

Jun 17, 2005 4 Replies

Witam wszystkich.



Jestem po pierwszych bojach z tym procem. Wrażenie dość miłe, przynajmniej na razie, jednakże... Przy zabawie z SPI (pomijając moje, jak to na początku bywa banalne błędy) wystąpił następujący problem: SPI włączone w trybie "master", "Variable Peripheral Select" z włączonym CSAAT w SPI_CSRx. Wpisując pierwszą daną do SPI_TDR, odpowiednia linia NPCS przyjmuje stan LO i go utrzymuje. Kolene dane są wysyłane poprawnie. No i wysyłam ostatni bajt ustawiając w SPI_TDR flagę LASXFER. Po wysłaniu tego bajtu odpowiednia linia powinna zmienić stan na HI. Tak się jednak nie dzieje, pozostaje stan LO... Po różnych próbach zauważyłem, że:



-jeśli włączony jest dzielnik FDIV w SPI_MR sytuacja wygląda tak, jak opisałem;



-jeśli jednak nie używam FDIV, zakończenie komunikacji (ustawiony LASXFER) działa poprawnie.



Nie wiem, czy to ja, czy on popełnia błąd. W "dejtaszicie" nic nie wyczytałem na ten temat (no chyba, że coś mi na oczy poszło).



Spotkał się ktoś z tym problemem? A może są jeszcze jakieś inne kruczki, o których wypadałoby wiedzieć?



Pozdrawiam M


Witam,

W układzie tym mogą być różne dziwne kwiatki. Jeśli nie jest to opisane w erracie - zapytaj producenta. Ja np. znalazłem brak w dokumentacji - SSC potrafi taktować transmisję tylko podczas wysyłania ważnych danych pod warunkiem że wybierzemy tryb 2 który nie jest opisany w dokumentacji. Kolejna rzecz to timery - zdarzenie "Compare A" nie zgłasza u mnie przerwania, natomiast B i C działają bez problemu.

Paweł

Użytkownik "Meleks" snipped-for-privacy@poczta.neostrada.pl> napisał w wiadomości news:opssh70706r58qyv@rafal...

No, to nie wiem teraz, czy wybór tego układu jako poligon doświadczalny był dobrym pomysłem. Jednak z drugiej strony, jak wszystko od początku idzie jak po maśle, to wiadomo, że kiedyś pieprznie, nie wiadomo jednak kiedy, ale wiadomo na pewno, że w jak najmniej odpowiednim momencie :-) Jak na razie na nim (AT91...) bedę uprawiał swoje eksperymenty. A tak przy okazji, nie ma jakiejś "upublicznionej" listy bugów tego procka? Zapewne przydałaby sie wielu ludziom. Zaoszczędziłaby duuużo czasu na szukanie błędów w programie, których nie ma :-)

No i jeszcze to: Jak szybko producent reaguje (poprawia błędy) na sugestie użytkowników? Nigdy nie miałem z tym do czynienia :-) Do tej pory "trafiały mi się" sprawdzone układy :-)

Pozdrawiam M

Proponuję poczytać dokument-erratę ze strony Atmela.

Paweł

Producent reaguje zwykle wypuszczając (z dużym opóźnieniem) stosowne erraty. Natomiast na poprawianie błędów się nie nastawiaj - procesory AT91SAM7Sxx mają dużo błędów identycznych z większym bratem AT91RM9200, które wciągnęli z dobrodziejstwem inwentarza tworząc serię 'SAM' (porównaj erraty). Niewykluczone, że w SAM'ach potwierdzą się też inne błędy już obczajone w '9200 - warto poczytać erratę tamtego procesora i najlepiej też kilku podobnych wynalazków Atmela.

Absolutnym rekordzistą w niepoprawianiu błędów sprzętu jest wg mnie Texas Instruments. Znane problemy w procesorach DSP propagują się już przez kilka kolejnych scalaków (przeszły z poprzedniej serii), a erraty tylko rosną. Wiele błędów nie ma obejścia (workaround: none) więc od sprytu kompilatora C (lub programisty w asemblerze) często zależy, czy kod wynikowy będzie miał szansę działać.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required