Svenska ElektronikForumet

Jag saknar detaljkunskaper om denna krets.
Bara ett par allmänna tips:

Går det att köra med debugger?
Kolla om timern går kontinuerligt. Om den får klocksignaler.
Kolla i databladet om just denna timer går att koppla till DMA. Om den är rätt kopplad.

Som du ser är CubeMX inte särskilt hjälpsam vid problemlösning.
Dess hjälptexter är minimala och absolut inte självförklarande.
Den är dessutom extremt seg. Skräp med andra ord.
Men nästan det enda hjälpmedel som finns vad jag vet.

SvenW skrev: ↑15 augusti 2021, 11:30:45 Jag saknar detaljkunskaper om denna krets.

Ja, det gör jag. Det kanske är värt att lära sig om denna krets? Men orsaken varför jag inte har gjort det har med att om jag kan STM32 kretsen, den skiller sig rätt mycket jämfört med andra kretar.

Bara ett par allmänna tips:
Går det att köra med debugger?
Kolla om timern går kontinuerligt. Om den får klocksignaler.
Kolla i databladet om just denna timer går att koppla till DMA. Om den är rätt kopplad.

Det går att köra debuggern.
Men hur kan jag göra det i debauggern? Vart ska jag kolla?

Som du ser är CubeMX inte särskilt hjälpsam vid problemlösning.
Dess hjälptexter är minimala och absolut inte självförklarande.
Den är dessutom extremt seg. Skräp med andra ord.
Men nästan det enda hjälpmedel som finns vad jag vet.

Ja, kör man fast, så kör man fast. Men CubeMX har blivit riktigt bra. Jag gillar verktyget, men man blir dock inte så utbildad när man kör det.
Jag tror det är nödvändigt med att ett program likt CubeMX finns för ST. ARM processorer är inga PIC 8-bit eller enklare. Här talar vi om 32-bits processorer med avancerade enheter så som CAN, SDADC osv. Det är inte en Arduino ATMega328p från 2008 som hade knappt något.

Jag menade att det är jag (SvenW) som saknar kunskap om kretsen.
Du (DanielM) kan den säkert mycket bättre än jag

Timern bör väl snurra även om debuggern stoppar programmet.
Bara att kolla om den ändrar sig av sig själv.
Den heter väl så här:

#define __HAL_TIM_GET_COUNTER(__HANDLE__) ((__HANDLE__)->Instance->CNT)

Annars kan man komplettera med temporär kod som loggar data.

Jag använder själv CubeMX. Men just nu går den inte ens igång!
Att programmera STM-kretsar enbart utifrån databladet är nog för mycket även för mig!
Förhoppningsvis blir den bättre efter hand!

I IAR kunde man välja om timer skulle snurra eller inte så man breakat i debuggern.

SvenW skrev: ↑15 augusti 2021, 19:48:25 Jag menade att det är jag (SvenW) som saknar kunskap om kretsen.
Du (DanielM) kan den säkert mycket bättre än jag

Timern bör väl snurra även om debuggern stoppar programmet.
Bara att kolla om den ändrar sig av sig själv.
Den heter väl så här:

#define __HAL_TIM_GET_COUNTER(__HANDLE__) ((__HANDLE__)->Instance->CNT)

Annars kan man komplettera med temporär kod som loggar data.

Jag använder själv CubeMX. Men just nu går den inte ens igång!
Att programmera STM-kretsar enbart utifrån databladet är nog för mycket även för mig!
Förhoppningsvis blir den bättre efter hand!

Jag saknar också kunskap om kretsen. Det är för komplex för mig.

Det ska jag kolla upp.

Har du problem att CubeMX startar ibland och ibland verkar det som grafikproblem? Jag bytte till en nyare dator. Då fungerade det.

Att programmera STM kretsar från datablad har nog ingen tid med. Då blir man flintis. Bästa med STM är just CubeMX. Vet att sådant är framtiden.

Alla projekt jag gjort med stm32 har gjorts via datablad och exempel koder. Det har slutat med releade produkter och håret kvar.

Denna tråd visar väl på att cube inte verkar vara en effektiv väg framåt?

Hur kan det bästa vara något som inte funkar?

Men hur gör man får att börja med registerprogrammering då?
Nu frågar jag inte om en komplett introduktion från dig. Jag efterfrågar mer vad du brukar kolla på.

