Svenska ElektronikForumet

Jepp, har suttit hela dagen med lite SPI problem,

saken är att jag kör två separata kort med en STM32 på varje, ena agerar master och den andra slav.

Från början körde jag ren överföring utan någon inblandning av ChipSelect. detta funka utmärkt.

Men så fort det är något som stör, "tex när jag slår på min fina Weller lödstation" så blir det en ordentlig störning på MOSI och SCK signalen
"20cm kabel som SPI signalen går mellan korten med".

Och efter störningen inträffat så tolkar slaven allt efter störningen som skräp, den hittar alltså inte tillbaka till synkningen
så då vart det ett måste med ChipSelect hantering, och lite felhantering.

Som kanske några vet så har STM32 en fulvariant av CS funktionalitet på Master sidan, den funkar helt enkelt inte riktigt som den borde.
den är låg hela tiden ist för att gå låg när data skickas.

Slaven använder den inbyggda NSS "ChipSelect" funktionen, vilket funkar fint.
Men på Master sidan så måste jag manuellt höja och sänka CS pinnen.

Nu till det som blev en udda lösning.

i huvud loopen Interrupt rutinen
Kort förklarat så Deaktiverar jag CS precis innan jag akteverar SPI TXE interrupten och sedan matar in data i SPI bufferten.
då SPI hanterar datan så triggas Interrupten och där så aktiverar jag CS
och därefter deaktiverar jag SPI Interrupten så att den inte triggas fören nästa gång jag måste sända.

detta är resultatet, gula SCK och blå är CS
Det konstiga "vilket jag tycker " är att SPI TXE Interrupten triggas innan SCK börjar mata ut data.



har nu länge försökt att hitta en lösning på hur man variferar när all data är skickad så man bara håller CS låg under själva data överföringen.

Någon som har någon koll ??

Utan att grotta mig ner exact i orsaken till dina problem, titta på att använda DMA'n.

Tackar för tipset: Tänkte grotta ner mig med DMA senare, Så tanken finns absolut.
Är inte helt hundra med DMA förståelsen än så länge så därför får det vänta.

Nu är det bara att få all att lira snabbt så jag kan påbörja nästa fas i projektet.

lizerdboy skrev:Men så fort det är något som stör, "tex när jag slår på min fina Weller lödstation" så blir det en ordentlig störning på MOSI och SCK signalen
"20cm kabel som SPI signalen går mellan korten med".

Det låter som att du borde börja med att fixa signalintegritetsproblemen i din design

lizerdboy skrev:Som kanske några vet så har STM32 en fulvariant av CS funktionalitet på Master sidan, den funkar helt enkelt inte riktigt som den borde.
den är låg hela tiden ist för att gå låg när data skickas.

Nja, innan man hävdar att det är en fulvariant så bör man reflektera över hur CS brukar användas på SPI. Många kretsar använder den inte bara för byte-alignment utan även för "ram-alignment" där flera bytes kommer i följd utan att CS inaktiveras. SPI-periferienheten kan inte ha koll på hur detta ska göras utan det måste vara mjukvarustyrt. Att SPI-mastern kan styra CS och då aktiverar den betyder (enligt STM32 Reference Manual) bara att den säger "jag är master just nu" och är tänkt för multi-master-system.

lizerdboy skrev:Det konstiga "vilket jag tycker " är att SPI TXE Interrupten triggas innan SCK börjar mata ut data.

Det är inte särskilt konstigt. Du måste ju ha tid att lassa in nästa byte i SPI-periferienheten innan den första byten är skickad för att inte tappa prestanda. Alternativet är att ta en paus efter att byten har skickats för att reagera på interruptet och komma fram till om ytterligare en byte ska skickas. Interruptet betyder bara att det finns plats i TX-bufferten (se figur 236 i STM32 Reference Manual [RM0008]).

Eftersom SPI bygger på att man skickar och tar emot samtidigt bör du lämpligtvis gå på SPI RXNE-interruptet som säger att något mottaget. Det är ju faktiskt samma sak som att du har skickat klart!

