temp.beroende UART problem mellan två microcontrollers

[Dalmas]

Jobbar intensivt med att felsöka ett komm.problem mellan två microcontrollers (9600 baud). (328P, 324PB) som tycks vara temp.beroende. Ibland lyckas inte ett 18 bytes mess komma "in" i uP. Meddelandet finns på RX-pinnen men registret som bearbetar det senare innehåller bara nollor samt ett status-byte vid kyla. Meddelandet har STX, CRC, och ETX.
Jag misstänker helt enkelt att ett förbisett sync.problem mellan avbrott och andra enheter gör att meddelandet förkastas av mottagande modul då CRC inte stämmer men det som talar EMOT detta är att problemet tycks vara temperaturberoende. DÅ tänker man att baudrate/kristall ligger lite fel. Det emotsägs av att en flash-programmering m.h.a bootloader fungerar fint och den komm. pågår i 38kbaud (samma uart-port) och vid olika extrem-temperaturer.
Det hör till saken att andra kortare meddelanden på uart fungerar. Detta meddelande är längst och ofta är felaktigt.

Orsak 1?
Det jag noterat av en tillfällighet är vid korrekt överfört meddelande "släpper" sändaren spänningen på RX tidigt direkt efter att meddelandet överförts. När jag kyler ner hela PCB:et (15x25mm) och meddelandet INTE tas emot korrekt har uart-porten släppt mycket senare. (1 ms rel. 20 ms).
Med att "släppa" RX-pinnen menar jag att jag ser ett tydligt knä i spänningen på pinnen. Från att ha legat på 0V direkt efter meddelandet går den något negativ lite senare och blir "fri" . Som sagt, detta knä uppkommer vid olika tidpunkter vid olika temperaturer. (Det jag använder mig av för att mäta allt detta är diff.förstärkare, Labview och kylsprej)

Orsak 2?
Till saken hör att jag hittat en enhet som sprutar ur sig avbrott relativt snabbt medan denna kommunikation pågår. Det avbrottet bör ju kunna hanteras ändå tycker jag även om inklockningen av ovan beskrivet meddelandet också sker m.h.a avbrott. I samband med detta uppkommer ju frågan om temp.beroendet. Kan förändringen i temp. göra att enheten som genererar denna stora mängd avbrott driva i tid så den sabbar meddelandet som samtidigt tas emot?

Frågor
Det jag önskar vet mer om är vad som sker i uP när sändande enhet släpper ledningen. Den förändringen tycks vara temp.beroende.
Kan ett yttre avbrott som kommer relativt ofta störa en pågående uart-kommunikation? Ska det inte vara prioriterat? Det ena väntar tills det andra är klart?

Något förvirrande inlägg men hela problemet är förvirrande. Ev. svar ger mig mer ledtrådar.

[Marta]

Du får ursäkta, men det där var ganska hyfsat obegripligt. En UART "släpper" aldrig signalen, finns inget som heter så. Menar Du att den går till/från tristate för att tillåta andra enheter att sända på samma signalledare.

Är alla matningsspänningar inom toleranser? Mäts med scope, inte 5-siffrors DMM.

Är klockoscillatorn stabil vid den kylda temperaturen? Mätning med scope och satidigt test av att felet finns där. Proben kan påverka. Sätt proben på utgångspinnen som driver kristallen.
Olika tider på något vid olika temperatur säger att klockan är instabil.

Vad är det för processorer?

Kylspray är något extremt. Den kan antagligen kyla MCU utanför spec.


Tillägg: Du skriver om negativ spänning. Är där RS-232-drivare inblandade?
Om denna genererar sin egen negativa spänning, fungerar detta stadigt då den är kall?

[Dalmas]

Ha ha. Ja. "Släpper" är fel ord. Det är tristate som sker. Processorerna är 328P och 324PB.

Jag säger kylsprej men felet uppträder när tempen stiger från det extremt kalla till rumsvarmt. Där finns ett fönster där felet sker. Detta "tempfönster" finns runt 18-20 grader så när det är kallt ute är det lite svalare i mitt kontor och då uppvisar samtliga samples mer eller mindre samma symptom.