Vi kan ta ett exempel.
Om jag ska få en GPIO pinne att gå från 0 till 1 så tänker jag följande steg:
1. Aktivera klockan för GPIO
2. Aktivera GPIO
3. Sätt registret för GPIO pinnen till 1

Nu var detta säkert jätte enkelt. Men när det kommer till SPI, DMA, ADC osv. Ja, då börjar det bli svårt enligt mig och där vet jag inte vart man ska börja. Är analogin lika?
Alltså man aktiverar klockan först?

CubeMX finns väll av en anledning och den anledningen är väll att STM32 plattformen är för komplex?
I så fall skulle folk sluta köra ramverk om komplexiteten är inget problem?

Något som skulle fungera för mig är att använda mig utav CubeMX och läsa registerna parallellt.

Så om jag försöker lite. Låt oss säga att när jag aktiverar DMA för SDADC så vill jag få det bekräftat att DMA har verkligen aktiverats.
Så jag börjar med denna funktion. Jag vet ju att SDADC fungerar för interrupt, men inte för DMA.

Kod: Markera allt

HAL_StatusTypeDef HAL_SDADC_InjectedStart_DMA(SDADC_HandleTypeDef *hsdadc, uint32_t *pData, uint32_t Length)

Koden börjar med

Kod: Markera allt

  /* Check that DMA is not enabled for regular conversion */
  if((hsdadc->Instance->CR1 & SDADC_CR1_RDMAEN) == SDADC_CR1_RDMAEN)
  {
    status = HAL_ERROR;
  }

Då betyder det att jag måste kolla kontrollregister CR1 för SDADC. Här är SDADC_CR1_RDMAEN = (0x1UL << (17U)) dvs 0b1 + 16 nollor där efter.
Kollar man i registret så skall

Kod: Markera allt

Bit 17 RDMAEN: DMA channel enabled to read data for the regular channel
0: The DMA channel is not enabled to read regular data
1: The DMA channel is enabled to read regular data
RDMAEN must not be ‘1’ if JDMAEN=1.

Bit 16 JDMAEN: DMA channel enabled to read data for the injected channel group
0: The DMA channel is not enabled to read injected data
1: The DMA channel is enabled to read injected data
JDMAEN must not be ‘1’ if RDMAEN=1.

Alltså betyder det att om Bit 17 är 1 hos CR1, då får jag ett error. Detta är troligtvis så att CR1 är aktiverad för injected data.

Jag föreslår att om du tror HAL gör fel, skriv ut eller leta upp registrena i debugger som är relevanta och kontroller att de registrena stämmer mot referensmanuallen.

MIn erfarenhet med HAL och DMA problem är snarare att man måste göra felhantering, dvs kolla felflaggor som får DMA stanna eller göra nåt dumt så jag skulle även kolla alla flaggor som skulle kunna vara intressanta.

Ditt grundproblem är inget man kan svara på rak arm, utan det är nog bara försöka isolera funktionen och hitta var felet är. DMA och interupt kan vara lite jobbigt debugga då det "sker utanför koden".

Du som är en av dom mest kunniga inom STM32 här.
Tror du det är smart att man skriver all C kod igenom att kolla i referensmanualen? Alltså "bare metal" programmering.

Jag har aldrig varit med om ett arbete där man skriver "bare metal" kod, dvs registerprogrammering. Det har alltid varit någon typ av HAL tillgängligt.
Men oavsett om jag kör HAL eller inte, så kommer jag köra fast förr eller senare.

En nackdel med att skriva registerprogrammering är när det kommer till alla dessa stora verktyg så som RTOS, USB, CAN, SD-kort osv. Det är då jag anser att HAL, eller snarare CubeMX är ett måste.

Jag kollar lite på AVR och STM32 referensmanualer och en AVR manual kan ha t.ex. 200 sidor, medan en STM32...liten processor har inte under 1000 sidor. Dessutom verkar AVR:en enklare att programmera då det finns färdiga exempel i referensmanualen.

Så jag funderar på att använda CubeMX, men ändå lära mig läsa referensmanualen. Jag kommer alltså inte att kunna programmera "bare metal" kod med andra ord, eller förstå hur en ARM Cortex processor är uppbyggd.

Jag tycker att resonemangen går åt fel håll här.
Det är med 99% sannolikt inget fel på koden som Cube MX generera i det här fallet, utan mer en brist på förståelse kring vad som genereras och vad man måste komplettera med själv.

