Vad är det som gäckar mig? (ADC -> µC)

[jesse]

Idag råkade jag ut för något mycket märkligt , som jag inte kan förklara.

Jag har fått tillbaks två kretskort från en kund för att uppdatera firmware.
Kretskorten har varit testade av mig före leverans, sedan legat på lager hos kund.

Nu när jag kopplar upp korten mot testrigg så är det en ADC som läser tokfel värden.
Något liknande har aldrig skett tidigare. Kundens version av firmware är 1.05.
Jag uppgraderade till senaste version (1.09) men samma fel bestod.

Jag testade mjukvaran (1.09) på ett kort jag har liggande hemma, och ADC uppför sig korrekt.
Jag jämför de båda kretskortsversionerna (kundens var äldre), men den aktuella ADC:n var identiskt kopplad.

Faktum är alltså: Då jag skickade korten har de fungerat med gammal mjukvara (1.05), när jag får tillbaks dem
beter sig båda korten exakt likadant = fel.

Jag känner mig mycket förbryllad. jag har redan gått igenom en massa mjukvaruparametrar, kollat koden, loggat inkommande rådata från ADC... Data jag får ut ser slumpartade ut, vilket beror på att det filtreras. Men när jag kollar rådata in från ADC så ser jag att ungefär 6 värden av 7 består av 0xffff. Kollar med oscilloskop, men där ser jag inget fel (En MCP3301 som pratar SPI med en AVR via en AdUM1201 isolator).

Och så plötsligt fungerar det ena kortet igen. Utan att jag ändrat något. Det andra har jag inte kopplat in ännu.
Extremt irriterande!

Dessa kort ingår i ett extremt misslyckat projekt. Det har varit strul sedan start. Laminat levererade med felaktiga vior, IC som går sönder utan anledning , felberäknade resistanser, konstig mjukvara.... har förföljt mig ett par år nu, och i november trodde jag att allt var över. Så kommer dessa @!#¤&%* kort...

[gkar]

kul!...
Saknas pull-up?..

[Nerre]

Spontant: Glapp i matningen till ADC så den bara fungerar ibland? (Kallödning t.ex.)

[ajje]

Kan kunden ha misshandlat ADCns ingång med ESD?

[Icecap]

Min teori:
När värden som är "rätt" är OK skulle jag tro att det rör sig om en timing-fel.
* SPI-kommunikationen ska inte göra så mycket - men jag antar att du har kollat noga med flanker, tiden mellan, data settling time osv. Om inte: gör det!
* Får omvandlaren tid nog att faktisk göra en omvandling? Här pratar vi worst case.

Det kan vara en timing som beror på temperaturen och där kunden - under drift - har en annan temperatur än vid test på bänken hos dig.

[Rick81]

Kan du förklara lite mer om SPI avläsningen hur den görs i SW? Görs den via SPI-hårdvara? Interupt? Kan du disabla interrupt?Timing? osv?

Skulle nog gissa att det är något med SPI-koden, det är mer än en gång jag varit övertygad om att det är HW som strular men sen visar det sig att det i själva verket var SW. Interupt har ju en tendens att bete sig "slumpartat"...

[bearing]

Du skriver att du kollat med oscilloskop och inte ser något fel. Menar du då att datan på mikrokontrollerns SPI-pinne ser ut att vara korrekt, men att datan blir 0xFFFF i ditt program?

[jesse]

Löste det lite senare.

Jag hade visserligen kollat med oscilloskop, men inte överallt. Det visade sig att det fanns en via med resistans > 1 kohm. Den gamla kortserien hade ju problem med viorna, och när jag kollade vidare lite mer i går kväll så såg jag att jag hade inte signal hela vägen fram på DO (data output). Åtgärdade det med att löda en kopparledare genom vian.

Det gör inte saken lättare att hela kortet är indränkt i ett 1 mm lager silikon.

Annars bygger just den här lösningen på en egen variant av galvanisk isolering av SPI. Normalt har man 3-4 ledare: SCK, CS, DI, DO. Men data går bara i en riktning, och CS genererar jag med hjälp av SCK. Jag behöver bara två isolerade datalinjer - SCK och DO. Detta isoleras med ADUM1201 digital isolator. När klockan går låg så går även min virtuella CS låg - men går inte hög igen förrän efter en kort fördröjning vilket gör att CS håller sig låg så länge klockan håller en viss hastighet. Fungerar klockrent. Normalt skulle det behövas en bufferkrets på CS-ingången, men MCP3301 har schmitt-trigger-ingång på CS, så den är redan buffrad, och omslaget blir distinkt.

[Icecap]

Bra att orsaken hittades! Att ett fel "åtgärdas" utan att man gör något är så extremt frustrerande - för inget är ju fixat!

Och din CS-lösning tycker jag är alldeles OK!