struct problem / serielle Schnittstelle

derTim schrieb:

an gehen sie aber nur ganz kurz und dann sind sie wieder weg... obwohl sie eigentlich die ganze zeit an sein sollten

kann es sein, dass sich der controller kurz danach resettet? data- oder prefetch- aborts? setz doch mal 'nen breakpoint auf diese sprungvektoren. womit debuggst du überhaupt?

ich arbeite mit der keil umgebung - und es tritt kein data abort oder ähnliches auf - der code läuft munter weiter (allerings funktioniert halt nichts, kein USART, kein Ethernet und die LEDs blinken nur kurz auf)...

software-fehler schließe ich fast schon aus... die PLL ist stabil und läuft..

derTim

okay, aber wenn die LEDs nicht an bleiben, dann ist ja was oberfaul.
guck' dir auch mal das an: http://www.efo.ru/ftp/pub/atmel/_ARM_MCUs_32bit/ARM_Disk/ARM_Disk_July_2006/pdf/errata/at91rm9200_erratasheet.pdf

.............
............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. .............

das errata-sheet kenn ich - aber so einen Fehler kann man gar nicht in ein solches sheet packen - wie gesagt muss ein HArdware-Fehler sein (vll. dieser falsch liegende Widerstand...) weiß zwar nicht welcher Widerstand einen Prozessor gleich mal völlig lahm legt, wenn er open ist - aber mal schaun..

derTim

hast du eine idee was es sein könnte? der widerstand ist es nicht, ist nämlich einfach nur später reingekommen und deshalb so schief drinnen...

welches anzeichen ist es wenn der prozessor nur ganz kurz die pullups deaktiviert und sofort wieder einschaltet? Ist die Wahrscheinlichkeit, dasss durch die Software irgendwas im Prozessor kaputt gegangen ist größer als ein Hardware-Fehler außerhalb des Prozessors?

Ich meine es geht halt gar nichts, was die Peripherie angeht - beide RS232 nicht, die Ethernet Schnittstelle empfängt keine Pakete und die LEds blinken nur einmal ganz kurz auf...

derTim

