Smazat příspěvek

 Chystáte se smazat zprávu (se všemi případnými odpověďmi) z kategorie Hlavní diskuze:


16.06.2020 (08:53:23)
deny hoch obalka :
Dobrý den,
Řekl jsem si, že zkusím nové STM32G0, proto jsem nasadil nový procesor STM32G030F6 (TSSOP20) do jednoho z mých projektů. V projektu potřebuji komunikovat po SPI s dvěma SPI-Slave čipy - procesor je v režimu Master. I když to nebylo nutno, využil jsem obě SPI, které čip STM32G0 nabízí.
Jedno SPI používám pro komunikaci s 16 bitovým slovem a komunikace funguje tak jak má - přenos, přerušení, prostě vše v pořádku.
Problém nastává při použití druhého SPI, které používám pouze s 8 bitovým slovem (1 byte). Data odešlu v pořádku, do Slave také dorazí v pořádku, hodiny odpovídají skutečnosti - vše měřeno osciloskopem. Data ovšem nepřijmu - tedy přijmu, ale v DR registru jsou nějak podivně rozsypaný - první byte ignorován, druhý byte je kombinace prvního a druhého a třetí je v pořádku. RXNE vlajka se nenahazuje a negeneruje se ani přerušení navázané na RXNE. Slave čip data posílá v pořádku - opět kontrolováno osciloskopem.

Zde je funkce, kterou používám pro příjem :
while(LL_SPI_IsActiveFlag_TXE(SPI1) == 0); // pockej na prázdný TX registr
LL_SPI_TransmitData8(SPI1, 0xff); // odesli tmp data (jen pro ctení)
while(LL_SPI_IsActiveFlag_RXNE(SPI1) == 0); // pockej na príjem dat
return LL_SPI_ReceiveData8(SPI1); // vycti data a vrat
Program se ovšem zasekne na čekání na RXNE vlajku - ta nepřijde.

Funkce inicializace SPI je zde :
spi.BaudRate = LL_SPI_BAUDRATEPRESCALER_DIV256;
spi.BitOrder = LL_SPI_MSB_FIRST;
spi.ClockPhase = LL_SPI_PHASE_1EDGE;
spi.ClockPolarity = LL_SPI_POLARITY_LOW;
spi.CRCCalculation = LL_SPI_CRCCALCULATION_DISABLE;
spi.CRCPoly = 0;
spi.DataWidth = LL_SPI_DATAWIDTH_8BIT;
spi.Mode = LL_SPI_MODE_MASTER;
spi.NSS = LL_SPI_NSS_SOFT;
spi.TransferDirection = LL_SPI_FULL_DUPLEX;
if(LL_SPI_Init(SPI1, &spi) == ERROR)
return ERR_INIT_SPI1;

//LL_SPI_EnableDMAReq_RX(SPI1);
//LL_SPI_SetDMAParity_RX(SPI1, LL_SPI_DMA_PARITY_ODD);
LL_SPI_SetRxFIFOThreshold(SPI1, LL_SPI_RX_FIFO_QUARTER_FULL_FULL);

LL_SPI_Enable(SPI1); // zapnutí SPI 1

Hodiny do SPI zapínám a před inicializací SPI ještě zresetuji. DMA se nyní nevyužívá, proto je zakomentované.

Chtěl bych Vás poprosit o radu, co dělám špatně, neboť se s tím peru už cca týden a na nic moc jsem nepřišel **21
Děkuji za každou radu.
16.06.2020 (17:35:26)
VroutekB:
Jako bývalý profesionální honič bugů na STM32 říkám: A co si pro nalezení chyby udělal sám? Co takle votevřít bagr debagr, vedle reference manuál a podívat se, co říkají svaté registry?
16.06.2020 (19:59:45)
deny hoch obalka :
Děkuji, Vroutku. Na tvůj příchod jsem netrpělivě čekal **01 (Nemyslím, nijak ironicky, opravdu jsem rád, že mi pomůžeš.)

Registry jsem samozřejmě s referenčním datasheetem porovnával. SPI je nastaveno správně - výběr bitů, baudrate předdělička atd. Při vysílání také stav registrů odpovídá představě - nahodí se BSY bit, spadne TXE bit (po zapsání dat do DR), začne přenos. Po dokončení přenosu se shodí BSY bit, nahodí TXE a přenos je dokončen. Hodiny tikají, data z pinu MOSI lezou takové jaké mají. Vše kontrolováno osciloskopem.
Při přijmu nejsou zaznamenány příchozí data. Kontrolován SS management a tam to také vypadá v pořádku.

Pokud by jsi byl ochoten, zašlu všechny stavy registrů, aby to viděli další pár očí. Třebas přehlížím jen nějakou triviální záležitost a oprava bude otázkou pár minut.
Děkuji.
16.06.2020 (21:41:40)
VroutekB:
Zkontroluj si následující:
Configure the FRXTH bit. The RXFIFO threshold must be aligned to the read access size for the SPIx_DR register.
Jinak viz 27.5.7 v RM, ale to víš, Zkontroluj to podle toho, že to odpovídá. Víc toho na dálku takle neodhadnu a že číst registry umíš ti věřím, to nemusíš posílat :)
16.06.2020 (21:44:21)
Arambajk:
A ten fifo threshold to opravdu nastaví správně?
RXNE se nenahodí nikdy anebo až v průběhu následujícího vysílání? Pokud jo, pak tedy znovu zkontrolovat polaritu a fázi. Případně jestli slave stihne od NSS připravit první hranu včas apod.
17.06.2020 (18:48:42)
deny hoch obalka :
Děkuji za rady.
Ano, ten threshold vypadá nastavený správně - je nahozený bit FRXTH v registru CR2. Vlajka RXNE nikdy nepřijde.

