Om man förutsätter att stm32'an kan krascha närsomhelst och hoppa till vilken adress som helst.
Kan man på nåt sätt fixa så att den inte har möjlighet att sätta PIN = AKTIV? när villkor != true ?
Ett sätt är att använda en extern RC fördröjning + komparator + watchdog-timeout) men är en ganska så ful lösning
> Om man förutsätter att stm32'an kan krascha närsomhelst och hoppa till vilken adress som helst.
Ett *väldigt* konstruerat exempel.
Du menar att processorn på något sätt skulle få spatt och "hoppa"
till SetOut() utan att passera if(villkor == true) ? Hur skulle den
komma dit ? Genom att programräknaren helt slumpvis skulle råka
få "rätt" adress ?
Ett sätt är att ha två utgångar som AND'as ihop och som var för
sig har ett if(villkor == true) villkor. Då räcker det inte med att
komma till bara ett av SetOut1()/SetOut2() anropen.
Det är sannolikt mer sannolikt att villkor sätts "true" av misstag.
njja asså om du av någon anledning skulle få ett skenande program kan mycket hända, du kan spärra läge på pinnen (alltså typ output open-drain) så att den inte kan göra om utgången till push pull tex. men att göra den 100% säkert är nog omöjligt i alla micro.(om du kan göra det i kod kan ett software runaway göra det samma. jag skulle istället lägga min tid på att kolla så att den inte skenar. just Stm32 har ett lib för klass b compliance(krävs för MC i vitvaror tex) tror de har en application note på hemsidan men koden måste du fråga ST om. teknikerna bygger istortsett på att med jämna mellanrum kolla alla register+ram+flash+PC, är nått fel så resetta micron. ett annat enket tips är att fylla allt det oandvända flash utrymmet med en TRAP/ eller reset instruktion. finns mycket att läsa om det på internet.
Jag vet inte hur just STM32 fungerar men t.ex PIC fyller minnet med NOP
vid en "Erase All", så ett skenande program kommer förr eller senare
till "reset" av sig självt. Och då kan man kolla att det inte har varit en
vanlig POR eller hårdvarureset och göra vad man tycker är lämpligt...
i det här fallet bör det vara nära 100% säkert, håller med om att det är väldigt osannolikt att den skulle hoppa till just den minnespositionen som skippar ett/flera villkor.
problemet är att det i sällsynta fall kan förekomma ström-pulser på uppåt 750A med varierande utseende/frekvens ett antal cm från mcu:n och sånt kan ju få det mesta att spöka, ska kika lite mer på ST:s dokument...
att ha två villkor efter varandra hjälper ju inte så mycket om instruktionspekaren får för sig att sättas till precis där båda testerna utförs efter varandra, eller jag kanske missförstod hur du menade
> "Det är sannolikt mer sannolikt att villkor sätts "true" av misstag."
Beror väl på vad villkor består av, är villkor = false så är det ju inte så sannolikt med ett misstag att koden är riktigt skriven är ju en förutsättning
spelar nog ingen roll hur många pinnar du sätter säg att du bara skulle ha din kod och resten är fyllt med trap instruktioner. så är nog största chansen att den skulle sättas av en software runaway att den faktiskt hoppar till första instruktionen
void SetOut(void) {
PIN = AKTIV;
}
void main(void) {
while(1) {
if(villkor == true)
{
SetOut1(); <---ett hopp hit triggar fortfarande utgången.
SetOut2();
SetOut3();
}
}
}
tror att den bästa lösningen är att skärma av är att undvika att skicka in EMC/EMI i MCUn. du kan troligen göra det säkrare men tror inte du kan nå 100% blir nog väldigt svårt.
ett av de bättre lösningarna kan nog vara att sätta en hårdvarutimer(typ 555a) externt och kräva att pinnen ska vara hög i x ms innan den riktiga utgången tänds. på så vis får du x ms på dig att detektera ett runaway. problemet är att 555an kanske också påverkas av EMC/EMI.
Men nu är det ju så att om det ska vara riktigt säkert ska man ha 3 olika processorer, de ska vara programmerat i var sitt språk till att göra samma sak och man kopplar ihop dom med ett kretslopp som väljer det output som minst 2 kommer med.
Att räkna med att ett program skenar är det samma som att säga att kompilern eller hårdvaran är trasig, alltså hittar man en annan hårdvara och kompiler.
Dessutom använder man WatchDog-funktionen och ser till att den övervakar alla loops som kan finnas.
Sedan lägger man en uppstartskod som avkänner vilken sorts reset som kom senast och var det WD som utlöste en reset kan man välja att stoppa allt och meddela att ett fel finns.
*Självklart* var det inte så jag menade och det var inte så jag skrev !
> Ett sätt är att ha två utgångar som AND'as ihop och som var för
> sig har ett if(villkor == true) villkor. Då räcker det inte med att
> komma till bara ett av SetOut1()/SetOut2() anropen.
Alltså:
if(villkor == true)
{
SetOut1();
}
if(villkor == true)
{
SetOut2();
}
Out1 och Out2 AND'ade externt.
Nu måste villkor == true oavsett vart man hoppar av misstag...
Matte: Är också lite inne på det, RC länk och liknande schmitt-trigger grind för att skapa extern tidsfördröjning. Eller använda en intern timer som har en compare-utgång kopplad till en pinne.
Att använda flera processorer är uteslutet pga kostnadnaden (stora serier).
Sodjan: ja det borde funka, förutsatt att man knyter villkor till en extern hårdvaruresurs och inte till nån variabel som sätts nån annanstans i programmet, ska fundera lite konkretare på vad jag vill att villkor ska bestå av.
Sant, man skulle yterligare kunna säkra upp det genom att
ha två oberoende villkor :
if(villkor1 == true)
{
SetOut1();
}
if(villkor2 == true)
{
SetOut2();
}
och sedan se till att inte båda kan sättas "true" av misstag.
Ännu bättre är att testa mot två värden vilket är mindre sannolikt
att de sätts slumpvis än att bara något sätts "true"...
Sodjan, tror fortfarande inte att det blir säkert, nånstans måste juh dessa variabler sättas också, även om du har 5 variabler och alla ska ha ett exakt 32bitars värde för att triggas så kan ett runaway fortfarande hoppa tills där dessa sätts. om dessa sätts på olika ställen så måste de ha något gemensamt för att veta att de ska sättas och vad hindrar att den triggas osv.
jag tror att.
1 begränsa EMI/EMC så att den aldrig flippar.
2 se till att om detta skule hända ska den hinna inse att den har gått åt skogen och lösa problemet innan något brinner upp.
I ditt fall kanske ett Lågpass filter med lågt R och stort C+ schmitt trigger med rätt stor Hysteres. beror nog lite på hur mycket åt helvete det går om det blir fel och om det enkelt går att förebygga det värsta med externa komponenter (tex skydd mot att både high-side och low-side leder samtidigt i en halv brygga).
Det kräver en del omtanke att "säkra" systemet mot störningar, att utgå ifrån att programloopen kan utföras slumpmässigt är det samma som att säga att man inte kan lita på ett programmerbart system.
Frågan är i mina ögon alldeles fel och komplett irrelevant, den rätta fråga hade varit:
"Hur säkrar man sig så gott det går att ett µC-baserat system inte störs ut".
Och DÄR kan man ge svar som faktisk är riktiga:
* Avkoppling av alla kretsar.
* Stabil matningsspänning.
* Groundplane.
* Genomtänkt dragning av ström.
* Watchdog funktion.
* Grey-out skydd med t.ex. en resetkrets om det inte finns inbyggd i µC'n.
Jag har gjort ett mycket avancerat system som finns i handeln i ett större antal exemplar, kretskortet hade bara ett EMC-fel då det testades och det var den nätdel som vi köper färdig som skulle avstöras.
Det har inte varit några enheter som har "flippat", detta sannolikt då jag har lyckats bra på de ovanstående punkter, mjukvarafel har dock funnits men ingen enhet har gjort saker som inte var programmerat in, t.ex. att ProgramCountern skulle flippa.
Lösningen med 3 olika µC kommer ifrån NASA och från Fly-By-Wire system som kräver absolut säkerhet och är alltså inte ett tänkt system men i högsta grad realitet.
Jag vill bara tillägga att jag blir lite orolig när man har behov
av att ställa dessa frågor *här* (på ett forum primärt inriktat
till hobbyister) när det gäller något som ska köras i "stora serier"...
D.v.s om jag vore beställare av jobbet...
Och jag kan bara instämma med sodjan, speciellt eftersom STM32 är en ganska "stor" processor som definitivt kan "kräva sin man" i designfasen.
Jag har av störningsskäl hållit fast i 5V processorer, man har helt enkelt mer marginal än med 3,3V (eller lägre) system MEN likaså finns det MÅNGA system som kör med låg spänning och likaväl är stabila, jag har för mig att vissa PC-kärnor har 1,1V matningsspänning så det är definitivt inte omöjligt att skapa stabila system, även med låg spänning och många bits.
Att många PC-kärnor sedan kör Windows ska man inte klandra dom för...
