Ett intrikat programvaruproblem

[TomasL]

Så här ser det ut:
Har 5st AD-Omvandlare TI ADS1248 (24-bitas med 8 kanaler, SPI).
1 st AD5412 DAC (12 bitar, SPI)
1 st MC33972 (24 ingångars switch detektor, SPI)
2 st MAX498 (8-kanalers relädrivare, SPI)
1 st SPI FLASH

på SPI-Linan ligger alla parallellt, utom MAX-kretsarna som är seriekopplade
AD-Omvandlarna och DACen har gemensam reset-lina
MAX och MC33 har gemensam resetlina
MAX har gemensam CS, övriga har dedicerade CS


Vad som händer är att AD-omvandlarna slumpmässigt blir nollställda, ibland en halv, ibland en, osv.
Vi har kört samma kod mot samtliga dessa kretsar i snart 10 år, utan problem, nu helt plötsligt har detta börjat hända.

Samtliga skrivningar/läsningar av SPI-linan sker från samma TASK (vi kör OPEN-RTOS), så det kan aldrig bli två skrivningar till SPI-bussen samtidigt (eller snarare borde inte kunna).
Samtliga accesser på SPI-Bussen avslutas med att Respektive CS går hög.
Gissningsvis är det en pekare som under exekvering hittar på något dumt i bland och skriver nånting till porten där CS-signalerna ligger.
Det periodiciteten är från var 15de minut upp till varannan vecka.

Rent praktiskt sett så är det två register AD-omvandlarna som "Nollställs", dessa register styr de två inbyggda strömgeneratorerna som exciterar PT100-givarna som är anslutna (2 per AD-omvandlare), antingen så skrivs registren över (troligast, eftersom det i bland enbart är konfigen för den ena generatorn som skrivs över), eller också så får omvandlarna ett reset-kommando.

Processor är PIC32MX, kompilator är XC32 (GCC).
Hur i helsike skall man kunna felsöka detta, någon som har ideer.

[Shimonu]

Bara en tanke jag hade tidigt. Finns det övervakning på spänningsnivåer? Sporadiska fel behöver ju inte betyda programfel och jag fick inte känslan av att det var fastställt här. Du säger att du kört samma kod i 10 år, det är ändå bra stöd för att något annat kan vara problemet än koden då.

[TomasL]

Nja, jag tror inte så mycket på det, felen har visat sig på både ny och gammal utrustning, och verkar vara kopplat till en programuppdatering. Dock sker det inte överallt, utan vi har väl ett 10-tal enheter av ett par hundra som beter sig så här.
Koden som hanterar SPI-Bussen är 10 år gammal, dock är ju annan kod från relativt ny till helt ny.

[Polyene]

Hur snabbt kan du detektera att felet har uppstått?
Ett sätt skulle kanske kunna vara att toggla en pinne så fort det upptäcks, och låta oscilloskopet trigga på den signalen. Sen får man ju titta på vad som hänt på bussen, reset m.m. strax innan det triggade. Ett oscilloskop med mycket minne är ju så klart bra i det fallet...

[TomasL]

Som sagt, slumpmässigt mellan 15 minuter och två veckor, om det sker överhuvudtaget.
Jag har kört utrustning hemma i flera veckor utan problem.
Dock, har jag börjat få lite ledtrådar om när det uppträder, vilket gör att jag troligen kan forcera fram det hemma lite lättare.

[ToPNoTCH]

Är det inte enklast att alltid sätta dessa två register, om inte annat som en redundant lösning.

Sen är det nog bra med en riktig resetkrets/spänning monitor då det systemet verkar lite komplext.

Långskott är väl även att kolla lite Errata på chippen (eftersom det funkat förr och inget är ändrat)

[TomasL]

Jo, vi sätter numera (sedan i går) dessa två register varje gång vi skickar mät-konfigurationen till AD-omvandlarna, vilket verkar ha löst problemet i sig. dvs fixat till korrekt resultat, men inte roten till problemet.
Anledningen till att vi inte gjorde det tidigare var att det tidigare inte behövdes, och att det käkar tid.