Börjar du blanda in andra IDE'er eller försöka konfigurera dessa kringkomponenter manuellt i registret kommer du aldrig komma vidare utan att hela tiden fundera på om du fått med allt och gjort det rätt.

Jag har själv gjort samma resa med USB där man får för sig att "det här är ju lätt, koden automatgenereras" och sedan funkar det inte och man börjar på riktigt sätta sig in i det.
Man inser då snabbt att det finns logiska begränsningar i vad som GÅR att automatgenerera. I mitt fall med USB, så visste givetvis inte Cube MX om mitt "USB HID Device" skulle vara en mus, tagentbord eller composite device och då genereras givetvis inte någon Device descriptor.
Resultatet var att halva USB initieringen fanns och detaljerna om vad man pluggat in saknas varför Windows inte kan få igång någon driver.

Det är lätt att säga "Cube MX funkar inte" i ett sådant fall men då har man inte fattat vad Cube MX är till för.
Det är i grunden ett verktyg för att initiera dina pheriphals med nödvändiga parametrar.
Det är inget verktyg som bygger ditt program och det är framförallt inte synskt.
Jag vill nog gå så långt att jag påstår att det är så pass bra att generera dessa initieringar så att man lätt luras att tro att man får mer än vad man får.
Vissa callbacks genereras men är tomma som exempel, och då får man ju heller inget fel i kompileringen som kan leda en till förståelse att här måste man skriva något eget.

Jag får känslan av att du saknar en del grundkunskap kring periferienheterna i processorn och hur dom skall användas (eller har missuppfattat).
Min bild just nu är:
3st SARDAC (vilka i sig har upp till 9 kanaler) som du "triggar" (dina ord) genom två timers (12 & 13) och sedan två timers till (16 & 17) som du använder som "input capture" och där 12 och 13 skall "spara sitt värde" i en cirkulär buffer (varför och vad har detta värde med avläsningen att göra).
Och några värden ur den här (ursäkta uttrycket) soppan skall i slutändan ner på SD kort. Avläsningen skall ske i injected mode "för bättre kontroll" (dina ord).

Jag skulle vilja att du beskrev vad du hoppas skall hända i någon form av periodiserat flöde.

Jag har någonstans i bakhuvudet något att en av DaC måste agera master och trigga de andra om du skall köra DMA (om det hade med att dom satt på samma DMA kanal eller vad det nu var) ta det dock med en nypa salt för det kan vara en specifik modell av MCU som detta gäller för.

Input capture är till för att trigga en räknare genom extern påverkan (pinne som går hög typ) vilket i sin tur vid uppfyllt villkor (roll over etc.) skapar en händelse i syfte att exempelvis räkna frekvens/pulslängd eller läsa av ett värde på en motor på ett exakt läge av rotation etc. etc.
Här kommer exempelvis injected mode in i bilden då den gör override på alla andra AD operationer, för att man "omedelbart" vill använda dessa värden och kanske behöver läsa av vissa specifika kanaler i en serie etc.
Man kan givetvis använda en timmer för att periodiserat trigga en händelse på tid (vilket jag tolkade att du var ute efter) med men då använder man väl "output compare".

Kan du inte bara börja med att lösa problemet. Läs av dina ADC (skit i injected mode) var 20'e MS baserat på en timer.
När du fått detta att funka så kan du börja testa med DMA (kanske en i taget).
Klä på med injected mode (om du nu behöver det, vilket jag är tveksam till).
Du har verkligen kastat dig över hela kakan på en gång här.

Jag är otroligt nyfiken på konfigurationen för dina fyra timers. Men posta dom inte för jag har fan inte tid och kommer inte kunna hålla mig från att kolla på det

Generellt sett så förklarar inte databladet HUR du skall använda olika periferienheter i din MCU, utan beskriver enbart hur den kan konfigureras.
Därför är det meningslöst att plöja 1500 sidor, för svaret finns inte i dessa. För STM så gäller precis som för många andra tillverkare att denna kunskap finn i Application notes.
Dessa är mer korta och fokuserar mer på användandet med ibland exempel kod och use cases.

Börja med att läsa AN3116 och därefter AN4195 (tagna ur huvudet, det finns säkert fler som är aktuella).
Jag är säker på att du kommer komma underfund med att du missuppfattat något.