Spänningsmatningen har jag varit inne på också. Den kommer från en extern modul (ca. 10 cm kabel) där 324PB sitter. Processorerna har samma matningskälla alltså. Den ligger på ca. 3.3V

Jag har mätt galet mycket hela veckan och det hetaste spåret nu är den lilla enheten som sprutar ur sig avbrott oavbrutet. Detta kan ev. påverka meddelandet så det förkastas.

[Marta]

Om det funkar vid lägre/högre temperaturer än 18..20 grader, släpp temperaturspåret. Det är ytterligt osannolikt orsaken.

Finns där något som lägger stor last på en enhet så får Du räkna efter så buffring i UART räcker för att inte tappa tecken. Testrutin som skriver ut det råa meddelandet på en display hjälper mycket.

Interruptprioritet i bemärkelsen att en IRQ kan bryta en annan finns nog i bästa fall som en låg och en hög som användaren måste tilldela. Med färdiga libbar från olika håll flyter sådant omkring hur som helst.

Du har alltså flera enheter som kan sända på samma lina? Håller protokollet som undviker att två skickar samtidigt? Är det egenutvecklat och ännu inte validerat är sannolikheten för protokollfel hyfsat stor.

"Flyter" UART ingång så måste den hållas på stoppbit tillräckligt länge innan meddelandet börjar och protokollet måste kunna flusha skräptecken. Så drygt ett teckens tid i vila och unik startsekvens krävs då innan meddelandet.

[Dalmas]

Ok., Ja. Om jag skippar temp.spåret så förenklar det mycket och kan göra det mer begripligare.

Nej, det finns inte fler enheter på samma uart. Den andra enheten som genererar en stor mängd avbrott går på i2c till 328P processorn. Samma processor har denna uart-port som pratar med 324PB processorn.

Om vi släpper temp.spåret så skulle jag absolut leta problemet i testmodulen i mjukvaran. Felet uppträder i slutprovningen och det är en helt egen separat mjukvarudel i 328P som används då. Driftmodulen i programvaran är totalt omskriven och ny. Testmodulen är hjälpligt moddad men kan finnas en hel del skräp kvar där sen gamla versionen. Testmodulen är gjord mest med Copy-Paste och det kan ha slunkit med skit där. Bla. är just uart-komm en ny företeelse i denna testmodul.
En lösning som ska testas på måndag är att bara använda den "andra i2c-modulen" då den behövs. Det är fullt möjligt att den IRQ-rutinen är ständigt aktiv. Den behöver bara vara aktiv då den delen testas. Däremellan kan den stängas av och behöver då inte uppträda medan uart:en jobbar.

Tack för de nya tankebanorna.

[ds77]

Vad är det för cpu och hur är de klockade?

Det jag tänker när jag läser temperaturberoende asynkrona kommunikationsproblem är en oscillator som driver med temperaturen.

Det går ju att verifiera frekvensen med ett oscilloskop.

Edit: Nu ser jag att det troligen är en AVR, kör du med RC oscillator?

[Jan Almqvist]

Jag skulle absolut rekommendera någon typ av biasing som drar Rx till logisk ett när sändaren/sändarna är i tristate, i annat fall kan mottagande UART se startbitar när Rx inte har rätt nivå och kommer att läsa in tecken som inte finns.

[Marta]

Finns där 6 pinnar tillgängligt så anslut en standard LCD för debugmeddelanden. Det hjälper mycket att se vad som tas emot och att kunna få en bokstav som markerar när något visst exekveras.

Finns där så mycket ny programvara så säger all erfarenhet att problemet finns där.

Är det bara två enheter och alltid skall vara så finns det ingen anledning att sätt utgången i tristate. Bättre att hålla stoppbit hela tiden.

[Dalmas]

Ja. Bägge två är AVR med intern RC-osc. Tror dock inte det är baud problem då det går utmärkt i både låga och höga temp. att köra 38kbaud.