da gibt es mehrere möglichkeiten. was geht noch?
- kommst du über's JTAG noch drauf?
- wenn ja, was zeigt der debugger an?
- bist du ganz sicher, dass sich der controller nicht wiederholt resettet?
- ist vielleicht der bootloader aktiv? (ich nehme an, dein controller hat sowas)
- wie ist es mit den PLL settings und clocks? ist da alles klar?
- vielleicht hardwarefehler? kalte lötstellen (kannst mit 'nem durchgangsprüfer messen)?
- schwingt der quarz noch (kannst du mit'm oszi sehen).

musste eben systematisch vorgehen und fehlerquellen ausschliessen...

also durch software kann man 'nen µC kaum zerstören, es sei denn, du hast vielleicht irgendwelche security-bits gesetzt, so dass gar nichts mehr geht oder die PLL astronomisch hochgefahren und das teil übertaktet, aber das alles muss schon mit böser absicht geschehen sein.

... ach ja, das wichtigste: die versorgungsspannungen nachmessen (mit oszilloskop am besten), da dürfen keine einbrüche oder sonst irgendwelche komischen signale drauf sein.

ARM freak schrieb:

da gibt es mehrere möglichkeiten. was geht noch?
- kommst du über's JTAG noch drauf?
- wenn ja, was zeigt der debugger an?
- bist du ganz sicher, dass sich der controller nicht wiederholt resettet?
- ist vielleicht der bootloader aktiv? (ich nehme an, dein controller hat sowas)
- wie ist es mit den PLL settings und clocks? ist da alles klar?
- vielleicht hardwarefehler? kalte lötstellen (kannst mit 'nem durchgangsprüfer messen)?
- schwingt der quarz noch (kannst du mit'm oszi sehen).

musste eben systematisch vorgehen und fehlerquellen ausschliessen...

also durch software kann man 'nen µC kaum zerstören, es sei denn, du hast vielleicht irgendwelche security-bits gesetzt, so dass gar nichts mehr geht oder die PLL astronomisch hochgefahren und das teil übertaktet, aber das alles muss schon mit böser absicht geschehen sein.

die Clock funktioniert nicht... es gibt intern im Controller ein PMC PeripherieClock die für alle Sachen zuständig ist wie Ethernet, RS232, Timer etc. - und all das funktioniert auch nicht... die Clock sowie Interrupts lösen nicht aus... nachdem bei der USART aber kein interrupt gesetzt worden ist, muss es die Clock sein, die fehlt und somit nichts übertragen wird.

Resetten tut der Controller definitiv nicht. Mit JTAG kann ich neuen code immer noch uploaden (läuft auch nicht mit einer Clock). Der Debugger zeigt keinerlei Fehler an (keinen Data Abort oder ähnliches)... das programm wird ausgeführt (aber ohne ISR Routinen)

Wie kann ich die PLL Settings genau überprüfen? Hochfahren tut der Controller zwar (aber ich weiß nicht genau was das dann heißt) - würd vermuten schon mal ein gutes zeichen...

Wie setzt man denn solche Security Bits?? Steht im Manual gar nichts darüber drinnen... wenn dann kann das nur aus versehen geschehen sein; bei AVRs gibt es die Fuses (aber das sind noch keine Security Bits, oder?)

Den Quarz muss ich noch überprüfen - kann ich da einfach mit dem Oszi drangehen mit einer Spitze?

derTim

mist, ich kann nicht mehr anworten, der doofe spamschutz lässt nix durch

n-a, d-a-nn ma-ch do-ch ma-l ei-n ga--nz pri-mitives prog-ramm re-in, da-ss ei-nfach ei-ne L-ED od-er son-st 'n-en po-rt t-oggled. geh-t so-was?

derTim schrieb:

Wie kann ich die PLL Settings genau überprüfen? Hochfahren tut der Controller zwar (aber ich weiß nicht genau was das dann heißt) - würd vermuten schon mal ein gutes zeichen...

die einstellungen dafür stehen im user manual und sind abhängig von dem quarz, der angeschlossen ist. wenn da was nicht stimmt, kann es z.b. sein, dass solche sonderbaren effekte auftreten. wie lange lief's denn vorher?

derTim schrieb:

Wie setzt man denn solche Security Bits?? Steht im Manual gar nichts darüber drinnen... wenn dann kann das nur aus versehen geschehen sein; bei AVRs gibt es die Fuses (aber das sind noch keine Security Bits, oder?)

ich weiss nicht wie's bei deinem controller geht, aber die meisten in dieser klasse haben sowas um z.b. den zugriff auf's flash von aussen zu unterbinden oder JTAG zu disablen usw.

derTim schrieb:

Den Quarz muss ich noch überprüfen - kann ich da einfach mit dem Oszi drangehen mit einer Spitze?

ja, am besten wenn du 'den tastkopf auf hochohmig stellst, damit das signal nicht zusammenbricht.

sorry, irgendwas hat dem spamfilter nicht geschmeckt (besonders der satz mit den vielen - darin)

das ganze lief schon zwei monate lang ganz ok - manchmal hatte ich das Problem, dass der Controller nicht zur main-Routine gekommmen ist - aber das passierte vll. drei, vier Mal - öfter nicht...

derTim

die beiden Quarze arbeiten auf jeden Fall... sind noch nicht tod...

derTim

wenn ich mit JTAG uploade - mach ich das mit 1MHz und das funktioniert auch einwandfrei... meckert Keil nicht, dass der Target das gar nicht unterstützt etc. -> von daher würde ich vermuten, dass der Quarz auf jeden Fall auch richtig läuft (die PLL dürfte hier noch nicht im Spiel sein)...

diess Security Bits, kann man die nicht ganz einfach wieder durch löschen des kompletten RAMs und ROMs wieder zurücksetzen - bzw. wenn ein solches bit verändert worden ist, wie kann man es wieder in den ursprünglichen Zustand zurücksetzen?

derTim

kommt drauf an, wie das JTAG in deinen controller integriert ist. es gibt welche, da reichts schon, wenn strom da ist und man kann sie schon über jtag flashen und sogar code auf der CPU laufen lassen, der takt kommt dann von der TCK leitung des JTAGs. was mir allerdings zu denken gibt ist, dass von anfang an nicht richtig lief (dass er manchmal nicht startete, wie du sagtest). so'ne ferndiagnose macht allgemein nicht viel sinn, aber vielleichet fragst du mal da: http://www.mikrocontroller.net/forum/mikrocontroller-elektronik da gibt's bestimmt welche, die sich mit deinem atmel auskennen.