ToPNoTCH skrev: ↑16 augusti 2021, 20:26:36 Jag tycker att resonemangen går åt fel håll här.
Det är med 99% sannolikt inget fel på koden som Cube MX generera i det här fallet, utan mer en brist på förståelse kring vad som genereras och vad man måste komplettera med själv.

Mycket troligt. Men med tanke på att jag har fått SDADC att fungera med interrupt och jag bara ersatte interrupt med DMA, så borde det faktiskt också fungera direkt. Att ersätta interrupt med DMA är inte många knapptryck med andra ord.

Jag har själv gjort samma resa med USB där man får för sig att "det här är ju lätt, koden automatgenereras" och sedan funkar det inte och man börjar på riktigt sätta sig in i det.
Man inser då snabbt att det finns logiska begränsningar i vad som GÅR att automatgenerera. I mitt fall med USB, så visste givetvis inte Cube MX om mitt "USB HID Device" skulle vara en mus, tagentbord eller composite device och då genereras givetvis inte någon Device descriptor.
Resultatet var att halva USB initieringen fanns och detaljerna om vad man pluggat in saknas varför Windows inte kan få igång någon driver.

Jag har inte haft något problem med USB hos STM32. Jag tycker det fungerar bra. Jag har möjligheten att kunna skicka bytes fram och tillbaka.

Det är lätt att säga "Cube MX funkar inte" i ett sådant fall men då har man inte fattat vad Cube MX är till för.
Det är i grunden ett verktyg för att initiera dina pheriphals med nödvändiga parametrar.
Det är inget verktyg som bygger ditt program och det är framförallt inte synskt.
Jag vill nog gå så långt att jag påstår att det är så pass bra att generera dessa initieringar så att man lätt luras att tro att man får mer än vad man får.
Vissa callbacks genereras men är tomma som exempel, och då får man ju heller inget fel i kompileringen som kan leda en till förståelse att här måste man skriva något eget.

Jag vet vad CubeMX är och jag använder det hela tiden. Men det är just när jag kommer till DMA som det strular till för mig.

Jag får känslan av att du saknar en del grundkunskap kring periferienheterna i processorn och hur dom skall användas (eller har missuppfattat).
Min bild just nu är:
3st SARDAC (vilka i sig har upp till 9 kanaler) som du "triggar" (dina ord) genom två timers (12 & 13) och sedan två timers till (16 & 17) som du använder som "input capture" och där 12 och 13 skall "spara sitt värde" i en cirkulär buffer (varför och vad har detta värde med avläsningen att göra).
Och några värden ur den här (ursäkta uttrycket) soppan skall i slutändan ner på SD kort. Avläsningen skall ske i injected mode "för bättre kontroll" (dina ord).

Jag saknar grundförståelse hur processorn fungerar och jag vet inte heller vart man ska börja. Alla processorer är olika.
3 stycken SDADC där SDADC1 har 9 kanaler. SDADC2 har 3 kanaler och SDADC har 5 differentialskanaler.
Räknare 16 och 17 använder jag inte till SDADC, bara till IC. Ja. Räknare 12 och 13 ser till så DMA sparar i en cirkulär buffer.

Jag har inga problem med att spara på SD-kort. Den delen har jag redan gjort. Jag har skapat fått följande att fungera:
* GPIO
* DAC
* SD-kort
* SPI
* USB + interrupt
* PWM
* CAN + interrupt
* 1 Input Capture + DMA
* SDADC + interrupt
* RTC + alarm

Men andra Input Capture + DMA fungerar inte. Den verkar ha en icke-cirkulär buffer. Och att SDADC + DMA fungerar inte.

Jag skulle vilja att du beskrev vad du hoppas skall hända i någon form av periodiserat flöde.

Om jag börjar med IC och SDADC, vilket jag har problem med så hoppas jag att IC1, som drivs av TIM16, ska bete sig exakt som IC0 som drivs av TIM17. IC0 (Input Capture 0) fungerar med DMA, men det gör inte IC1 med DMA. Koden är exakt identisk, bara annan typ av räknare.

För SDADC så vill jag spara ned värderna hos arrayerna via DMA. Men arrayerna är har bara 0 som index.

Jag har någonstans i bakhuvudet något att en av DaC måste agera master och trigga de andra om du skall köra DMA (om det hade med att dom satt på samma DMA kanal eller vad det nu var) ta det dock med en nypa salt för det kan vara en specifik modell av MCU som detta gäller för.

