ATmega: Störungen durch Masseschleife ISP/RS232

[Stefan H. (shaun)]

Hallo zusammen,
ich habe gerade nach langem Suchen ziemlich eindeutig feststellen 
müssen, dass mein ATmega64 anscheinend ein Problem mit der Masse hat. 
Das Ding sitzt auf einer zweilagigen Platine mit reichlich Massefläche, 
an den ISP-Pins hängt direkt die 10polige Pfostenleiste, am USART1 ein 
MAX232 und daran die Serielle des PC, der über den Parallelport via 
ISP-Adapter auch am Controller angeschlossen ist. Wenn beide Stecker 
draufstecken führt die Datenübertragung per RS232 ab und zu mal zu 
Störungen derart, dass ein über SPI angebundener DDS-Chip sich aufhängt 
- ich war faul und habe die I/O-Sync Leitung nicht verwendet, so dass 
ein einziger Fehler in der SPI-Kommunnikation den Chip mit guter Chance 
bis zum nächsten Reset lahmlegt.
Der SPI-Bus ist beim ATmega64 übrigens unabhängig vom ISP, daher bin ich 
umso erstaunter. Ich werde das Ganze erstmal durch Anschluss der 
I/O-Sync-Leitung abmildern, aber ewas bedenklich finde ich es schon.
Kann jemand mit ähnlichen Erfahrungen vielleicht etwas Trost verschaffen 
;)

[Stefan W. (wswbln)]

...Erfahrungen mit Masseschleifen kann ich nicht beisteuern, aber SPI 
ohne die CE (heißt bei den AD-DDSen FrameSync) Leitung zu verwenden ist 
Mist (wie Du ja schon feststellen durftest), denn via CE (FS) kann man 
die Kommunikation mit dem/den Slave(s) neu aufsetzen. Aus dem selben 
Grund ist I²C in kritischen Systemen (wo sich verschalten oder nicht 
(rechtzeitig) schalten zu schweren Folgeschäden führen kann (z.B. 
Umrichter)) und/oder in Systemen die in störungsbehafteten Umgebungen 
laufen sollen, mit sehr grosser Vorsicht zu geniessen, denn diesen Bus 
kann man (zumindest mit älteren Bausteinen) so aufhängen, dass man da 
ohne Aus/Einschalten nicht mehr rauskommt. Bei neueren Bausteinen hilft 
manchmal so lange SCK toggeln, bis wieder ein ACK kommt, aber ich habe 
bei sowas ein ungutes Gefühl. Die Ansteuerung z.B. einer H-Brücke würde 
ich NIE über I²C machen (über SPI jederzeit, aber mit CE :-) )

[Stefan H. (shaun)]

Danke, nur leider musste ich feststellen, dass CS alleine beim AD9959 
nicht ausreicht. Einmal ein Bit verloren und das war's bis zum RESET. 
Zum Re-Synchronisieren der Kommunikation hat der 9959 eine dedizierte 
SYNC-I/O-Leitung (in allen ausser dem superschnellen 4-bit-Modus), die 
lt Datenblatt dazu dienen kann, eine Übertragung vorzeitig zu 
terminieren oder eine neue einzuleiten. Genau diese Leitung werde ich 
nun auch anschliessen, da es mir etwas unsauber erscheint, dass eine 
Störung mein Gerät unbrauchbar macht.
Im Übrigen habe ich inzwischen die Ursache gefunden: die Kapazität des 
ISP-Kabels ist offensichtlich zu groß, denn auch wenn der ATmega64 MISO 
und MOSI nicht für den ISP braucht, wird SCK dennoch geteilt. Und eben 
dort sehen die Flanken mit angestöpseltem ISP-Kabel nicht mehr wirklich 
gut aus. Hatte neulich abend wohl ein Brett vor dem Kopf.
Zu Deinem Inverter-Beispiel möchte ich noch loswerden, dass in dem 
Bereich ja sowieso eine hardwareseitige Verriegelung gegen 
Kompletthavarien angebracht wäre, ausserdem ein Watchdog, der schnell 
genug ist, dass bei einem hängenden uC nicht die 
Zwischenkreisgleichspannung ins Verbundnetz gebügelt wird 
(Solarumrichter oder sowas).
Aber ist schon richtig, wo Softwareausfälle Folgen haben können, ist man 
mit Bussystemen, die sich nicht unter allen Umständen neu 
synchronisieren lassen, sicher nicht so gut beraten.