Watchdog + USBaspLoader bootloader

[dlaszlo]

Sziasztok!

Ezt a bootloader-t http://www.obdev.at/products/vusb/usbasploader.html próbáltam ki metaboard-al https://metalab.at/wiki/Metaboard, minden tökéletes, kivéve egy dolgot: a programomban be akartam kapcsolni a watchdog-ot, de sajnos ez a bootloader szétfagy ha watchdog reset van. (Vagyis szerintem a bootloader a hibás, de nem kezdtem el nézegetni, hogyan működik.) Találkozott már valaki ilyesmi problémával? Akkor is szétfagy, ha a jumpert leveszem, amit a bootloader figyel, hogy programfeltöltés üzemmódra van-e szükség. A 2012.12.08-i bootloader-t használom, a watchdog timeout időt 8s-re vettem.

Így kapcsoltam be a watchdog-ot:

Kód: Egész kijelölése

#include <avr/wdt.h> 

wdt_enable(WDTO_8S);
wdt_reset(); // egyszer meghívtam a reset-et
// itt várakozott a progi, hogy reseteljen a watchdog...
// itt várakozott a progi, hogy reseteljen a watchdog...

Ide kapcsolódó (kezdő) kérdés, azt nagyon jó dolognak tartom, ha pl sleep módba lehet kapcsolni a mikrokontrollert, és a watchdog-gal felébreszteni, de egy jól megírt alkalmazásnál van arra szükség, hogy a watchdog reseteljen (nem interrupt módban, hanem kifagyás miatt)? Lehet ennek valami elektronikai oka, hogy a mikrokontroller kifagy, mikor kellhet ez? Miért számítanék rá, hogy kifagy a programom?

Köszönöm

[Robert]

Biztos kifagy? nem újraindulgat? Esetleg a bootloadert az elején / futás alatt nem nullázgatod állandóan?
Igaz nem a fusebiteknél kapcsoltad be a WD-t?


Az Arduino bootloadere kiolvassa a MCURST biteket és ha WD reset volt -> fagyaszt! Ne tegyél kárt a kontrollerben...

[Robert]

Sleepből ne WD-vel ébreszd.
Timer nem jó?


Melyik chip?

[dlaszlo]

Atmega328p az IC. Valami hasonlót csinál, mint az újraindulgatás, mert ha megnyomom a reset gombot, akkor a windows lejátsza az "USB-s hardware-t ismert fel" hangot (ez az USBasp, ami a bootloader-ben van), majd pár másodpercre rá azt a hangot, amikor ismeretlen eszközt talál. A fuse biteknél nem kapcsoltam be a WD-t. Azért raktam 8s-re a timeout-ot, hogy ne legyen gond azzal, hogy nem indul el a bootloader a következő reset-ig, és újabb reset jön emiatt.

Leszedem a legújabb bootloader-t, és kipróbálom (ha sikerül lefordítani).

[Robert]

A chip újraindulása a USB eldobást jelent!
Kell a watchdog?
Az USB feléledése _után_ indítsd el, és hosszú USB Timeoutot állíts be az inf állományban!

ATMega32U4 nem jó? Abban HW USB lenne....

[dlaszlo]

A chip újraindulása a USB eldobást jelent!
Kell a watchdog?
Az USB feléledése _után_ indítsd el, és hosszú USB Timeoutot állíts be az inf állományban!

ATMega32U4 nem jó? Abban HW USB lenne....

Köszönöm, több dolgot is szeretnék kérdezni, ha nem gond egy post-ban leírom:

Ahogy néztem, az USB csak a bootloader idejére él, csak feltöltés módban.

Szerintem nem kell a watchdog.
A következő miatt gondoltam mégis rá: Az történt, hogy egy ATMEGA328-at tartalmazó eszköz (akvárium hőmérséklet mérés+hűtés) mellett a hosszabbító
kapcsolójával egy neoncsövet, egy akvárium levegőztető pumpát, és egy akvárium szűrőt is bekapcsoltam egyszerre, és az ATMEGA328 "meghülyült", amíg újra nem indítottam kézzel. Ez egy stabilizált 5V-os tápegységről ment közvetlen, egy 100 nF-os szűrő kondenzátorral. Az ilyen/hasonló esetekre, kell/jó lehet a watchdog?

