[Andrzejj23]

W tej chwili mam najbardziej ograniczone zasoby czasowe - nie zakładałem, że takie 'kwiatki' mogą się pojawić
Generalnie używam produktów Microchip  (PIC) i mam narzędzia. Chciałem 'pobawić' się nieco więcej z Arduino i zmontowałem jakiś układ na bazie Adafruit M0 Adalogger (bo taką akurat miałem). Tam jest SAMD21G18. Postanowiłem jednak całość zrobić na samodzielnej płytce ze względu na wymagany kształt. Kupiłem więc mniejszy procesor (łatwiejszy w montażu) o tej architekturze: SAMD21E17, (zasoby wystarczą do uruchomienia tego samego kodu) zrobiłem płytkę i chciałem wszystko wgrać ... a tu takie przygody. Wydawało mi się, że o ile Arduino może wygenerować samodzielny kod (plik HEX) to spokojnie użyję mojego PICkit4. Okazało się, że wygenerowany HEX zaczyna się od 2000H, zatem samodzielnie nie będzie w stanie obsługiwać np. przerwań. Pomyślałem OK, wgram bootloader z Arduino IDE i dolutuję złącze do USB, żeby potem wgrać sam kod programu... i dlatego dokupiłem programator, który Arduino IDE obsłuży. Niestety tak jak napisałem - to też bez sukcesu.... Z tego co się zorientowałem - coś jest źle w plikach konfiguracyjnych ustawiających obsługę ATMEL ICE z OpenOCD, ale w którym konkretnie pliku to poprawić (dopisać transport select swd) nie wiem. 
W tej chwili trochę na ślepo, w celach edukacyjnych, programowałem bootloadery z użyciem PICkit4 (jak znalazłem HEXy do tej rodziny procków) i uzyskałem efekt taki, że któryś się wgrał i miga mi dioda, ale zostały poustawiane bity blokujące nadpisanie bootloadera i teraz już nic nie mogę wgrać bo wyskakuje błąd przy weryfikacji pierwszej komórki...
Instaluję Atmel Studio (Microchip Studio), bo znalazłem instrukcję jak przy jego użyciu wgrać poprawny bootloader
A i tak najlepsze byłoby wyjście, gdyby Arduino IDE rzeczywiście był w stanie wygenerować kod, który mógłby pracować zupełnie samodzielnie... (intuicyjnie wydaje mi się, że to musi dać się jakoś ustawić)

[kaczakat]

Nie wiem czy to zadziała, jak pisali w podanym wcześniej linku trzeba zdobyć bootloader do takiego mniejszego uC, ale potem kompilować też trzeba pod konkretny uC.
Robiłem coś takiego z Atmegami, można wyedytować plik tekstowy z definicjami płytek, tam jest opisane wszystko jaki programator, bootloader (opcjonalnie), gdzie jest jego plik i jak się nazywa, sygnatura, jaki protokół i program do wgrywania, masę innych parametrów, ale w parę chwil do ogarnięcia, w sumie to kilkanaście linii.
Bez problemu można było skompilować program i go wgrać do np. Atmega88, ale czy dany core zawiera definicje innych uC to już sprawdzisz jak przez to przebrniesz. Na pewno AVR nie ogarniał wszystkich MEGA, pojawiły się atmegi PB i trzeba było poczekać aż Arduino zaktualizuje się na tyle by ogarnąć te uC i wtedy zadziałało.
O ile dobrze pamiętam to zarówno ten programiki od Microchipa jak i od STM32 ściągały dane danego uC dopiero jak zachodziła konieczność jego użycia w IDE, jest ich już teraz po prostu za dużo, Atmegi w Arduino były właściwie wszystkie, tak samo w Atmel Studio jak się wybrało AVR 8 to instalował wszystko do nich i już nic potem nie ściągał.

[kaczakat]