Slave čip vždy odpovídá na každý byte "pořadovým číslem" přijatého bytu - tj. na první byte mi odpoví 0x01, na druhý odpoví 0x02 a na třetí 0x03 (zprávy mají většinou 3 byte).

Zde je snímek nastavení SPI :
https://imgup.cz/images/2020/06/17/G0_SPI_RXNE.png
18.06.2020 (08:53:35)
Pavel_P:
Takový, možná blbý, dotaz, když se ty flagy nikdy z nějakého důvodu, nenastaví, to tam zůstane v cyklu napořád ?
18.06.2020 (09:02:38)
deny hoch obalka :
Ano, program zůstane zaseklý na kroku "while(LL_SPI_IsActiveFlag_RXNE(SPI1) == 0);".
18.06.2020 (16:10:47)
Arambajk:
Tak tam místo while dej ledku a koukej po kolitátém odeslaném byte ten flag nahodí, někdy ho nahodit musí.
18.06.2020 (17:35:38)
deny hoch obalka :
Děkuji, Arambajku.
Ani po 20 byte odeslaných se RXNE vlajka nenahodila - LEDka nerozsvítila.
18.06.2020 (17:42:53)
VroutekB:
Eště mě napadá: Zkus nahodit SSOE bit v CR2, co to udělá.

PS: A neshazuje ti ten RXNE flag tak náhodou debilně spravený debuggér, kterej vyčítáním DR registru ti kurví ten RXNE flag?
18.06.2020 (19:49:42)
deny hoch obalka :
Vroutku, děkuji.
Bohužel ani to nepomohlo. Příznaky jsou stále stejné **21
Bohužel už se tu s tím peru bezmála 10 dní a na nic moc jsem nepřišel, takže jsem vzal do ruky páječku a procesor šel ven. Připájel jsem tam jiný kus (ze stejné zásilky), nahrál původní nezměněný program (ani jsem nekompiloval, vzal jsem pouze .hex a nahrál) a ejhle, ono to funguje ! **06
Takže asi nějaká kusová chyba - buď přímo periférie SPI nebo ARM jádra. Procesory byly kupovány na webu TME.cz, takže by se teoreticky nemělo jednat o nějaké náhražky, i když člověk v poslední době sám neví.

Každopádně Vám všem zúčastněným děkuji za pomoc **01
18.06.2020 (19:50:52)
deny hoch obalka :
Mimochodem, funguje to i s debugerem, i když krokuji program. Vlajka je nahozená, dokud nepřečtu DR registr.
18.06.2020 (19:54:12)
VroutekB:
Debagr by na to vliv mít neměl, jen řikám pro jistotu. Pač si matně pamatuju, že snad u jednoho konkrétního procáka s tímhle přesně problém byl, ale tušim snad u jiný periférie? Nepamatuju přesně, boužel. Už sem nějak vyšel ze cviku. **02
19.06.2020 (21:04:35)
RayeR (web) :
To je hrozny, jak se tomu HW da verit cimdal min, vzdy sem byl veden k tomu hledat nap[red chybu mezi zidli a klavesnici, ale kdyz misto 10 dni badani vyresi problem prepajeni procaku za 5 minut, tak tuto metodu asi netreba zatracovat :)
Je teda divny, ze to je chyba nakych strev uvnitr SPI periferky, kdyby to jako spatne prijimalo/vysilalo, tak bych treba rekl, ze se ESDeckem prismahnul naky port a kurvi to. Tohle je vnitrni chyba kerou asi melo odhalit nake testovani, pokud se to neska vubec testuje. Kdo vi co za vymet ti ty polsky smelinari prodali...
19.06.2020 (21:07:33)
RayeR (web) :
ps my sme kupovali MCU primo od ST v tisicovkach a nikdy takovyhle problem nebyl, pokud byla naka chyba, tak dle errat a chovalo se to +- konzistentne na vsech kusech...
20.06.2020 (09:02:21)
VroutekB:
Já tu někde mam od poláků dva kusy CS4270 kodeku, kterej taky nefungoval a ani za svatou pyču nešel zprovoznit. Projekt šel k ledu, ale mám tu nachystané další dva kusy téhož z Mouseru, tak se uvidí, třeba se to taky opraví přeletováním kus za kus **22


Přezdívka:*
Heslo:*

███   ███   █ █   
  █   █ █   █ █   
███   ███   ███   
  █     █     █   
███   ███     █   
Opiš:*

Zde můžete smazat vlastní vlákno nebo kteroukoliv odpověď v něm. Můžete smazat vlastní odpověď v cizím vlákně, pokud na ni ještě nikdo jiný nereagoval. Mazat cizí vlákna a odpovědi v nich mohou pouze admini. Smazání příspěvku je nevratná operace! Smazáním vzkazu se smažou i odpovědi na něj.
Seznam uživatelů
Zpět na knihu