Az ATMega32U4 és az FT232 is jó lenne, de ezekből nincs DIP tokos, az SMD-s alkatrészek forrasztása "projektet" várom, de még a nyák készítés is előttem áll. Ez a metaboard szuper jól működik, mert csak "rádugom" a számítógépre, és rögtön fel tudom tölteni a programját, de valószínűleg egy jó programozóval jobban jártam volna. AVRISP MKII, vagy avr-dragon-on is gondolkodtam már, kérdés hogy melyiket érdemes beszerezni? (win8-hoz és linuxhoz)

A bootloader fordítás tapasztalatok:
Linux alatt akartam lefordítani, azt gondoltam hogy jobban járok mint Windows alatt, de több dologba is belefutottam.
- A fordítás elvileg sikerült, be kellett írni a makefile-ba az MCU típusát.
- Permission denied hibaüzenet a /dev/ttyUSB0-ra. ezen túljutottam root-ként
- Arduino ISP-vel akartam a bootloader-t feltölteni, gondoltam így telepítem a környezetet:
sudo apt-get install arduino avrdude - el kell olvasnom egy leírást, hogy hogyan telepítsem linux alá a környezetet, mert ez így nem lett tökéletes.
- A bootloader-hez adott makefile-t testre kellett szabni az arduino ISP-hez, de a feltöltés közepén van valami "elnyelt"/"nem egyértelmű" hibaüzenet, és kilép a make parancs.
- Egy bash fájlba, copy-paste-el betettem az Arduino IDE-vel kilogolt "arduino ISP-s" avrdude parancsot. Ezzel sikerült "feltöltenem" valamit, de az rögtön szétfagy, nem működik amit fordítottam. Holnap folytatom...

[Robert]

A bekapcsolási hülyülés:
1, hiányos tápszűrés és/vagy közel megy a hálózati és az kisfesz vezeték (min 5-15 cm távolság kell, párhuzamosan ha megy).
2, a bekapcsolási induktív áramlökések a környező vezetékekben induktív feszültségtüskét okoznak. Ez ellen az Arduino chipedet nem védted (soros ellenállás, kondi, zenerdióda, stb)
3, kapcsolóüzemű a hálózati tápod és az összes zavarjel átmegy az Arduino fele.

Programozó:
- Ha csak sima AVR és nem kell debug: STK500 (Linux, Win 8x64 alatt is OK)
- MKII - AVR és XMEGA : eredeti esetén OK, de az AVRDUDE-val 1-2 fórumon küzdenek. (LibUSB vs. JUNGO driver összeakadás)
- Dragon: debug+programozás. A külső programozókénti használat (nem AVR Studio) esetén mint az MKII .

ArduinoISP:
- a fusebitek jól vannak beállítva?

[dlaszlo]

Köszönöm a segítséget!

Ma újra kezdtem az egész bootloader fordítgatást:

A linuxra így tudtam végül mindent feltenni (ubuntu 13.04) a bootloader fordításhoz:

Kód: Egész kijelölése

sudo apt-get install gcc-avr binutils-avr gdb-avr avr-libc avrdude arduino

A /dev/ttyUSB0 jogosultság probléma magától megoldódott, nem nyúltam hozzá (de frissítettem egy csomó ubuntus csomagot)

A Stephan Bärwolf által karbantartott bootloaderből indultam ki (https://github.com/baerwolf/USBaspLoader).

Átírtam a makefile-t, hogy az ArduinoISP-t használja, és hogy ATMEGA328P-hez történjen a fordítás+feltöltés (működik is a feltöltés végre):
Az ide kapcsolódó commit: https://github.com/dlaszlo/USBaspLoader ... 8b1fa6892b

Észre vettem, hogy az eredeti metaboard-hoz képest fel vannak cserélve a bootloader config fájljában a JUMPER, és az USB_CFG_DMINUS, ezt visszaírtam:
https://github.com/dlaszlo/USBaspLoader ... 1bb570ae6c

Fordítás:

Kód: Egész kijelölése

make clean
make

Feltöltés:

Kód: Egész kijelölése

make fuse
make flash

Sajnos még nem működik a bootloader, ismeretlen eszköz, a reset gombra meg sem nyekken:/ Most elgondolkodtam, hogy vagy nagyon rossz bootloader verzióból indultam ki,
vagy valami egyszerű dolog maradt még ki, elnéztem és nem jó pin-eket állítottam be az USB-hez, https://metalab.at/wiki/images/thumb/5/ ... ircuit.gif
Holnap még keresgélek.
Bár nem kell hogy működjön a watchdog, de már érdekel a dolog:)

