Problem mit STM32 ADC (DMA) - HW oder SW?

[Alec T. (803)]

Hi zusammen,

vielleicht hat ja jemand von euch ne ähnliche Erfahrung gemacht und 
hilft mir kurz runter vom Schlauch...

Ich nutze nen STM32F103C8T6. Projekt wurde aufgesetzt mittels CubeIDE 
(bitte keine Grundsatzdiskussion darüber ;). Der ADC ist konfiguriert 
für DMA. 9Kanäle, AD0 bis AD6 + interne temp + interne VCC/ref messung.

FreeRTOS ist im Einsatz.

Problem: Der ADC macht meist alles super, aber in undefinierten 
zeitabständen misst er für unregelmäßige dauer "mist".
Konkret misst er am Beispiel der internen Ref normalerweise 3V3 wie 
erwartet, dann auf einmal zeitweise aber nur 2V8 über einige oder auch 
mehrere sekunden hinweg. dann wieder alles mormal.

Der ADC wird im moment manuell im DMA modus getriggert, dann 10ms 
osdelay, dann auswerten, wieder 10ms osdelay (ja, kann man besser 
machen, kommt noch). Keine Fehler wenn ich die entsprechend ADC status 
HAL funktionen abfrage.

Stack überlauf in den Tasks sollte es nicht sein, laut abfrage über die 
HAL funktion ist da überall genug luft. Und den content der tasks habe 
ich testweise weitgehend auskommentiert. Der content beeinflusst jedoch 
die Auftrittswahrscheinlichkeit merklich, i.e. wird anscheinend weniger, 
und tritt wenn fast alles auskommentiert ist manchmal nicht mehr auf, 
zumindest in dem zeitraum wo ich es laufen gelassen habe.

Auf der einen Seite typisch für nen Speicherüberlauf, wüsste aber nicht 
wo der herkommen sollte. Ausserdem auftreten auch, wenn auch deutlich 
seltener, wenn fast alles auskommentiert ist?
Und zudem, trotz erheblicher änderungen am restlichen code, immer 
dieselben werte die darüber schreiben? Scheint mir auch unwahrscheinlich 
bzw. untypisch für nen speicherüberlauf.

Hardware hatte ich im Verdacht. Zugegeben alles Chinakracher. Habe aber 
inzwischen zwei eigene prototypen-Boards und zwei Bluepills von 
unterschiedlicher Bauart durchgetestet, und alle verhalten sich gleich. 
Insofern, HW fake etc. nicht ausgeschlossen, aber...

Jemand ne Idee?

Mapfile um zu gucken was vor dem DMA array liegt muss ich mir noch 
anschauen.
Debugger hab ich leider nicht. Muss mir wohl doch bald mal nen j-link 
edu zulegen. Kann ich damit Zugriffe auf bestimmte speicherbereichte 
überwachen oder bei speicherzugriff auf das DMA ziel nen breakpoint 
setzen?

Danke für die Infos und Grüße
Alec

[Uwe Bonnes (Gast)]

Ueberspannung an Pins ("positive injection") bringt die analogen Teile 
gerne durcheinander. Auch auf das Problem hin betrachten...

[Stefan F. (Gast)]

Du hast weder deine Software noch die Hardware zum überprüfen vorgelegt. 
Was erwartest du: Wilde Phantasien oder zielgerichtete Hilfe?

Jedenfalls kann ich dir bestätigen, dass sowohl die Hardware als auch 
die Software kaputt sein kann - das ist eigentlich immer so.

[Alec (Gast)]

Stefan ⛄ F. schrieb:
> Du hast weder deine Software noch die Hardware zum überprüfen vorgelegt.
> Was erwartest du: Wilde Phantasien oder zielgerichtete Hilfe?

Steht doch da oben. Eigene Erfahrungen, übliche Fallstricke, 
Denkanstöße.

Hardware ist u.a. ein stinknormales Bluepill Board. Denke ist unnötig 
dazu hier was anzuhängen, dürften viele kennen. A0-A6 auf feste 
potentiale gelegt, jeweils 0V, VCC/3, VCC2/3, VCC und das ganze nochmal 
von vorn.
Ansonsten sind da nur noch 4LEDs mit Vorwiderstand an den Timer3 PWM 
Kanälen dran. Versorgung über USB.

Software, wenn du Lust und Zeit hast kannst du natürlich auch den 
kompletten code haben, bin aber davon ausgegangen das hier niemand für 
andere Leute debuggt...

[Alec (Gast)]

Uwe Bonnes schrieb:
> Ueberspannung an Pins ("positive injection") bringt die analogen Teile
> gerne durcheinander. Auch auf das Problem hin betrachten...

Danke, sollte aber zu zumindest bei den Bluepill Boards nicht auftreten 
können. Die ADC Eingänge hängen alle irgendwo zwischen GND und VCC.

[Alec T. (803)]

Falls jemand ein ähnliches Problem hat: Für mich hat die Änderung im DMA 
von Normal auf Cyclic das Problem gelöst. Wenn ich mal Zeit habe schau 
ich mal warum, Grund ist mir noch nicht ganz klar...