Man Tackar danwi "vilket jag menar"

Ang: signalintegritetsproblemen
Detta är jag fullt medveten om, denna är helt och hållet en test version.
Jag har medvetet låtit bli att tänka på detta för att se hur känsligt systemet är och även intrducera störningar för att se hur man kan lösa detta på andra sätt, tex mjukvara.
När jag har den erfarenheten "vilket jag inte har än" så har jag bättre koll på hur mycket jag måste tänka om i designen för att möta behovet av skydd.
Vet inte om det är den bästa vägen att gå, men i min mening så tycker jag om att testa innan för att få ett hum på vart dom svaga länkarna är.

Ang: fulvariant av CS på Master sidan.
Detta är ett dokumenterat problem att NSS inte uppför sig på ett normalt "CS" sätt. visst det kan vara så att ST ville göra så, men det skapar problem.
Men jag har förstått nu att man inte kan se NSS som CS, men det är konstigt att dom har valt att ta bort den funktionaliteten då CS används för byte/ram-alignment

Ang: SPI TXE Interrupten
När jag kollade när interrupten hände tidsmässigt och läste på mig lite mer så förstår jag varför. dock saknar jag möjligheten att kunna läsa av när all data är skickad.
Vilket gör att jag inte kan återställa min manuellt satta CS efter datan är skickad.

Triggas inte RXNE-interruptet mitt i om man skickar 4 st 16 ord, vilket jag gör nu.
När jag tittar med oscilloskop på signalen så är data överföringen konstant, men RXNE triggas efter varje inkommet ord.
eller har jag het fel ?

Har nu fått till duplex med felkorrigering och att den inte tappar synkroniseringen efter störningar.
så nu är det I2C BitBang rutin för ett externt Eeprom minne som ska skapas =)

Detta är ett dokumenterat problem att NSS inte uppför sig på ett normalt "CS" sätt.

Det är inte alls något "problem".
NSS uppför sig som på alla andra processorer. danwi har redan beskrivit varför.
NSS (när den är konfigurerat som utgång) är INTE ett vanligt CS signal, utan är låg under hela transmissionen. Transmissionens slut vet endast du.
Eller, som jag föreslog - DMA'n.


Edit: förtydligande NSS som utgång.

Angående signalintegriteten så kunde jag bara inte låta bli att påpeka det

Du kommer få ett RXNE-interrupt för varje 8-bit/16-bits ord som överförs (läs "som tas emot"). Det är ju egentligen till för att din mjukvara ska kunna ta hand om det inkomna ordet innan det blir överskrivet av nästa. Precis som för TX-riktningen finns en buffert på endast ett ord.

Jag ska korrigera mig själv lite här....
DMA'n på STM'en ger inte automatiskt handtering av NSS, som den gör på en del andra ARM processorer.
Däremot ger den ju ett interrupt när allt data är överfört och man kan då titta på BSY och se när man kan dra upp NSS pinnen.
Se fig. 218, sidan 608 i ref-manual.

Får korrigera mig själv ang, dokumenterat problem ang NSS
det är mer väl omtalat problem.

Angående signalintegriteten: Jag medger att jag inte är den bästa på att skapa en lösning som bäst lämpad i en miljö med mycket störningar.
Men jag försöker skapa mig en erfarenhet utifrån att testa olika lösningar.

såg en bra kommentar: ”There are two kinds of designers….those that have signal integrity problems…. and those that will.”
just nu stämmer det senare in, men jag försöker skaffa mig lite erfarenhet inom ämnet iaf

Om någon har tips på litteratur eller annan info i ämnet får gärna dela med sig med den förslag/info.

såg en bra kommentar: ”There are two kinds of designers….those that have signal integrity problems…. and those that will.”

Som vi säger på flygfältet - "There are two kind of pilots... those who have forgotten to lower the landing gear... and those who haven't. Yet."

Altid kul att ha något att se fram emot.