[Robert]

HWhibák:

A nyák gyantamentes?
Kész obdev-es kódot ha ráraksz működik az USB?
A kvarc környéke is gyantátlan?
Nincs hosszú nem sodort D+/D-?
Összes tápláb bekötve?
100nF kerámia ott van?

[dlaszlo]

Köszönöm a tippeket, azért nem gondoltam HW hibára, mert az eredeti firmware tökéletesen működik. Miért okoz bajt az, ha gyantás a nyák?

Most már az új bootloader is működik

A gond az volt, hogy az eredeti bootloader az eredeti konfigurációval metaboard kompatibilis, ez az új bootloader meg ehhez készült: http://matrixstorm.com/avr/tinyusbboard/ Ráadásul a metaboard kapcsolási rajzád a PD4-hez a vezetékre rá van írva hogy 6, ami miatt tegnap félrekonfiguráltam a bootloaderconfig.h-ban a pineket, amiben még egy comment is volt, hogy az érték régen 6 volt Ez lett a javítás: https://github.com/dlaszlo/USBaspLoader ... 6834240f40

A következő különbségeket látom még a régi és az új bootloader között:
A régi bootloader-nél:
- Ha be volt kapcsolva a jumper, akkor amikor először csatlakoztattam a metaboard-ot, kilépett a bootloader, és elindult a feltöltött program, resetet kellett nyomni, hogy bejöjjön a bootloader feltöltés módban.
- Feltöltés után automatikusan indult a feltöltött progi.
- Ha ki volt kapcsolva a jumper, akkor a feltöltés mód soha nem indult el, mindig automatikusan elindult a feltöltött progi.

Az új bootloader-nél:
- Ha be van kapcsolva a jumper, akkor csak a feltöltés mód jön be, akármit is csinálok. (mondjuk ennek nem sok értelmét látom)
- Ha ki van kapcsolva a jumper, akkor először a programom indul el, reset gombra a feltöltés mód, feltöltés vagy újra reset gombra ismét a programom, stb...

Ahogy nézem még, itt már nincs szükség az 1MOhm-os ellenállásra a kapcsolásban. (én meghagytam, gondolom nem okoz gondot)

A watchdog-ra nem fagy szét ez a bootloader - de sajnos reset-re a feltöltés mód jön be, itt majd valahogy módosítani kell a bootloader-en. Gondolom nem lehet nagyon bonyolult, valahogy le kell ellenőrizni, hogy watchdog reset volt, és ha igen, akkor elindítani az eredeti programot. A kérdés az, hogy (ahogy írtad is) lehet hogy az arduino-ban sem véletlen van az a védelem, hogy megáll a bootloader ha watchdog reset volt, ez az áramkört védi. Esetleg meg lehetne azt csinálni (nem tudom még hogy ), hogy x időn belül van két reset (pl 5 percen belül), akkor megáll, ahogy az arduino-ban is megáll a bootloader, vagy hasonló.

[Robert]

Gyantás nyák: vezet, légnedveség hatására. Nálam 10kohm-ra ment le

A várok, jegyzem mi volt az előzmény - tipikus EEPROMba mentegetős feladat.

[dlaszlo]

Ahhoz hogy működjön a watchdog, vissza kellett tenni a feltételt, hogy ha nem külső reset történik, akkor a bootloader lépjen ki:
https://github.com/dlaszlo/USBaspLoader ... 2ece422801
Így a feltöltött programban le lehet kezelni, ha watchdog reset volt.