Znalazłem core, który obsługuje SAMD21E17A, kompiluje się OK, mam już ten uC, ale nie mam na razie czasu polutować by przetestować, jak masz jakiś schemat jak zrobić minimum do uruchomienia to podrzuć.
https://www.cba.mit.edu/quentinbolsee/Ar...M-tutorial
W katalogach core jest bootloader, obsługuje Atmel-ICE.

[Andrzejj23]

Ja też   Znalazłem coś takiego: https://github.com/mattairtech/ArduinoCo...ts/MT_D21E
Dodatkową zaletą jest to, że można w konfiguracji wybrać opcję 'bez_bootloadera'. 
Jestem na niedoczasie, więc nie wszystko jeszcze sprawdziłem (jeśli chodzi o ATMEL-ICE) - póki co programuję z użyciem PICkit4 i wygenerowanego HEXa. 
Później sprawdzę to dokładnie, ale w tej chwili wszystko wskazuje na to, że uszkodziłem wejście RESET przez błędne podłączenie sygnałów z programatora ICE. Programowanie tej sztuki odbywało się pomyślnie (przy użycku PCIkit4), ponieważ odczyt/weryfikacja potwierdzały wgraną zawartość, ale procesor nie startował. Zauważyłem, że pomimo rezystora podciągającego, na linii RESET jest stan niski. Wymieniłem procek i ten sam wgrywany wcześniej program ruszył.... Dla mnie to duże zaskoczenie, bo procki Microchipa (które znam lepiej) nigdy nie uległy uszkodzeniu w przypadku błędnych połączeń... (a te przy budowaniu prototypów czasem się zdarzają).
W każdym razie w tej chwili zrobiłem kolejny krok i mogę działać dalej. Bardzo dziękuję za pomoc na tym etapie (zobaczymy, czy to mi wystarczy, czy w kolejnych krokach znowu na czymś się nie zatnę  ). Mam nadzieję, że ten wątek i powyższy link będzie jeszcze dla kogoś przydatny.

[kaczakat]

Z trzech core, które już mam programator działa z Atmel ICE tylko z tym od Arduino, te do SEEEDuino czy ten z mojego linku kompilują, wgrywają, ale na koniec jest jakiś błąd debuggera i program nie działa, wystarczy wrócić do ARduino SAMD, wgrać bootloader i płytka rusza z programem wgranym w tym innym core. Potem można wgrać program z core Seeeduino ZERO, ale znowu znika port COM tak jakby był znowu sam bootloader i sterownik CDC nie pomaga, program działa. Potem wystarczy programatorem wgrać bootloader od ZERO, wgrać program programatorem, jeszcze raz się przywiesi przy wgrywaniu, ale pojawi się port COM bootloadera, przy kolejnej próbie już wgra, potem pojawia się port com Arduino ZERO z wysyłanymi danymi z uC. Jak się znowu wgra tym bootloaderem z Seeduino, to na czas wgrania pojawia się port COM bootloadera, po resecie Seeduino ZERO bez drivera, powtórzyć...
Core od MattairTech (czwarty) działa najlepiej, przez chwilę pojawiły się tu nawet dwa urządzenia, jedno Arduino ZERO port COM, a drugie Arduino Zero bez drivera, teksty drukowane na serialUSB się nie pojawiały przy tym, ale ustawienie portu USB "With CDC" rozwiązało problem. Widzę tu też sterowniki CDC, może zadziałają lepiej. Wgrywanie bootloadera też tu jakoś lepiej działa.
Na drugim komputerze z core MattairTech i win7x64 wyskakują błędy weryfikacji przy wgrywaniu, ale program działa.
Doszedłem że nie pasuje mu USB 3.0. na USB 2 działa OK.
No i RAM, Army mają więcej flash i RAM, ale jak dobrze rozumiem by odpalić USB i na podstawową konfigurację procka znika prawie po 10kB, w AVR z USB znika tyle RAMU ile poszło na bufory UART, można się zdziwić zamieniając AVR na jakiegoś ARM z 4x większą pamięcią RAM, albo zakładając, że 16kB to spoko starczy, bo potrzebujemy tylko 8.
Wszystko to jest trochę dziwne, ale nauczyłem się paru nowych rzeczy.