Jo, jag har gått igenom alla errata osv, de som är aktuella är redan kompenserade för, sedan tidigare, dvs inga nya de senaste 8-10 åren.
Har kikat på kort-lösningen, den är nog inte 100% optimal, och behöver fixas till, och kommer att fixas i en kommande revision (när jag fått #%&?#¤? MPLABX att fungera), dock som sagt, det har funkat problemfritt i 10år.

[mankan]

Ta hem ett system (kanske inte helt enkelt) som visar symptomet ofta och börja intervallhalvera mjukvaran. Som mjukvarumänniska vill man gärna skylla på hårdvaran men det är bara rätt kanske 1 gång på 50 eller 100.

[TomasL]

Nja, att ta hem ett system är omöjligt, så jag måste försöka forcera det hemma, alternativt komma på ett sätt att felsöka on-site, utan att plocka isär hårdvaran.
Problemet är dock, det går inte köra vanliga debug-sessioner.

[LHelge]

Nu känner jag inte till OPEN-RTOS, men andra RTOS jag pysslat med brukar kunna ha konstiga saker för sig när stacken tar slut i en task.

Har du lagt till någon mjukvara nyligen som ökar behovet av stack antingen i SPI-tasken eller i någon annan task som är inne och skriver i SPI-taskens stack?

FreeRTOS t ex har viss övervakning (watermark) på stacken men min erfarenhet är att det funkar sådär... På en ARM Cortex-M brukar det oftast märkas på att du får ett HardFault-interrupt när du derefererar en pekare av skräpdata, men jag vet inte hur en PIC32 hanterar det. I veldigt speciella fall skulle det däremot kunna leda till att du skriver data som är "trovärdig" så programmet snurrar på som vanligt men med odefinierat beteende.

[mankan]

När du säger säger saker som att koden har varit densamma i 10år så väcks följande tankar i mitt huvud:
Vilka ändringar i OS, kompilator, grundläggande C-bibliotek har skett under den perioden?

Har t.ex själv varit med om kod som varit oförändrad i 8 år som plötsligt började få fel den inte kunde hantera. Grundorsaken, koden var skriven för Linuxkärna av version 2.4 och nu kördes koden på 2.6 och version 3.x.

Är systemen som uppvisar problemen nya (dvs ny HW) med ny mjukvara eller gamla (åldrande komponenter?) med ny mjukvara?

Du nämner också GCC? C eller C++? Vilken, vilka versioner? Vilka optimeringsflaggor? Har varit med om fall där -O2 funkar men inte -Os, Linuxkärnan hoppade snett i nästlade if/else när den skulle montera flashfilsystem.

LHelge: Du får mig tänka på en grej vi gjorde på jobbet en gång. Fyll det outnyttjade minnet med typ, 10 GOTO 10. Då kan du med debugger (ifall du har en sådan i din miljö) stoppa processen (task:en) och inspektera stacken, istället för att CPU:n kör skräp orsakar undantag och kanske tom loopar runt till adress 0 och startat om lite lagom obemärkt.

[TomasL]

Samma bibliotek, samma kompilator, samma RTOS sedan start, ingen uppgradering av biblioteken, vad jag vet, Jo Kompilatorn uppgraderades för en 4-5 år sedan.
Det är ren C, dvs inte C++

Orsaken till att detta inte ändrats är att dels MPLAB 8 slutade uppdateras för en 5 år sedan eller så, samt att vi inte sett något behov av att uppdatera RTOSet, då allt funkat som det skall.
OPEN-RTOS är exakt samma sak som FREE-RTOS.

PIC32 är en MIPS
Btw, vi använder O1 som optimering.

[LHelge]

LHelge: Du får mig tänka på en grej vi gjorde på jobbet en gång. Fyll det outnyttjade minnet med typ, 10 GOTO 10. Då kan du med debugger (ifall du har en sådan i din miljö) stoppa processen (task:en) och inspektera stacken, istället för att CPU:n kör skräp orsakar undantag och kanske tom loopar runt till adress 0 och startat om lite lagom obemärkt.

Precis det FreeRTOS gör om man definierar:

Kod: Markera allt

#define configCHECK_FOR_STACK_OVERFLOW 2

Den fyller stacken med ett förutbestämt värde och håller koll på det när man går över nuvarande watermark.

Kod: Markera allt

#define configCHECK_FOR_STACK_OVERFLOW 1

Kollar att watermark inte går över stackens storlek

Kod: Markera allt

#define configCHECK_FOR_STACK_OVERFLOW 0

Checkar inte för detta, vilket ger en viss prestandavinst.

Jag har därmot haft blandad framgång med detta, kan bero på att jag oftast köpr med statisk allokerad stack, vet inte hur bra det fungerar då.

TomasL: Tyvärr har jag inte använt PIC32 (eller MIPS) på över 10 år, så jag kommer inte ihåg hur den hanterar vanliga problem vid skräp i stacken, som null-pointer dereferencing och loknande.

[TomasL]

Vi borde inte ha några stackproblem, eftersom vi har väldigt få lokala variabler i funktionerna, mest några enstaka räknare, och en del statiska variabler, samt en del register-variabler. Vi har inga rekursiva funktioner, och vi dyker inte så långt ned, dvs, vi har inte så många nivåer av funktionsanrop, det mesta är rätt "platt".
Om vi tolkat dokumentationen rätt, så anges stackutrymmet i 32-bitars ord, vilket innebär att vi har minst 512 32-bitars ord i stacken (dvs 2kByte), en del tasks har större stack.

Men det tål att undersökas, definitivt.

[xxargs]

Ta hem ett system (kanske inte helt enkelt) som visar symptomet ofta och börja intervallhalvera mjukvaran. Som mjukvarumänniska vill man gärna skylla på hårdvaran men det är bara rätt kanske 1 gång på 50 eller 100.

Äntligen en mjukvarumänniska med lite insikt med tanke på så mycket skit vi 'hårdvaru och transmissionsmänniskor' har käkat under åren som ändå i slutändan 'bara är en liten bugg i programkoden'


Sedan är det också bra att få in i mindsetet att använda checksummor eller hellre CRC-värden i sina paket (och i rätt ordning och inte spegelvända eller göra något annat dumt) och bygga i mjukvara att det _kan_ skita sig och kommer att göra det och att det måste hanteras snyggt.

Transmission/överföring har alltid ett tryck av fel utifrån med både burstfel (tex. när en kontaktor bryter i närheten och det blixtrar och har sig) och slumpmässiga fel av brustyp. Tre vanliga nivåer i feltakt att räkna på är BER 1*10^-5 (felsannolikhet på magnetmedia, optisk media, TLC/QLC-flashmedia - innan korrektion, överföringsfel över radiovior, mm.), BER 1*10^-6 på oskyddad kabel (RS232-obalancerat, RS485 på oskyddad kabel) och BER av 1*10^-12 för mer skyddade, skärmade kanaler som Ethernet, SATA mfl.

En CRC-värde har alltid (mycket) bättre upptäcktsförmåga av fel än en checksumma med samma antal bit i kontrollvärdet.

Vill man läsa mer om sådant - kika i https://users.ece.cmu.edu/~koopman/pubs ... tation.pdf och där i slutet även presenterar några implemetationsmissar i tex. CAN-bussen där dataintegritetskollen i överföringen i stort sett utraderats för 2 bitar fel i använda polynomet, oskyddad paketstorleksvärde, placerar CRC före datat eller spegelvänt utskriftsordningen på kontrollvärdet - dvs. LSB och MSB-ordning som programmerarna inte tänker på innan datat körs ut seriellt på UART/överföringsgränsnittet och kan helt ruinera upptäcksförmågan av bit-flipsfel, olika kanalkodningars påverkan (8B/10B-kodning etc.) och många fel går igenom helt oupptäckta.

När man läst igenom detta så inser man att ZFS fletcherchecksumma är inte någon vidare skydd för datat då SATA:s IEEE802.3 CRC behöver släppa igenom 1000-10000 fel oupptäckt innan Fletchersumman tar en enda av dem.

Medans BTRFS CRC32C (samma som används av iSCSI och SAS) har ca 10000 ggr större sannolikhet att hitta fel som missas och går ej upptäckt igenom IEEE 802.3 CRC32 i SATA-bussen - så stor skillnad är det bara i val av rätt polynom för CRC utan att beräkningskostnaden för CRC skiljer sig något alls.

Om man är lite elak så är ZFS Fletchersumma ett skydd för logiska fel gjorda av programmerare som hanterar filsystemet själv under utvecklingen av ZFS och möjligen korrupta data från SD och micro-SD minnen och somliga USB-stickor - inte att fånga brusstörda sektorer med alternativa innehåll än den tänkta originalet i samband med överföring och som inte redan är fångad av SATA-bussens CRC32-checkvärde. Skall man få högre skydd så måste man slå på ZFS SHA256 kryptografiska starka hashvärde av sektorer (används när den gör inband-deduplicering) men då med seriösa prestandasänkning som följd

Medans BTRFS CRC32C faktiskt också upptäcker bitfel som missas av SATA-bussens egna CRC32-kontroll i transporten av datat mellan hårddisken och datorn.
Men BTRFS har bara haft CRC32C som enda alternativ mycket länge och det är inte dugligt för inband-deduplicering då risken för att olika data in ger samma checkvärde är för stor (aka födelsedagsparadoxen)

Men helt nyligen har man infört flera alternativ på checkvärden i BTRFS med olika kostnader i prestanda och det som förmodligen kommer att användas när man vill ha bättre än CRC32C för tex. inband-deduplicering är 'blake2' då dess beräkningskostnad bara är dubbelt så stor som CRC32C och ger kryptografisk stark hashvärde medans alternativet som också finns med SHA256 kostar 8 ggr tiden (även med HW-stöd) gentemot CRC32C

8 ggr beräkningstiden med SHA256 så inser man varför så få slår på full Hashning av datat och inband-deduplikation på ZFS-filsystem - det kostar så mycket RAM-minne och prestanda pga. SHA256 att de flesta skyr för det.