dma schreibt nicht ins Datenregister

Hänge deinen Quelltext (Minimalbeispiel) hier an. Von dubiosen Service 
lade ich nichts runter, und viele andere hier sicherlich auch nicht.

Sebastian Kaulitz schrieb:
> Ok, ist im Anhang.

Welche Program erzeugt Sourcecode mit der Endung .rar????

(How low can it go)

Sebastian Kaulitz schrieb:
> Hat denn keiner eine Idee?

Evtl. der ARM-Klassiker "Peripherie-Clock nicht aktiviert"?
Wenn man Deine main.c Datei mal überfliegt (gründlicher habe ich es mir 
nicht angeschaut, da ich mit dem HAL-Zeugs nix am Hut hab), fällt auf, 
daß in   MX_GPIO_Init() und MX_DMA_Init() jeweils mit 
HAL_RCC_xxx_CLK_ENABLE() Clock aktiviert wird, in MX_SPI1_Init() jedoch 
nicht.

Er hat das gesamte Projekt"Test" mit nem dutzend z.t. hier nicht 
benötigtigter Ordner gepackt exportiert.

Als wüste er was folgte wen er irgend eine nicht im SC deqularierte 
Funtion im QT aufruft. Schlau aber nicht schlau genug gnörgeld wird 
trotzdem.


Um es kurz zumachen ich kenne Keinen Prozessor bei dem der DMA HW 
Register direkt verändert. Das obliegt imho besser der Init des 
abgelegten Codes.

DMA dient dem schnellen Austausch von Daten mit der Perepherie ohne 
Prozessorlast zu erzeugen und Register zu verändern.

Namaste

Winfried J. schrieb:
> Um es kurz zumachen ich kenne Keinen Prozessor bei dem der DMA HW
> Register direkt verändert.

Doch, der DMA schreibt direkt ins SPI-Tx Register (zumindest, wenn alles 
richtig läuft).

Winfried J. schrieb:
> Das obliegt imho besser der Init des
> abgelegten Codes.

Da vermute ich bei völliger Ahnungslosigkeit (s.o.), daß 
HAL_SPI_Transmit_DMA() wohl die entsprechenden Register von DMA und SPI 
geeignet initialisiert. Wenn die SPI-Peripherie aber nicht getaktet ist 
(meine Vermutung), geht natürlich nichts.

Sebastian Kaulitz schrieb:
> Ansonsten könnte man ja beim Debuggen nicht sehen,
> dass die Werte initialisiert werden.

Auch ohne Takt kann man manchmal in bestimmte Register schreiben und 
deren Inhalt lesen (hängt vom Controller ab). Dynamische Prozesse 
funktionieren dann trotzdem nicht.

Sebastian Kaulitz schrieb:
> Sobald über die HAL_SPI_Transmit_DMA das DMAEN Bit 1 gesetzt wird,
> wird CNDTR 0 ohne, dass das SPI_DR Register beschrieben wird.

Wie prüfst du das?

Oft sind solche Register nicht lesbar, oder Lesezugriffe (auch solche 
durch den Debugger!) haben Nebeneffekte. Insbesondere Registerzugriffe 
durch die DMA-Engine könnten für den Debugger nicht direkt sichtbar 
sein.

Kannst du manuell Werte in SPI_DR schreiben und siehst sie dann aus MOSI 
rauströpfeln?

Bist du dir sicher, dass die DMA-Engine die auch an die richtige Adresse 
schreibt? Lass die Daten mal nacheinander (stride = 1) ins RAM schreiben 
und schaue, ob die da ankommen. Mit stride = 0 sollte nur der letzte 
Wert ankommen.

Weißt du, wie die DMA-Engine feststellt, dass das zuletzt geschriebene 
Byte fertig gesendet wurde (und bist du sicher, dass das funktioniert)?

S. R. schrieb:
> Wie prüfst du das?
>
> Oft sind solche Register nicht lesbar, oder Lesezugriffe (auch solche
> durch den Debugger!) haben Nebeneffekte.

Genau so sieht es nämlich aus, Heisenberg lässt grüßen. Abgesehen davon 
kann man grundsätzlich nicht in das SPI DR etwas hineinschreiben und es 
dann aus dem Register wieder lesen. Schreibzugriffe gehen in den 
TX-Buffer und Lesezugriffe geben im Idealfall das wieder, was man auf 
dem Bus empfangen hat. Logischerweise muss man nicht grundsätzlich das 
empfangen was man gesendet hat. All das und noch viel mehr kann man 
erfahren wenn man sich mal das Kapitel zu SPI im Handbuch durchließt.