Alla har olika DMA kanaler. Jag kan inte välja samma DMA kanal för olika SDADC.

Input capture är till för att trigga en räknare genom extern påverkan (pinne som går hög typ) vilket i sin tur vid uppfyllt villkor (roll over etc.) skapar en händelse i syfte att exempelvis räkna frekvens/pulslängd eller läsa av ett värde på en motor på ett exakt läge av rotation etc. etc.
Här kommer exempelvis injected mode in i bilden då den gör override på alla andra AD operationer, för att man "omedelbart" vill använda dessa värden och kanske behöver läsa av vissa specifika kanaler i en serie etc.
Man kan givetvis använda en timmer för att periodiserat trigga en händelse på tid (vilket jag tolkade att du var ute efter) med men då använder man väl "output compare".

Jag vet vad Input Capture är. Jag sparar "Counter Value" i en cirkulär buffer och Counter Value räknas från 0 till 0xFFFF på 6.5535 sekunder. Vilket är en uppdateringsfrekvens hos räknaren med 10 kHz. Endast Input Capture 0 fungerar för mig.

Kan du inte bara börja med att lösa problemet. Läs av dina ADC (skit i injected mode) var 20'e MS baserat på en timer.
När du fått detta att funka så kan du börja testa med DMA (kanske en i taget).
Klä på med injected mode (om du nu behöver det, vilket jag är tveksam till).
Du har verkligen kastat dig över hela kakan på en gång här.

Du menar att jag använder en interrupt som triggar varje 20:e millisekund? Jo, det kan jag och jag har redan fått SDADC att fungera med interrupt. Men med DMA fungerar det icke!

Jag är otroligt nyfiken på konfigurationen för dina fyra timers. Men posta dom inte för jag har fan inte tid och kommer inte kunna hålla mig från att kolla på det

Dom har jag redan postat i post #1.

Generellt sett så förklarar inte databladet HUR du skall använda olika periferienheter i din MCU, utan beskriver enbart hur den kan konfigureras.
Därför är det meningslöst att plöja 1500 sidor, för svaret finns inte i dessa. För STM så gäller precis som för många andra tillverkare att denna kunskap finn i Application notes.
Dessa är mer korta och fokuserar mer på användandet med ibland exempel kod och use cases.

STM har faktiskt väldigt många fina exempel också som dom erbjuder med några korta förklaringar. Så fick jag CAN att fungera med mitt Open Source SAE J1939 bibliotek. Väldigt uppskattat.

Börja med att läsa AN3116 och därefter AN4195 (tagna ur huvudet, det finns säkert fler som är aktuella).
Jag är säker på att du kommer komma underfund med att du missuppfattat något.

Du menar inte denna?
https://www.st.com/resource/en/applicat ... ronics.pdf

För jag kör alltså 16-bit ADC på min STM32, inte 12-bit ADC.

Du som är en av dom mest kunniga inom STM32 här.
Tror du det är smart att man skriver all C kod igenom att kolla i referensmanualen? Alltså "bare metal" programmering.

Jag har aldrig varit med om ett arbete där man skriver "bare metal" kod, dvs registerprogrammering. Det har alltid varit någon typ av HAL tillgängligt.
Men oavsett om jag kör HAL eller inte, så kommer jag köra fast förr eller senare.

"Registerprogrammering" som du kallar det funkar bra på 8 bitas processor ex PIC där man har väldigt få och simpla peripherals.

På STM32 är peripherals betydligt mer komplexa och har många register och beroenden. Den största STM32 jag jobbat med (STMH7) har referensmanual på 3500 sidor.
Jag har jobbat med STs processorer i ca 13 år och alltid använt plattformslager från ST som grund ( standard periheral lib och sedan HAL/LL).

Sen klagar många på att HAL har buggar, vissa saker saknas, tar stor plats osv. Och ja visst de är inte perfekta: har själv bugfixat, samt optimerat vissa delar (för minska flash), tagit registervärden från och skrivit direkt istället men det går fortfarande snabbare än skriva egna plattformsbibliotek från grunden.