[Andrzejj23]

Czy możesz podesłać jakiś schemat samego podłączenia Atmel-ICE do procka? Ja cały czas działam z PICkit4 ale dochodzę do wniosku, że prawdopodobnie dwa układy jakoś 'zablokowałem' i nie chcą pracować. Być może pomoże 'full chip erase' ale tego PICkit4 nie potrafi (lub nie umiem tego zrobić). W Microchip Studio (Atmel Studio) jest to proste ale właśnie cały czas nie doszedłem dlaczego mój Atmel-ICE nie działa, więc może trzeba zacząć od podstaw i sprawdzić połączenia.....

[kaczakat]

Zainstalowałem Atmel Studio 7 i tam po prostu wykryłem procek by sprawdzić czy dobrze podłączyłem, a na płytce adaptera (jakaś z ali) mam wypisane numery pinów, są też w PDF do Atmel ICE. Zresztą na płytce jest oznaczony pin nr 1 na brzegu złącza  i płytki, na gnieździe jest niżej. Natomiast piny są po jednej stronie o numerach nieparzystych, więc 2 jest w drugim rzędzie.
Atmel ICE nie zapewnia zasilania, pin 3.3V daje tylko informację do programatora jakie jest napięcie układu, może nie zablokowałeś, tylko nie zasilasz.
W płytce ZERO mam tak to podłączone, 3 piny poza zasilaniem (3.3V tylko do odczytu):
1 3V3
3 GND
4 SCK
2 SDO
10 RST
   

[Andrzejj23]

Kupiełm Atmel-ICE jako samą płytkę (nie ma w komplecie kabli) i dlatego wszystko weryfikuję. 
Sprawdziłem już chyba setny raz - mam tak jak podałeś.
Mimo to wyskakuje okno:

No device detected. Error 4109
Unable to enter programming mode. Verify device selection, interface settings, target power, security bit, and connections to the target device.



Co więcej ten sam komunikat wyskakuje, gdy podłączę PICkit4 i próbuję nim odczytać cokolwiek (ten sam PICkit4 pod MPLAB IPE rozpoznaje procka i odczytuje zawartość pamięci)
(płytka oczywiście jest pod zasilaniem)


Aktualizacja: wziąłem kolejną płytkę z nowym prockiem i ten jest rozpoznawany w Atmel Studio przez Atmel-ICE.
Czyżby jednak ten poprzedni był uszkodzony? (tylko dlaczego PICkit go rozpoznaje i odczytuje z niego kod.....)

[kaczakat]

Jak PIC KIT go rozpoznaje to przecież jest OK, kojarzę taką sytuację, że jak został włączony tryb debug to Atmel Studio nie widzi procka, może PIC KIT wprowadził uC w taki stan i go nie wyłączasz przed rozłączeniem, ale oczywiście jestem Arduinowcem i nie do końca wiem co piszę , nie za bardzo mogę to teraz zweryfikować. Coś tam TMF o tym pisał na elektrodzie i chodziło raczej o jakąś Atmegę na Cursiosity z debugiem na płytce, ale raczej nie znajdę już tego.
Jednak znalazłem: https://www.elektroda.pl/rtvforum/viewto...1#17652111 chodziło o utknięcie w trybie debug? No ale to jednak były AVR, choć może Atmel skopiował problem do innych swoich konstrukcji.

[Andrzejj23]

Dzięki - drążę ten temat....
Pytanie dodatkowe (skoro już zainstalowałeś Core od MattairTech) - gdzie powinienem szukać kodu uruchamianego przy starcie procka? Mam taki objaw, że układ startuje zawsze po włączeniu zasilania, jednak jak wcisnę reset - zatrzymuje się i po puszczeniu nie startuje ponownie (trzeba na chwilę odłączyć zasilanie). Zastanawiam się, czy nie ma jakiś 'pozostałości' po bootloaderze i być może restart z przycisku jest jakoś błędnie obsługiwany.....