Svenska ElektronikForumet

Det är helt klart något som påverkar programmeringspinnarna som skiljer. Och nu vet jag inte med ATmega men på t.ex. PIC kan det ju finnas en LVP-pinne som måste stå i rätt läge fram till man disabler den för att programmeringen ska fungera.

Så ta reda på vad som är kopplat på programmeringspinnarna, detta inkluderar dåliga lödningar osv.!

Nu så kanske jag har missat något, men är det ens säkert att det
är ISP som används? Det kan vara bootloader också, och då är nog
sådant som LVP-pinnen (om det hade varit en PIC) ej aktuellt.

Nej, schema för kortet där det inte fungerar är vad som behövs nu.

Ja, det är bootloader.
Schema kommer här.
Eagle PDF Något påverkar uppenbarligen och jag ska på med skåpet och kolla signalerna men jag måste iväg till Norge en sväng så det får vila till helgen.

Tack för att ni inte gett upp på mig ännu

OK.
SV5 ser ut som ISP-port, men det kör du ju inte.
Är det SV7 som du programmerar via?

Det enda som jag ser lite snabbt är att hanteringen av RESET (som är kritisk för
att bootloadern ska börja ladda) inte fungerar som den ska. Där skulle jag börja
mäta. Det som talar mot det är att det fungerar då du ansluter från sockeln
till en DIP-klämma. Så en glapp sockel kan absplut inte uteslutas...

Satt i en ny sockel och det beter sig precis som tidigare.
Hastigheten vid uppladdning är 115KBaud men det ser ok ut på analoga skåpet (100Mhz BW).
Ska hämta in det digitala skåpet från verkstan och titta mer i detalj på signalen.
Ska även prova att fånga det med Saleaen.
Tror jag kan utesluta glapp utan får koncentrera mig på signalkvaliten.

Digitala skåpet visar inte heller några konstigheter på signalen (400Mhz/400MSa/s). Nu ska vi se vad logikanalysatorn säger om konversationen...
Börjar även luta mot att det kanske är något fel på chippet, ska prova att programmera in bootloadern i en annan krets. och se om den beter sig lika dant.

Saleae visar att kommunikationen kommer igång.
Innan uppladdning startar ska det utväxlas ett antal meddelanden.
0x30 0x20 ska besvaras med 0x14 0x10 tre gånger ("ping-pong").
Sedan ska följande utväxlas
0x4 0x81 0x20 besvaras med 0x14 0x01 0x10
0x4 0x82 0x20 besvaras med 0x14 0x10 0x10
Efter det börjar det sändas lite dataskurar som besvaras med 0x14 0x10 och lite annat

När det failar så stannar det då den första dataskuren inte besvaras eller att något av de tre första "ping-pong" inte besvaras.

Har mätt med digitlskåpet samtidigt och det fångar sista paketet som ser helt ok ut även där.

Ska prova att byta krets i morgon, "The search goes on..."
Har jag lagt så här mycket tid på det nu så ska jag bara få igång det (känna mig som han i Segelsällskapsresan som inte får igång utombordaren och till slut hämtas i tvångströja )

Så här ska det se ut (svar tabbade ett steg ut):

Resetkoppling blir lite skum när du programmerar genom en Uno.
Du får dels ditt målsystems RC-nät som det "ska" se ut, sen kopplar du ihop det med ännu ett pullupmotstånd och DTR via en kondensator med samma värde. När DTR vill sänka resetingången stretar din kondensator emot, och jag tror att det blir nån halvmesyr till reset där. Skulle kanske till och med kunna vara så att den hamnar så på pottkanten att lite extra ledningar (till breadboarden) gör att det funkar bättre.
Du skulle ju kunna testa att exempelvis öka ditt pullupmotstånd till det dubbla, och halvera kapacitansen. Det ger samma tidskonstant vid standalone, plus att DTR och dess kondensator får mer att säga till om i ihopkopplingen.

> Så här ska det se ut...

Alltså då det fungerar?
Hur ser det ut då det *inte* fungerar?