Sen brukar man behöva gå till referensmanualen vid felsökning eller mer komplexa saker.
Och som du själv säger, HAL är ett sätt att snabbt komma igång, men du kommer likväl alltid behöva felsöka när det inte fungerar som det ska men det blir ju samma sak med "registerprogrammering". Fördelen är att du slipper grotta in i register på de sakerna som fungerar som det ska.

Kan det här vara en ledtråd.

DMA controller
The hardware requests from the peripherals (TIMx, ADC1, DACx, SPIx, I2Cx, and USARTx)
are simply logically ORed before entering the DMA. This means that on one channel, only
one request must be enabled at a time

Kolla databladet på sid 167,168,169.

Du kanske skall prova grejorna separat så ser du om du har konflikter i användandet av DMA kanaler (jag får det till att du har det).

ToPNoTCH skrev: ↑17 augusti 2021, 13:07:43 Kan det här vara en ledtråd.

DMA controller
The hardware requests from the peripherals (TIMx, ADC1, DACx, SPIx, I2Cx, and USARTx)
are simply logically ORed before entering the DMA. This means that on one channel, only
one request must be enabled at a time
Kolla databladet på sid 167,168,169.

Du kanske skall prova grejorna separat så ser du om du har konflikter i användandet av DMA kanaler (jag får det till att du har det).

Jag har gjort flera test. Här är några resultar:

Om jag tar bort räknaren igenom kommentera bort den via // så får jag BARA 0:or på min DMA buffer.
Om jag har kvar räknaren och kör som vanligt nu. Då får jag ett litet värde t.ex. 120 till 230 i första indexet i DMA bufferen. Alltså betyder det att DMA fungerar.
Om jag INTE kör med External Trigger, utan med Software Trigger, då får jag samma resultat som jag har External Trigger med räknare, dvs bara ETT värde på index[0] i DMA buffern.

Så slutsatsen kan man säga att någonting händer i alla fall.
Antingen så är det räknaren som ej aktiverar en DMA förfrågan, eller så är det som du säger, bara 1 kanal måste vara aktiverad åt gången.
Jag ska testa ändra lite prioriteter, jag har dom alla på LOW. Uppdatering: Ingen skillnad.

Jag testade bara att köra 1 kanal från DMA2 med SDADC1. Resultatet blev det samma.

Kod: Markera allt

if (HAL_SDADC_CalibrationStart(hsdadc1, SDADC_CALIBRATION_SEQ_1) != HAL_OK)
		Error_Handler();
if (HAL_SDADC_PollForCalibEvent(hsdadc1, HAL_MAX_DELAY) != HAL_OK)
		Error_Handler();
if(HAL_SDADC_InjectedStart_DMA(hsdadc1, (uint32_t*)SDADC1_Single, 9) != HAL_OK)
		Error_Handler();

Första index i volatile static int16_t SDADC1_Single[9]; är alltid runt 205-220. Sedan händer det inget mer. Det get samma sak utan volatile.
Jag har testat med extern trigger och software trigger. Detta ger också samma resultat.

Men det kanske får bli så att man kan inte köra flera DMA snabbt efter varandra, för att det krockar? Jag kanske får köra Interrupt med en uppdateringsperiod på några millisekunder?

Test2:
Jag testade att köra bara med 1 DMA. Alltså jag tog bort alla andra DMA och aktiverade ingen DMA. Bara kommenterade bort allt och tog bort allt via CubeMX.
Men ändå så vid Input Capture 1 så körs verkar DMA bara anropas 1 gång med den cirkulära buffern, medan för Input Capture 0 så anropas DMA hela tiden med den cirkulära buffern.

Så jag misstänker att det är något problem med DMA requests. Alltså en bug.
För nu verkar det som att Input Capture 0 bara kör 1 DMA request efter att jag har tagit bort DMA för TIM17 (Input Capture 0) och sedan satt tillbaka det.

Circular Mode och Normal Mode ger EXAKT samma resultat för input capture. Så jag antar det sker samma sak med SDADC också?

Misstänkt bugg:
Jag tror att orsaken varför Cirular Mode och Normal Mode ger samma sak har med att DMA förfrågan skickas bara 1 gång.
Bilden visar en array där första elementet för SDADC1 innehåller bara ett värde. Resterande värden är alltså 0. Alltså betyder det att DMA har helt enkelt gett upp och gått och lagt sig?

Skärmklipp.PNG

För Input Capture så är det exakt samma sak.

Skärmklipp.PNG

