Svenska ElektronikForumet

Har gjort ett antal kort åt en kompis baserat på ATMEGA8L, Och dessa har börjat strula. Allt har funkat bra innan men helt plötsligt en efter en så har de slutat fungerat, och bara skickat "C C C C C" ut i en ändlös loop. Detta stötte jag på när jag programmerade i första början men gjorde fel någon gång, har dock aldrig återkommit sen.

Till detta säger han även att några kort som inte ens varit fysiska inkopplade innan har "tappat minnet" av att ha legat i ESD påsen ett par månader. De skickar även bara ut "C C C"... är detta ens möjligt?

Någon som stött på något liknande innan?

Mvh Micke

Var skickar de ut C, på uarten?? Vad ska korten skicka ut när de fungerar??

Vad ska dom skicka ut? På vad skickar dom ut det(uart,SPI,TWI, annat?)? Det behövs nog mer beskrivning överlag för att man ska kunna uttala sig om vad det kan vara för fel.

EDIT: För långsam igen

Det kan faktisk vara möjligt men det beror på hur chippen är programmerat. Det finns (gamla) sätt där programmeringsenheten utför "laddningen" av minnescellerna och då kan ett felaktigt sätt göra att programmet har ganska kort livslängd.

Använder man dock ett chip med inbyggd bootloader och spänningsnivåer är rätt under programmeringen bör det inte ske... och inte med fler chip.

Det är alltså något arbetsförhållande som har blivit fel så att chippen är rätt men den kanske resetter? Watchdog?

Vi hade ett liknande fel på ca 20% av en 200 batch MEGA128or. Efter omprogramering och sänkning av klockfrekvensen från 16MHz till 11,5920MHz så försvann problemet. Vi provade även att bara sänka klockfrekvensen då hoppade de flesta igång...

Låter som ett programminne-fel och dålig kontroll av fabriken om de är specat till 16MHz... eller ska man lägga in wait-states och det var glömt?

Ja den skickar ut detta på Uarten, jag tror dock det beror på att det inte varit riktigt konfat på Brownouten, förmodlingen har det varit riktig fulspänning in till den som hoppat och spikat och gjort eepromet korrupt eller nått.

Provade att flasha om de nu och då funkar det som vanligt. Får se om problemet uppstår igen. Jag kör på 3.68Mhz så så högt kör jag de inte.

Läste du in minnet (Flash och EEPROM) från AVR:erna till datorn och kollade om det stämde?

Om det är så många AVR:er som strular på samma sätt så får du väl fundera på om det kanske är något fel i AVR-programmet.

Det finns ju inget skydd i AVR för att förhindra att den skriver sönder sig själv, ett osannolikt fel men inte omöjligt, speciellt inte om man har kod i den som skall kunna uppdatera det interna programmet.
BODEN inställningen är jätteviktig att den är rätt inställd och påslagen, om inte så skriver man sönde EE2PROMet innom några hundra omstarter (konstaterat och statistikt säkerställt i ett praktiskt försök på 20 enheter och 1000 omstarter).
Vi ISP´ar bootkoden och fusebittarna.
Sedan i samband med kalibreing och test så läggs själva applikationskoden ned via serieportar.
Iinnan kalibreringen är godkänd så kontrolleras att ALLA fusebittarna är rätt.
Jag kan inte förstå varför inte alla inställningarna kan sparas till fil utan måste skrivas in innan varje bootkodsprogrameringsesion, detta ger aldeles för stor risk för felaktigt programerade enheter.
Vi använder Atmels egen AVRISP med tillhörande programvara.

I senaste versionen av avr-gcc kan man ange fuse-bitarna i koden.