Was auch immer der Debugger anzeigt, was in das DR geschrieben wurde, 
läßt sich nicht auslesen, bestenfalls weiß er noch, was er gerade 
reingeschrieben hat. Schreiben per DMA ist komplett unsichtbar, es sei 
denn, man schaut sich an, was auf der Sendeleitung der SPI-Schnittstelle 
raus kommt. Aber da muß man sehr schnell schauen. Mit LA oder zumindest 
Oszi, das auf eine Flanke triggert. Dann flackert es zumindest, wenn die 
DMA heimlich Daten verschickt.

Sebastian Kaulitz schrieb:
> Ich habe nun folgendes drin:   HAL_SPI_Transmit(&hspi1, flameBits ,
> sizeof(flameBits)/sizeof(flameBits[U8FLAMELED1ST.position]), TIMEOUT);
>
>   HAL_SPI_Transmit_DMA(&hspi1, digitNumbers, 1);
>   put2STR();

Ja,was denn jetzt?

Mit oder ohne DMA?
Du solltest dich mal entscheiden!
Doppelt bringt gar nix.
Ohne den Code genau angeschaut zu haben, sieht deine Grössenberechnung:

Sebastian Kaulitz schrieb:
> sizeof(flameBits)/sizeof(flameBits[U8FLAMELED1ST.position])

auch ziemlich "strange" aus.

Sebastian Kaulitz schrieb:
> Das habe ich schon gelesen, dachte aber, dass man das trotzdem sehen
> müsste.

Du willst auf die SPI-Schnittstelle sowohl schreiben, als auch lesen, 
hast aber nur ein Register, nämlich DR. Wenn du jetzt beim lesen von DR 
das zurück bekämst, was du zuletzt geschrieben hast, wie genau soll man 
dann das lesen was der Controller von der Schnittstelle empfangen hat?

Sebastian Kaulitz schrieb:
> Sorry, falsch kopiert.HAL_SPI_Transmit_DMA(&hspi1, flameBits, 2);
> HAL_SPI_Transmit_DMA(&hspi1, digitNumbers, 1);

Trotzdem Quatsch!
Nach dem 1. Transmit ist der DMA noch beschäftigt, und du versuchst 
direkt einen 2. hinterher zu schieben.

Sebastian Kaulitz schrieb:
>> Wie prüfst du das?
>  Ich debugge

Da siehst du vermutlich garnix.
Weder den geschriebenen Wert, noch die DMA-Engine in Aktion.

>> Kannst du manuell Werte in SPI_DR schreiben und siehst sie dann aus MOSI
>> rauströpfeln?
> mit direktem Schreiben mittels hspi.Instance->DR = 0x1111;
> geht das Schreiben auch nicht

Wie prüfst du das?

Halte mal ein Oszilloskop, einen Logikanalysator oder meinetwegen eine 
LED mit Vorwiderstand an den MOSI-Pin. Wenn du da keine Übertragung 
siehst, dann kann die DMA-Engine auch keine Übertragung auslösen.

>> Bist du dir sicher, dass die DMA-Engine die auch
>> an die richtige Adresse schreibt?
> Ja siehe Bild

Kann ich nicht interpretieren, glaube dir aber einfach mal unbesehen. 
;-)

>> Lass die Daten mal nacheinander (stride = 1) ins RAM schreiben
>> und schaue, ob die da ankommen. Mit stride = 0 sollte nur der letzte
>> Wert ankommen.
> Ich verstehe nicht genau, was du genau meinst.

Wenn du ein 10 Byte-Array von A nach B kopierst, dann siehst du die 10 
Bytes an den Adressen (B, B+1, B+2, ...) auftauchen. Das 
SPI-Datenregister hat aber nur eine Adresse, also müssen die 10 Bytes 
nacheinander an die gleiche Adresse geschrieben werden.

Beides kannst du testen, indem du in den RAM schreiben lässt.

Sebastian Kaulitz schrieb:
> sizeof(flameBits)/sizeof(flameBits[U8FLAMELED1ST.position])
>
> Wo ist das Problem?

Üblicherweise nimmt man sizeof(array)/sizeof(array[0]), wenn man die 
Größe eines Arrays in Bytes möchte. Per Definition sind nämlich alle 
Einträge gleich groß, da braucht man dem Compiler (und dem Leser) keine 
zusätzliche Dereferenzierung aufbürden. :-)

Sebastian Kaulitz schrieb:
> Trotzdem komme ich aber in den Hardfault Handler.. :(

Davon schriebst du bisher nichts. Lese die entsprechenden Register im 
Handler aus und lasse dich beleuchten, warum der HardFault feuerte. 
Könnte ein Alignment-Problem sein.

Du hast, soweit ich das einschätzen kann, zwei Probleme:
a) SPI funktioniert nicht
b) DMA funktioniert nicht.

Sorge erstmal dafür, dass SPI funktioniert. Notfalls teste mit einer 
Software-SPI am gleichen Pin, dass deine angeschlossene Hardware auch 
funktioniert. Fange erst danach an, mit DMA zu spielen.