Rick81 skrev: ↑17 augusti 2021, 11:37:00
Du som är en av dom mest kunniga inom STM32 här.
Tror du det är smart att man skriver all C kod igenom att kolla i referensmanualen? Alltså "bare metal" programmering.

Jag har aldrig varit med om ett arbete där man skriver "bare metal" kod, dvs registerprogrammering. Det har alltid varit någon typ av HAL tillgängligt.
Men oavsett om jag kör HAL eller inte, så kommer jag köra fast förr eller senare.
"Registerprogrammering" som du kallar det funkar bra på 8 bitas processor ex PIC där man har väldigt få och simpla peripherals.

På STM32 är peripherals betydligt mer komplexa och har många register och beroenden. Den största STM32 jag jobbat med (STMH7) har referensmanual på 3500 sidor.
Jag har jobbat med STs processorer i ca 13 år och alltid använt plattformslager från ST som grund ( standard periheral lib och sedan HAL/LL).

Sen klagar många på att HAL har buggar, vissa saker saknas, tar stor plats osv. Och ja visst de är inte perfekta: har själv bugfixat, samt optimerat vissa delar (för minska flash), tagit registervärden från och skrivit direkt istället men det går fortfarande snabbare än skriva egna plattformsbibliotek från grunden.

Sen brukar man behöva gå till referensmanualen vid felsökning eller mer komplexa saker.
Och som du själv säger, HAL är ett sätt att snabbt komma igång, men du kommer likväl alltid behöva felsöka när det inte fungerar som det ska men det blir ju samma sak med "registerprogrammering". Fördelen är att du slipper grotta in i register på de sakerna som fungerar som det ska.

Kul! Du verkar kunnig.
Av ren nyfikenhet, vilken CPU-märke är vanligast bland företagen? Gissar på att det är PIC eller AVR, bara för att dom har hängt med länge. Ser du mycket STM ute på industrin?
Antar att dom alla är lättarbetade?

Nu har jag löst problemet med Input Capture. Ja, det är en bug i CubeMX.

Bara flytta autogenererade MX_DMA_Init();. Då fungerar Input Capture.

Kod: Markera allt

 /* Initialize all configured peripherals */
  MX_GPIO_Init();
  MX_DMA_Init(); <--- Till här
  MX_DAC1_Init();
  MX_DAC2_Init();
  MX_RTC_Init();
  MX_SPI2_Init();
  MX_TIM2_Init();
  MX_TIM5_Init();
  MX_SPI1_Init();
  MX_TIM4_Init();
  MX_SDADC1_Init();
  MX_SDADC2_Init();
  MX_SDADC3_Init();
  MX_CAN_Init();
  MX_USART1_UART_Init();
  MX_TIM6_Init();
  MX_TIM12_Init();
  MX_TIM13_Init();
  MX_TIM16_Init();
  MX_USB_DEVICE_Init();
  MX_FATFS_Init();
  MX_TIM17_Init();
  <--- Flytta från här
  MX_TIM19_Init();
  /* USER CODE BEGIN 2 */

För SDADC så har det blivit bättre. Nu får den värdern i bufferen. Men på något sätt så verkar det som att det är Normal Mode och inte Circular Mode som gäller trots att jag har valt Circular Mode. Jag får alltså bara samma värden hela tiden.

Skärmklipp.PNG

Uppdatering:
Efter att testa ta bort nyckelordet volatile så fungerar SDADC. Något felindexerat dock. Men det gör inget.

Skärmklipp.PNG

Svenska ElektronikForumet

Någon som förstår det där med DMA i STM32?

Re: Någon som förstår det där med DMA i STM32?

Re: Någon som förstår det där med DMA i STM32?

Re: Någon som förstår det där med DMA i STM32?

Re: Någon som förstår det där med DMA i STM32?

Re: Någon som förstår det där med DMA i STM32?

Re: Någon som förstår det där med DMA i STM32?

Re: Någon som förstår det där med DMA i STM32?

Re: Någon som förstår det där med DMA i STM32?

Re: Någon som förstår det där med DMA i STM32?

Re: Någon som förstår det där med DMA i STM32?

Re: Någon som förstår det där med DMA i STM32?

Re: Någon som förstår det där med DMA i STM32?

Re: Någon som förstår det där med DMA i STM32?

Re: Någon som förstår det där med DMA i STM32?

Re: Någon som förstår det där med DMA i STM32?