Hallo, durch einen Besuch vom Distributor wurde J-Link von Segger mit Ozone empfohlen. Jetzt stellt sich mir die Frage, welche praktischen Vorteile hat dieser Debugger gegenüber dem Atmel ICE3? Als Prozessoren kommen SAMD21, SAME53 und zukünftig evtl. PIC32 zum Einsatz. - Kann J-Link auch Trace (oder eingeschränkt)? - Kann J-Link Data Breakpoints, wenn der Prozessor das selbst nicht unterstützt? - Lohnt sich J-Link Pro / Ultra+ ? - Was ist euch daran negativ aufgefallen? Wie sieht es mit der Unterstützung bei Atmel Studio 7 / MPLAB X aus? Danke für praktische Erfahrungen.
> Atmel ICE3
Atmels Liste der "Verfehlungen" ist zu lang, um zumindest bei mir
ernsthaft als Alternative zu erscheinen:
- Treiberbau mit Demoversionen von DDKs/SDKs
- Spannungsregler die schon beim scharfen hinsehen abrauchen
- unzuverlaessige Winzsteckverbinder
Und Segger scheint die J-Links, und deren Updatefaehigkeit, auch
als Gelddruckmaschine anzusehn.
Ich habe hier 2 J-Link V8 und einige in Boards Embedded J-Links.
Bei einer Neuanschaffung wuerde ich mich vorher zumindest genau
umsehen ob es wieder etwas von Segger werden sollte.
Ozone ist m.W. "nur" ein Debugger. Mir reichen bei "normalen"
Controllern eigentlich immer die Moeglichkeiten der Debugger
der jeweiligen IDE, also IAR C-Spy oder der von Keils MDK.
Bei Signalprozessoren ist aber ein zusaetzlicher Trace, bzw.
die graphische Darstellung, schon ein nettes Feature.
Alex schrieb: > - Kann J-Link auch Trace (oder eingeschränkt)? "J-Link" ist ein ziemlich weit gefasster Begriff. Welches der J-Links welche Features unterstützt, siehst du hier: https://www.segger.com/products/debug-probes/j-link/models/model-overview/ > - Kann J-Link Data Breakpoints, wenn der Prozessor das selbst nicht > unterstützt? Das hat mit J-Link nicht so viel zu tun. GDB konnte das schon immer, aber das wird saulangsam. Die Strategie ist dann nämlich, dass die Software im Single-Step abgearbeitet wird und nach jedem Schritt geschaut wird, ob sich das entsprechende Datum geändert hat. Da kannst du mehr als einen Kaffee trinken in der Zeit … > - Lohnt sich J-Link Pro / Ultra+ ? Siehe verlinkte Matrix. > - Was ist euch daran negativ aufgefallen? Das Gefeilsche um den Preis. Der vom Atmel-ICE ist allerdings inzwischen auch schon mehr als doppelt so hoch wie zur Einführung durch Atmel. > Wie sieht es mit der Unterstützung bei Atmel Studio 7 / MPLAB X aus? Keine Ahnung, nehme ich nicht. Motopick schrieb: > unzuverlaessige Winzsteckverbinder Dafür musst du dich bei ARM bedanken. Den Mikro-10-Pin-Verbinder für Cortex-M haben die festgelegt. Atmel hat sich nur dran gehalten. > Spannungsregler die schon beim scharfen hinsehen abrauchen Meinst du damit den Dragon? Den Regler hätten sie auch gleich ganz weglassen können, aber sie wären dann aber außerhalb der Specs gewesen (von USB bzw. dem ATmega2560). Ansonsten ist es natürlich nicht trivial, einen Eingangspannungsbereich von 4,3 bis 5,3 V auf 4,5 V (oder mehr) sicher zu regeln, ohne eine aufwändige Wandlertopologie wie SEPIC zu nehmen (der Dragon sollte ja vor allem billig sein). > Ozone ist m.W. "nur" ein Debugger. Allerdings nicht der schlechteste – schreibe ich als alter GDB-Fan. Finde ich besser als all diesen Studio-Krams, und das nicht nur, weil es auch eine Linuxversion davon gibt.
>> - Lohnt sich J-Link Pro / Ultra+ ? Siehe verlinkte Matrix.
Bei den angegebenen Sachen weiss ich nicht, ob mir die in der Praxis was
bringen. Für was soll "High Speed Sampling Bandwidth" da sein?
Wann / wofür kommt "Download speed into RAM" zum Einsatz?
Und nochmal die Frage:
Welche praktischen Vorteile hat J-Link gegenüber ICE3???
PS:
Ich arbeite beruflich damit und mache anspruchsvolle Echtzeit embedded
Projekte.
:
Bearbeitet durch User
Alex schrieb: > Als Prozessoren kommen SAMD21, SAME53 und zukünftig evtl. PIC32 zum > Einsatz. Atmel ICE kann keine PICs. PICKIT4 schon. PICKIT4 unterstützt so ziemlich alles, was Microchip aktuell anbietet (PICs, AVR, ARM). > - Kann J-Link auch Trace (oder eingeschränkt)? ETB ja. Für ETM brauchst Du einen J-Trace. > Wie sieht es mit der Unterstützung bei Atmel Studio 7 / MPLAB X aus? MPLABX unterstützt J-Link für PIC32. Bei ATSAM weiß ich es jetzt nicht genau. Andere PICs kann der JLINK nicht, dafür brauchst Du ein PICKIT4. Atmel/Microchip Studio verwende ich nicht. fchk
Alex schrieb: > Welche praktischen Vorteile hat J-Link gegenüber ICE3??? Dass nicht nur Atmel unterstützt wird. fchk
> Welche praktischen Vorteile hat J-Link gegenüber ICE3???
Segger ist sehr zuverlaessig und vor allem Hersteller uebergreifend.
Wenn du kein Bastler bist sondern professionell so wirst du das
schaetzen weil du mit den unterschiedlichsten Familien von verschiedenen
Herstellern arbeitest.
Du kannst mit zwei oder gar noch mehr Debuggern gleichzeitig an einem
Rechner arbeiten. Sehr sinnvoll wenn man z.B irgendwas mit Kommunikation
macht und beiden Teilnehmern unter die Haube schauen will.
Es gibt Versionen die du ueber Ethernet betreiben kannst
was nett ist wenn du auf eine Kiste willst wo der Techniker gerade
in Australien ist oder du mal schnell kucken moechtest was in der
Fertigung schief laeuft.
Sie haben eine ziemlich gute Dokumentation die dir alles erlaubt
wenn man sie nur liesst.
Die Firma ist halt professionell in dem Sinne das du sie dafuer
bezahlst das sie deine Probleme mit dem Debugger loesen und das
klappt eigentlich ganz gut. Die Billigteile der Hersteller leiden
oftmals unter einem gewissen Mangel an Liebe. Dafuer kosten sie
fast nichts.
Aber natuerlich muss es nicht unbedingt Segger sein. Du kannst
auch bei Lauterbach kaufen. .-)
Vanye
Frank K. schrieb: > Alex schrieb: > >> Welche praktischen Vorteile hat J-Link gegenüber ICE3??? > > Dass nicht nur Atmel unterstützt wird. Das ist allerdings eine reine Softwarelimitierung auf der PC-Seite. Der Hardware ist es egal, wer den Cortex-M hergestellt hat, den du da dran hängst. Ich habe eine Zeitlang für ein Kundenprojekt einen STM32 damit debuggt, weil das Atmel-ICE in meiner Umgebung weniger zickig war als der ST-Link. (An Details und genaue Ursache kann ich mich nicht mehr erinnern, zu lange her. Funktionierte jedenfalls klaglos.)
Vanye R. schrieb: > Du kannst > auch bei Lauterbach kaufen. .-) Dagegen sieht allerdings Ozone fürchterlich modern aus. ;-) Das Lauterbach-GUI mutet irgendwie wie voriges Jahrhundert an.
Frank K. schrieb: > Atmel ICE kann keine PICs. PICKIT4 schon. PICKIT4 unterstützt so > ziemlich alles, was Microchip aktuell anbietet (PICs, AVR, ARM). Um noch eine Alternative in den Raum zu werfen: MPLAB Snap. https://www.microchip.com/en-us/development-tool/PG164100 Der unterstützt AVRs, PICs und SAM-Arme. Und er hat nicht den futzeligen Steckverbinder im 0.05"-Raster, sondern eine bastel- und sogar Steckbrettfreundliche achtpolige Buchsenleiste im 0.1"-Raster. Der USB-Anschluss ist leider eine Micro-USB-Buchse. Ob aber irgendeine Software außer Microchip Studio und MPLAB X damit etwas anfangen kann, entzieht sich meiner Kenntnis.
> Das ist allerdings eine reine Softwarelimitierung auf der PC-Seite. > Der Hardware ist es egal, wer den Cortex-M hergestellt hat, den > du da dran hängst. Ganz so einfach ist das nicht. Es gibt auch Controller wo die einzelnen Cores hinter einem speziellen Multiplexer versteckt sind, TI hat das zum Beispiel. Da muss der Debugger den auch bedienen koennen und beim RT2040 ist das ja auch so aehnlich. Ausserdem weiss der Debugger dann ja nicht wo das Ram liegt und wie gross es ist. Das ist manchmal auch ganz nett. Ich glaube die virtuellen seriellen Schnittstellen brauchen sowas. Vanye
Vanye R. schrieb: > Ganz so einfach ist das nicht. Es gibt auch Controller wo die einzelnen > Cores hinter einem speziellen Multiplexer versteckt sind OK, Multicores sind da nochmal eine andere Nummer. Ich kenne den von dir genannten nicht, würde mich aber jetzt nicht wundern, wenn das einfach nur ein IO-Register ist, welches vom Debugger aus passend eingestellt werden muss (und dann für alle Cores die gleiche Adresse hat). Dann wäre es auch nur wieder an der Ansteuersoftware, das zu tun. > Ausserdem weiss der Debugger dann ja nicht wo das Ram liegt und wie > gross > es ist. Wer sollte das sonst wissen, wenn nicht der Debugger? Die Hardware (+ Firmware) interessiert das nicht. Die bekommt erzählt, wohin sie greifen soll.
Jörg W. schrieb: > Ansonsten ist es natürlich nicht trivial, > einen Eingangspannungsbereich von 4,3 bis 5,3 V auf 4,5 V (oder mehr) > sicher zu regeln, ohne eine aufwändige Wandlertopologie wie SEPIC zu > nehmen (der Dragon sollte ja vor allem billig sein). Auf dem RP2040 Pico ist ein Buck-Boost der aus allem zwischen 3 V und 5.5V konstante 3.3V macht. Der ganze RP2040 kostet nichtmal 5 Euro... Jörg W. schrieb: > Dagegen sieht allerdings Ozone fürchterlich modern aus. ;-) Das > Lauterbach-GUI mutet irgendwie wie voriges Jahrhundert an. Dafür funktioniert sie und ist performant. Zudem läuft Trace32 auf so ziemlich jedem Betriebssystem und sieht immer gleich aus. Die Oberfläche kann man auch an den GDB anbinden, benutzen wir für Remote Debugging über Netzwerk bei Baugruppen ohne JTAG/SWD. Dazu noch die mächtige Skriptsprache vom T32... Wir haben hier auch Multi-Core System da kann man dann parallel alle Cores über einen Debugger analysieren. Dann der Support, meiner ist jetzt gute 12 Jahre alt, mit dem nächsten SW Update debugge ich damit dann auch RiscV. Möchte ich nicht mehr missen. Für Privat allerdings wohl etwas teuer, da nehme ich dann gdb + openocd. Ich hatte mal nen UDE Debugger von PLS zum Testen, das Teil war das absolute Grauen, haufweise unkontrollierbare Magie im Hintergrund, beim Starten des Debuggvorgangs hat der direkt mal nen Reset auf dem Target gemacht. Sowas geht gar nicht.
Andreas M. schrieb: > Auf dem RP2040 Pico ist ein Buck-Boost der aus allem zwischen 3 V und > 5.5V konstante 3.3V macht. Der ganze RP2040 kostet nichtmal 5 Euro... Ob der vor 15 Jahren auch so wenig gekostet hätte? Darüber reden wir ja hier bei Dragon. Gemessen am gewünschten Zweck / Zielpublikum des Dragon wären sie wirklich besser beraten gewesen, sich um den Grenzfall (es liegen nur die garantierten 4,3 V an der USB-Buchse an, aber der Controller braucht formal mindestens 4,5 V, um mit 16 MHz getaktet werden zu dürfen) keine Rübe gemacht hätten und keinen Spannungsregler erst vorgesehen hätten. Das war ja letztlich auch der übliche "Reparatur"-Ansatz, wenn der Regler geschossen war: auslöten und überbrücken. > Jörg W. schrieb: >> Dagegen sieht allerdings Ozone fürchterlich modern aus. ;-) Das >> Lauterbach-GUI mutet irgendwie wie voriges Jahrhundert an. > > Dafür funktioniert sie und ist performant. Mag sein, aber hässlich wie Sau ist das Ding trotzdem. Eigentlich unglaublich, dass man in der Lage ist, mit Qt sowas hässliches zu bauen. :-) (Privat wäre mir deren Kram allerdings auch viel zu teuer. Ein J-Link Edu kann man sich privat dagegen schon noch leisten.) Um zurück zur Eingangsfrage zu kommen: funktionieren tut Ozone durchaus auch.
:
Bearbeitet durch Moderator
Jörg W. schrieb: > > Dagegen sieht allerdings Ozone fürchterlich modern aus. ;-) Das > Lauterbach-GUI mutet irgendwie wie voriges Jahrhundert an. Dafür kann der Lauterbach TRACE32 deutlich mehr als nur ARM und RISC-V.
Was ich bei Segger J-Link inzwischen schätze sind die Software Tools. https://wiki.segger.com/UM08001_J-Link_/_J-Trace_User_Guide#J-Link_Software_and_Documentation_Pack Die funktionieren recht gut und haben bei mir weniger Probleme gemacht als die Tools anderer Hersteller. So Dinge wie schnelle Debug Ausgabe über den RTT Viewer möchte ich nicht mehr missen.
Jörg W. schrieb: > Mag sein, aber hässlich wie Sau ist das Ding trotzdem. Eigentlich > unglaublich, dass man in der Lage ist, mit Qt sowas hässliches zu bauen. Mit Netbeans gelingt das auch; die MPLAB X IDE ist damit ... "erstellt". Ist Ozone noch schlimmer?
Dieter S. schrieb: > Jörg W. schrieb: >> >> Dagegen sieht allerdings Ozone fürchterlich modern aus. ;-) Das >> Lauterbach-GUI mutet irgendwie wie voriges Jahrhundert an. > > Dafür kann der Lauterbach TRACE32 deutlich mehr als nur ARM und RISC-V. Wobei das eine mit dem anderen nichts zu tun hat. Lauterbach ist ja auch einiges teurer als Segger, dafür kann man schon auch paar Features mehr erwarten.
Harald K. schrieb: > Ist Ozone noch schlimmer? Ich finde es etwas angenehmer. Ein kleines bissel überladen, aber man kann wenigstens die einzelnen Fensterchen auch rauslösen und bspw. auf den zweiten Bildschirm schieben.
Also euch allen schon mal ein Dankeschön für eure Einschätzungen - auch wenn es zeitweise etwas vom Thema abgedriftet ist. Die Infos über Alternativen, die ich gar nicht "auf dem Schirm" hatte, sind interessant. Was mich int der täglichen Arbeit oft plagt, ist dass wenn man die höchste Optimierungsstufe aktiviert hat, das Programm fast nicht mehr debugbar ist. (Breakpoints halten nicht mehr, lokale Variable wegoptimiert, und Single-Step hüpft im Programmcode wild umher). Aber das ist halt der Compiler und die Debuginfo die er erzeugt. Oder kann das IAR oder der J-Link auf wundersame Weise besser?
Alex schrieb: > Aber das ist halt der Compiler und die Debuginfo die er erzeugt. Nicht die Debuginfo, sondern der Code, der so erzeugt wird. Die Debuginfo kann natürlich nur das abbilden, was auch als Code da ist. Die Kunst des Embedded-Debuggers (also der Person ;-) ist es dann, sich die nötigen Hilfsmittel zu schaffen, das trotzdem noch zu debuggen, ohne dabei die Optimierung ausschalten zu müssen und dadurch etwas ganz anderes zu debuggen: volatile-Variablen, die man sich später im Debugger ansehen kann; ein simpler NOP kann stets einen Breakpoint erhalten; ein paar GPIOs zum Herumwackeln, damit man den Programmfluss auf dem Logikanalysator nachvollziehen kann.
Jörg W. schrieb: > Die Kunst des Embedded-Debuggers (also der Person ;-) ist es dann, sich > die nötigen Hilfsmittel zu schaffen Volle Zustimmung. Ich ergänze um schnelle Debug/Logging Ausgaben ins RAM oder über performante Schnittstellen. Ich würde trotz allem die volle Optimierung auf Performance nur nutzen, wenn sie wirklich notwendig ist. Wenn beim Start der Entwicklung bereits klar ist, dass die Plattform an die Grenzen von Speicher/Performance kommt, macht man was falsch.
Klaus H. schrieb: > Ich würde trotz allem die volle Optimierung auf Performance nur nutzen, > wenn sie wirklich notwendig ist. Darin unterscheiden wir uns. ;-) Ich benutze sie eigentlich immer. Weniger Optimierung versteckt potenzielle Fehler – bis hin zu -O0, bei dem der Compiler keine Codeflussanalyse macht und alle dahingehenden Warnungen (nicht initialisierte Variablen, nicht erreichbarer Code etc.) nicht mehr ausgeben kann.
Jörg W. schrieb: > Darin unterscheiden wir uns. ;-) OK, ich oute mich, Default ist bei mir auch "-O1". Dadurch fällt viel toter Code weg, ala const int i=0; if (i>0) {...} Trotzdem bleibt der Code noch einigermaßen debugbar.
:
Bearbeitet durch User
Unsere Firmwaren sind auf den meisten Targets ohne "-Os" oder "-O2" gar nicht mehr ausführbar. Wir müssen unsere Platformen lange unterstützen was in unserem Umfeld oft auch neue Funktionen/Features mit einschließt. Da ist also der RAM, der vor 10 Jahren da war die Grenze an der wir uns orientieren müssen. Alex schrieb: > Aber das ist halt der Compiler und die Debuginfo die er erzeugt. > Oder kann das IAR oder der J-Link auf wundersame Weise besser? Nein, das ist im Lauterbach auch nicht anders. Einzelschritt ("Steppen") ist dann einfach nicht mehr möglich bzw man muss wissen was man tut. Ich gehe dann gerne dazu über in der Assembler-Ansicht zu steppen. (Bei Lauterbach gibts da dann so ne gemischte Ansicht C/Assembler, weis nicht wie das bei den anderen ist). Einzelschritt kann alleine schon wegen Interrupten schwierig werden. Das braucht man in vielen Fällen aber auch gar nicht. Inzwischen finde ich die meisten Fehler schneller durch Code-Review der entsprechenden Stellen im Quellcode auf Basis des beobachteten Fehlverhaltens (Netzwerk, externe Schnittstellen). Manchmal muss kurz mit dem Debugger ein paar Zustandsvariablen prüfen. Für härtere Fälle haben wir Debug/Log Messages die wir über die Netzwerkschnittstelle ausgeben. Wenn man da UDP Frames mit dem syslog Port als Quelle oder Destination nimmt, dann zeigt einem das der Wireshark direkt in Textform an. In wirklich üblen Fällen ist dann mal ein Trace (via ETM oder SWD) notwendig, das kommt aber inzwischen sehr selten vor. Das nutzen wir eher nochmal zum Zeitmessen.
Andreas M. schrieb: > Dafür funktioniert sie und ist performant. Exakt. > Zudem läuft Trace32 auf so ziemlich jedem Betriebssystem Das stimmt leider nicht mehr. WIMRE hat Lauterbach im Release 2022.02 völlig überraschend die Unterstützung für VMS und SunOS als Host-Plattformen entfernt. Und dementsprechend gibt es auch keine Unterstützung mehr für PODBUS-Controller als Qbus-Einsteckkarte. > und sieht immer gleich aus. Ja, und sie ist dabei nicht im geringsten überladen, im Gegensatz zu so mancher anderer Software, bei der man sich irgendwann gar nicht mehr zurechtfindet. > Die Oberfläche > kann man auch an den GDB anbinden, benutzen wir für Remote Debugging > über Netzwerk bei Baugruppen ohne JTAG/SWD. Es geht in beiden Richtungen, d.h. T32 am GDB, aber auch ein T32 als gdbserver. Alternativ kann man den T32 Monitor auf dem Target laufenlassen, mit dem sich das GUI verbindet. > Dazu noch die mächtige Skriptsprache vom T32... Die Skriptsprache PRACTICE ist im Vergleich zu modernen Sprachen wie Python schon etwas aus der Zeit gefallen und bedürftige mal dringend einer Runderneuerung. Aber dafür ist sie weitgehend kompatibel geblieben, außer beim Erzeugen eigener Menüeinträge. Aber das ist ein Luxusproblem. > Wir haben hier auch Multi-Core System da kann > man dann parallel alle Cores über einen Debugger analysieren. Genau, und das können sogar Core komplett unterschiedlicher Architektur sein, die über eine JTAG-Chain zusammengeknüppert wurden. Oder auch mehrere Softcores oder Hard- und Softcore wie z.B. Cortex-A9 und Microblaze auf einem Zynq. > Dann der > Support, meiner ist jetzt gute 12 Jahre alt, mit dem nächsten SW Update > debugge ich damit dann auch RiscV. Möchte ich nicht mehr missen. Genau. Meiner ist von 2004 und wird immer noch voll unterstützt. Irgendwann (mit ARM Cortex-M) brauchte ich ein neues Anschlusskabel, in dem der Lizenzschlüssel steckt, aber das ist auch schon 14 Jahre her. > Für > Privat allerdings wohl etwas teuer, da nehme ich dann gdb + openocd. Nicht nur für privat. Auch in vielen Unternehmen gibt es da gewisse Vorbehalte, insbesondere von Leuten, die damit nicht arbeiten dürfen. > Ich hatte mal nen UDE Debugger von PLS zum Testen, das Teil war das > absolute Grauen, haufweise unkontrollierbare Magie im Hintergrund, beim > Starten des Debuggvorgangs hat der direkt mal nen Reset auf dem Target > gemacht. Sowas geht gar nicht. Oh, das ist interessant. Dann kann ich ja ganz froh sein, vor etlichen Jahren keinen UDE gekauft zu haben. Damals waren die Leute von PLS doch sehr bemüht, mir das Teil zu verkaufen.
Andreas M. schrieb: > In wirklich üblen Fällen ist dann mal ein Trace (via ETM oder SWD) > notwendig, das kommt aber inzwischen sehr selten vor. Das nutzen wir > eher nochmal zum Zeitmessen. Bei dem allerübelsten Fall, den ich jemals untersucht habe, reichte auch das nicht aus. Stattdessen musste ich mich rückwärts durch das Disassemblat eines Logikanalysators (HP16700) durcharbeiten und jeden Registerinhalt prüfen. Nach rund zwei Wochen konzentrierter Arbeit konnte ich dann herausfinden, dass ein Registerinhalt, der mit einer STM-Anweisung beim Funktionsaufruf auf den Stack geschrieben wurde, beim Zurücklesen mittels LDM nicht übereinstimmte, sondern ein Bit gekippt war. Das lag daran, dass auf einigen(!) Leiterplatten einige falsche SRAMs bestückt waren, d.h. die 5V-Ausführung statt der 3,3V-Ausführung. Erschwerend kam hinzu, dass die Komparatorschwellen von LA, CPU und SRAM natürlich nicht identisch waren.
Andreas S. schrieb: > Oh, das ist interessant. Dann kann ich ja ganz froh sein, vor etlichen > Jahren keinen UDE gekauft zu haben. Damals waren die Leute von PLS doch > sehr bemüht, mir das Teil zu verkaufen. Die hatten sich mir auf der Embedded World aufgedrängt, wollten uns unbedingt ein Demogerät zu Verfügung stellen. Das lief von Anfang an unrund war mir zu umständlich zu bedienen. Wir habens dann zurückgegeben. Allerdings muss man sich in T32 auch erst einarbeiten damit man mit umgehen kann. Kann auch gut sein dass ich mich schon zu sehr an T32 gewöhnt habe und ich inzwischen zu alt zum Umstellen bin. Andreas S. schrieb: > Das lag daran, dass auf einigen(!) Leiterplatten einige falsche > SRAMs bestückt waren, d.h. die 5V-Ausführung statt der 3,3V-Ausführung. > Erschwerend kam hinzu, dass die Komparatorschwellen von LA, CPU und SRAM > natürlich nicht identisch waren. Das ist natürlich fies. Das wird jetzt wirklich OT: Wir hatten ebenfalls mal ein Problem mit einer ungünstig gerouteten SDRAM Datenleitung. Die Firmware ist sporadisch abgestürzt wenn über PCI ein DMA gemacht wurde. Da gabs dann eine Einkopplung vom PCI Bus in die Datenleitung. Witzigerweise nur bei einem ganz bestimmten DMA Muster, sonst nicht. Und auch nur in bestimmten PCs.
Andreas M. schrieb: > Das ist natürlich fies. Das wird jetzt wirklich OT: Wir hatten ebenfalls > mal ein Problem mit einer ungünstig gerouteten SDRAM Datenleitung. Die > Firmware ist sporadisch abgestürzt wenn über PCI ein DMA gemacht wurde. > Da gabs dann eine Einkopplung vom PCI Bus in die Datenleitung. > Witzigerweise nur bei einem ganz bestimmten DMA Muster, sonst nicht. Und > auch nur in bestimmten PCs. Solch ein Kundenprojekt hatte ich auch schon einmal. Ich wurde damit beauftragt, einen angeblichen Fehler im Netzwerkstack von Linux zu untersuchen, weil es bei manchen Socket-Operationen einen Kernel Dump gab. Ich erkannte jedoch recht zügig, dass in den Speicherauszügen immer zwei Bits (Bit 2 und/oder Bit 18) gesetzt waren, und wusste auch, dass das DDR-RAM mit 16 Bit angebunden war. Ich ließ mit daher von dem zuständigen Hardwareentwickler das Leiterplattenlayout zeigen. Und siehe da, das RAM war eigentlich ordentlich angebunden, aber eine Datenleitung passte nicht. Statt mit einer direkten, kurzen Anbindung hing sie über eine längeren Umweg am Prozessor. Anfangs bestritt der Hardwareentwickler diesen Zusammenhang und meinte, er hätte noch nie derartige Probleme erlebt. Das stimmte auch, denn bisher hatte er nur irgendwelche Microcontroller der 8 MHz-Klasse mit internen Speichern verbaut und keinen 400 MHz-Prozessor mit fettem externen DRAM. Der Entwicklungsleiter (sehr erfahrener ASIC-Entwickler) ordnete dann aber eine entsprechende Layoutkorrektur an. Und siehe da, es gab keine komischen Abstürze und Kernel Dumps mehr. Ich räume durchaus ein, dass das Layout schon ein wirkliches Kunstwerk war, da die eine Seite der Leiterplatte als Kontaktflächen für eine Folientastatur ausgelegt war und somit als Verdrahtungslage fast wegfiel. Und es durften natürlich auch keine Durchkontaktierungen in den "Kämmen" der Kontaktflächen auftauchen. Aus Kostengründen durften auch nur insgesamt vier Lagen und erst recht keine Blind Vias eingesetzt werden. Es konnte nicht einmal eine durchgängige Masselage eingesetzt werden, da auch die Lage für Verdrahtungen verwendet werden musste. EMV-mäßig war das ein ganz heißes Eisen, und ich begleitete den Kunden auch ins EMV-Labor, wo über jedes Zehntel-dB verhandelt wurde. Ich konfigurierte dann vor Ort an den Takteinstellungen des Mikroprozessors und Ethernet-Controllers so lange herum, bis der Test gerade eben bestanden war und der Prüfingenieur das ganze absegnete. Mit anderen Anschlussleitungen hätte das schon wieder ganz anders ausgesehen, da es teilweise wirklich nur darum ging, die Resonanzen einer bestimmten Leitung zu minimieren.
Andreas S. schrieb: > Aus Kostengründen durften auch nur insgesamt vier Lagen und erst recht keine > Blind Vias eingesetzt werden. Ist doch überall das gleiche: Wir müssen sparen, koste es was es wolle... ;-) Alex schrieb: > Jetzt stellt sich mir die Frage, welche praktischen > Vorteile hat dieser Debugger gegenüber dem Atmel ICE3? In der alten Firma hatte ich früher den Atmel SAM-ICE, der war im Prinzip ein gebrandeter J-Link und auch von Segger entwickelt. Weiß nicht, ob das bei dem ICE3 auch noch so ist. Der Vorteil eines J-Link ist jedenfalls, dass der mit Controllern aller gängigen Hersteller klarkommt. Was ich auch sehr nützlich finde ist die Flash-GUI von Segger (J-Flash). Im J-Link ist je nach Modell die Lizenz enthalten, für den SAM-ICE mussten wir die damals extra kaufen. Außerdem sind die J-Link bei den gängigen IDEs meist schon vorkonfiguriert und funktionieren auf Anhieb. Laut deren Aussage auch bei Atmel Studio: https://www.segger.com/products/debug-probes/j-link/technology/ides/atmel-studio/
Martin M. schrieb: > Andreas S. schrieb: >> Aus Kostengründen durften auch nur insgesamt vier Lagen und erst recht keine > > Blind Vias eingesetzt werden. > > Ist doch überall das gleiche: Wir müssen sparen, koste es was es > wolle... ;-) Da von dem besagten Gerät > 100 k Stück vom Band fallen sollten, lohnte es sich durchaus, auch auf Einsparpotentiale im oberen Cent- oder gar Eurobereich zu achten.
Martin M. schrieb: > Weiß nicht, ob das bei dem ICE3 auch noch so ist. Nein, das AtmelICE ist eine Weiterentwicklung des JTAGICE3, völlige Atmel-Entwicklung.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.