Kan du ser med "skopet" att resetpinnen hanteras enligt spec
för att bootloader processen ska starta korrekt? Det är ju
en kritisk del för att det ska starta...

EDIT: He he, Wedge tänker i samma banor som jag...

@Sodjan, Loggen visar hur det ser ut när det fungerar.
När det failar så slutar målsystemets CPU att svara med 0x14 0x10 vid något tillfälle, det ser alltså helt ok ut i början.
[har editerat i loggen var det "brukar stanna]
När "uppladdaren" inte får kvittens så avbryter den, om kvittens uteblir tidigt i kommunikationen så gör den ett försök till efter någon sekund men då har CPU'n redan gått ur bootlöoader läge och börjat köra sketchen.

Reset pinnen går låg som den ska (syns på båda skåpen och i logikanalysatorn) och eftersom CPU'n svarar på de första kommandona så kan man sluta sig till att reseten gick igenom.

@Wedge, jag har tagit bort kondensatorn på resetpinnen i målsystemet för att undvika det fenomen du nämner och som sagt så fungerar reseten.

Logen är tagen med CPU i breadboard men med målsystemet inkopplat så det är inte elektriskt någon skillnad (vilket är det irriterande felet).

Inte för att det kanske har med saken att göra, men varför är RESET kopplad även till PB0(ICP)? Om du drar PB0 låg, resettar du inte allt då? Förstår inte riktigt grejen med hur det är kopplat.

@Kaggen, den är till för att jag ska ha en timer-interupt-driven mjukvaru "watch dog" som resetar CPU'n om programmet hänger sig.
Det ska styra ett torkskåp med ett värme ellement på 2200W så jag vill inte att det ska fastna i läge på och grilla kläderna...
ATMEGA328 hårdvaru "watch dog" kan inte användas i ARDUINO sammanhang tyvär.
Genom hårdvaran är det redan uteslutet att värme ellementet kan vara på om fläkten är av samt att det finns två temperatursensorer.

Kopplingen mellan PB0 och Reset har jag brutit på målsystemet för att utesluta att den kunde ha påverkan på problemet jag har.

Så, då har det varit progress. Inte för att jag löst mysteriet men nu har jag ett målsystem som går att ladda upp till

Vad hände? Jo, den krets jag köpt var en ATMEGA328-PU, alltså inte den pico power som sitter i en Arduino normalt, den heter ATMEGA328P-PU (ett P direkt efter 328).
När boot loadern ska brännas in måste man ändra kretsens signatur i filen avrdude.conf vilket fungerade helt ok. Sedan fungerar en 328 precis som en 328P i Unon.

Nu brände jag in en "vanlig" Uno boot loader i 328'an och satte den i en Uno, den fungerade utan problem.
Den 328P jag nu hade ledig brände jag in en "bread board" boot loader i (den utan extern kristall) vilket gick bra.
När jag nu sätter denna 328P i målsystemet (med samma boot loader som tidigare) så tar den snällt emot programvaran

Så jag har löst mitt problem men jag har inte knäckt varför det betedde sig så konstigt med en 328.

Så vad lär jag mig?
Galet kopplande fram och tillbaka gav inget (förutom insikt i hur knasigt det betedde sig)
Analogskåp gav lite (kunde se att signalen såg rimlig ut)
Digitalskåp gav lite mer (kunde se att signalen var fin)
Logikanalysatorn gav mest (kunde se att det faktiskt inte var helt dött, den startade i alla fall)
Trial and error med olika kretsar som "skulle vara kompatibla" löste problemet men inte gåtan.

Nu kan jag äntligen gå vidare och börja testa ut programvaran till torkskåpet.

Ett stort TACK! till allt stöd och alla goda idéer.

/PS
@Wedge, med kondingen på reset på plats så fungerar inte reset vid uppladdning precis som du trodde så den får vänta tills allt är färdig programerat.
/DS

Jag har för mig att skillanden mellan 328 och 328P är en av
de saker som nämdes då jag googlade runt kring problemet.
Jag vet att jag *tänkte* på det, men måste ha missat att
nämna det i tråden. Eller så trodde jag kanske inte att
det hade något med det aktuella fallet att göra...