Jag tror det är pullups på RX/TX.

Ny programvara OCH gammal programvara som är snabbt moddad pga tidsbrist.

Jag ska kolla om de läggs tristate. Det görs nog för att applikationen är batt.driven.

[Icecap]

Vad jag har läst är ATmega så pass instabil i hastigheten på intern RC-oscillator, båda långtidsinstabil och temperaturberoende att jag minns minst två andra projekt med UART som föll på det.

Lösningen blev i båda fall extern kristall varefter skiten fungerade bra.

[Marta]

"..DÅ tänker man att baudrate/kristall ligger lite fel."

Med denna rad utgick jag från att Du använde kristall. Är det intosc så ändras ju läget. PIC har fungerat fint för mig på intosc, men är där ingen spec som anger adekvat stabilitet vid aktuellt temperaturområde så byt till kristall/keramik. I varje fall verifiera timingen hos både sändare och mottagare. Det skall hålla om rx/tx går i vars en riktning.

[rvl]

Det trodde jag också, när ja läste "kristall".

AVR har möjlighet till viss kalibrering av den interna RC-oscillatorn. Har du testat det? (Finns app note som beskriver hur.)

[Dalmas]

Jag skrev "fel" där när jag skrev att processorerna innehåller var sin extern kristall. Så är inte fallet. Huvudprocessorn 328P har en 32kHz för tidshållningen. Allt annat drivs av Intern 8MHz klocka. Orsaken att det inte är extern kristall där är väl tyvärr prispress. Jag kan tycka det är dumsnålt. Förr eller senare blir det problem.
324PB har dock en annan arkitektur med biterrorkompensering eller vad det heter. Den tycks kanske vara mer tryggare. Det vore en smärre katastrof om det måste göras en designförändring på PCB:n. Dock skulle jag vilja se det på sikt. En ordnad och planerad designförändring.
Som en kommentar säger; Det går att kalibrera interna RC. Ja, jag har tittat på det. Det skulle möjligtvis vara en lösning men kräver resurser både i sluttestutrustningen och designförändringar. Men.....motivationen kanske måste vara högre för att initiera detta? Ett produktionsstopp kanske? ( Jag jobbar som konsult åt ett större företag som är beställare om inte det redan framgått. Jobbet är min hobby så...)

[ds77]

Verifiera att det är detta som är problemet först...

Du kan kalibrera interna oscillatorn mot din klockoscillator. På de andra kan du kalibrera mot inkommande dataström, kolla hur det är gjort på Avr butterfly.

[ToPNoTCH]

DÅ tänker man att baudrate/kristall ligger lite fel. Det emotsägs av att en flash-programmering m.h.a bootloader fungerar fint och den komm. pågår i 38kbaud (samma uart-port) och vid olika extrem-temperaturer.
Det hör till saken att andra kortare meddelanden på uart fungerar. Detta meddelande är längst och ofta är felaktigt.

Det är en missuppfattning att lägre baudrate alltid borde ge mindre felutfall.
I verkligheten så är det ju så att den baudrate som bäst matchar prescaling av fosc ger stabilast överföring.

Detta framgår tydligt i databladet (20.10). Där finns även tabeller över respektive "Error rate %" på fosc/baudrate.

Min gissning är (som flera andra inlägg) att 9600 ligger på snudden inom toleranserna och vid temperatur förändringen faller den ur.
Att 38K funkar bättre är troligen en bättre matchning (lägre Error rate %).

Saxat ur annat forum:

For RS-232, it must be within 2% accuracy. The internal oscillator can be as much as 10% off, so unless you correct that one way or another, the internal oscillator is not accurate enough. If you calibrate the internal oscillator, you may be able to get it accurate enough depending on your circumstance. If you are going to have a stable voltage and a relatively stable operating temperature, it may work for you.

Saxat ur databladet

Higher error ratings are
acceptable, but the Receiver will have less noise resistance when the error ratings are high, especially for large
serial frames