Nabend allerseits, ich habe diese Woche einen Segger Edu Mini Erworben. Weil ich Angst hatte das Teil zu verschlucken habe ich ne anständige Platine mit USB Typ B Stecker und verschiedenen Debug Connectors (parallel) gebaut. Der Plan war die Platine 1zu1 mit den zusätzlichen Steckern nachzubauen und den uC (ein Cortex M4 MK22FN128LH10) auf die neue Platine umzulöten. Leider gibt das Teil über die USB Datalines keinen Muks von sich. Die Platine wurde von vorn bis hinten durchgemessen und sämtliche Lötstellen mehrfach überprüft, sodass ich davon ausgehe dass der Fehler hier nicht begraben liegt. Haltet ihr es tatsächlich für möglich, dass der uC beim umlöten mittels Heißluftstation krepiert ist? Ich habe bisher nur 8-bit Atmels verlötet, die aber meiner Erfahrung nach ziemlich tolrant gegenüber grober Behandlung sind. Oder kann es sein, dass er "weiß" dass er sich nichtmehr auf der Originalplatine befindet (vllt zum Schutz vor chinesischen Rückwärtsingenieuren)? Ich würde einfach gerne wissen was da passiert sein kann, bevor ich das Projekt ad acta lege. Grüße, Andreas
> Weil ich Angst > hatte das Teil zu verschlucken habe ich ne anständige Platine mit USB > Typ B Stecker und verschiedenen Debug Connectors (parallel) gebaut. Kommt mir etwas merkbefreit vor, vor dem Hintegrund das du ja auch den normalen EDU haettest kaufen koennen. > Haltet ihr es tatsächlich für möglich, dass der uC beim umlöten mittels > Heißluftstation krepiert ist? Grundsaetzlich verletzt du damit natuerlich die vom Hersteller vorgegebenen Spezifikationen bezueglich loeten, von daher waere ein defekt schon denkbar. Allerdings ist mir soetwas noch nie passiert und ich loete regelmaessig ICs um. Die Teile sind schon deutlich robuster als man so allgemein annimmt. Olaf
Olaf schrieb: > Kommt mir etwas merkbefreit vor, vor dem Hintegrund das du ja auch den > normalen EDU haettest kaufen koennen. Die Tatsache dass der normale Edu mehr als doppelt so teuer ist schien dem durchaus merkwilligen Bastler Anlass genug, einen (geplanten) halben Tag in eine seiner Lieblingtätigkeiten zu investieren. Olaf schrieb: > Allerdings ist mir soetwas noch nie passiert und > ich loete regelmaessig ICs um. Ist wie gesagt auch meine Erfahrung. Die Frage ist halt ob das bei komplexeren uCs kritischer wird.
Also um den µC würde ich mir keine Sorgen machen. Ob das auch für den Inhalt des Flash gilt, steht auf einem anderen Blatt. Möglicherweise hat sich der verabschieded? Schau doch erst mal, ob wenigstens der Quarz schwingt, und ob der µC seine Kernspannung (falls vorhanden) erzeugt.
Angehängte Dateien:
-
DS1Z_QuickPrint4.png
14 KB
Quarz ist keiner vorhanden, scheinbar wird der interne Oszillator + PLL verwendet. Oha schrieb: > ob der µC > seine Kernspannung (falls vorhanden) erzeugt. Ich verstehe leider nicht was genau du damit meinst. 3.3V sind auf jeden Fall an allen Vdd Pins vorhanden. Ich habe gerade festgestellt dass auf dem RESET_b pin obiges Rechtecksignal anliegt. Laut RefManual wird der Controller für mind. 128 Takte im Reset (low) gehalten um den Flash zu initialisieren. Damnach steckt das Ding wohl in einer Resetschleife?
Andreas F. schrieb: > Oder kann es sein, dass er "weiß" dass er sich nichtmehr auf der > Originalplatine befindet (vllt zum Schutz vor chinesischen > Rückwärtsingenieuren)? Ich müsste mal die J-Link Kollegen fragen, aber ich wüsste nicht, dass wir etwas derartiges machen. Den Schutz gegen die chinesischen Klone machen wir anders. Garantie/Gewährleistung wird dabei natürlich schwer, aber ich denke, dass wusstest du vorher schon ;-).
Andreas F. schrieb: > Haltet ihr es tatsächlich für möglich, dass der uC beim umlöten mittels > Heißluftstation krepiert ist? Ohne genaue Temperaturkontrolle hätte ich grosse Bedenken so ein Ding zerstörungsfrei zu löten/auszulöten. Einfach heizen bis das Zinn schmilzt ist eine Brute-Force- Methode die vermutlich leicht etwas zerstört. Zudem heutzutage mit höheren Temperaturen gelötet werden muss wegen bleifreiem Zinn.
> Einfach heizen bis das Zinn schmilzt ist eine Brute-Force- > Methode die vermutlich leicht etwas zerstört. Noe. Es entspricht meiner Erfahrung das dort normalerweise nichts passiert. Ich will nicht sagen das dies nicht mal irgendwann vorkommen kann, aber es ist eine seltene Ausnahme. Olaf
> Oder kann es sein, dass er "weiß" dass er sich nichtmehr auf der > Originalplatine befindet (vllt zum Schutz vor chinesischen > Rückwärtsingenieuren)? Wie sollte er das feststellen können, wenn du die Platine 1:1 nachgebaut hast ? Denke jetzt nicht, dass der irgendwelche Impedanzen oder dergleichen misst, so dass irgendwelche Leitungslängen oder Bauteile beachtet werden müssten. Ich würde einfach auf einen Hardwarefehler tippen, falsche Belegung oder was vergessen , oder das Teil ist tatsächlich defekt gegangen.
Patrick R. schrieb: > oder das Teil ist tatsächlich defekt gegangen. Man kann ja auch bei solchen "einfachen" (will heissen technologisch primitiven) Lötvorgängen mal eine Lötbrücke erzeugen die man nicht sieht (nämlich unter dem Chip). Ähnlich verhält es bei solchen Aktionen mit lose aufliegenden Pins die trotz aller Löt-Bemühungen nicht mit dem Pad kontaktieren (wollen).
Til S. schrieb: > Andreas F. schrieb: >> Oder kann es sein, dass er "weiß" dass er sich nichtmehr auf der >> Originalplatine befindet (vllt zum Schutz vor chinesischen >> Rückwärtsingenieuren)? > > Ich müsste mal die J-Link Kollegen fragen, aber ich wüsste nicht, dass > wir etwas derartiges machen. Den Schutz gegen die chinesischen Klone > machen wir anders. Garantie/Gewährleistung wird dabei natürlich schwer, > aber ich denke, dass wusstest du vorher schon ;-). Also, wir machen so etwas nicht als Kopierschutz, aber wenn die Schaltung nicht zu 100% nachgebaut ist, kann es natürlich sein, dass der J-Link nicht mehr funktioniert. Und wie schon erwähnt wurde, wird der Chip durch das zweimal aufheizen nicht besser. Die Chance den Chip dabei zu zerstören ist ziemlich groß. Vielleicht ist es einfacher eine Platine zu erstellen auf der die J-Link EDU Mini Platine Huckepack drauf sitzt? Oder einfach die 42,- Euro mehr für einen J-Link EDU ausgeben ;-).
:
Bearbeitet durch User
Til S. schrieb: > Oder einfach die 42,- Euro mehr für einen J-Link EDU ausgeben ;-). Ja, das ist er wieder, der Gedanke. --> Sparen, koste es was es wolle,
> J-Link nicht mehr funktioniert. Und wie schon erwähnt wurde, wird der > Chip durch das zweimal aufheizen nicht besser. Die Chance den Chip dabei Das kann er ja prüfen. Einfach nochmal von der Eigenbauplatine runternehme und auf die Originalplatine drauf löten. :-) Olaf
Olaf schrieb: > Einfach nochmal von der Eigenbauplatine > runternehme und auf die Originalplatine drauf löten. :-) ROFL. YMMD. Olaf schrieb: > Noe. Es entspricht meiner Erfahrung das dort normalerweise nichts > passiert.
Andreas F. schrieb: > Oder kann es sein, dass er "weiß" dass er sich nichtmehr auf der > Originalplatine befindet (vllt zum Schutz vor chinesischen > Rückwärtsingenieuren)? Eher nicht. Vermutlich eher ein "Kopierfehler". Woher weisst Du dass Du die Originalplatine richtig kopiert hast? Hast Du ALLE Traces der Originalplatine gegen Deine gecheckt oder wurde da evtl. die eine oder andere Leitung vergessen? Naja, um ~€18 für einen Ersatzadapter zu sparen viel Aufwand^^
Til S. schrieb: > Garantie/Gewährleistung wird dabei natürlich schwer, > aber ich denke, dass wusstest du vorher schon ;-). Schade, hatte auf Ersatzteile in Form von .bin oder noch besser .c files gehofft :-D Til S. schrieb: > Vielleicht ist es einfacher eine Platine > zu erstellen auf der die J-Link EDU Mini Platine Huckepack drauf sitzt? Das ist tatsächlich zuerst der Plan gewesen.. Hinterher ist man wohl immer schlauer. Danke für die Info, das hilft schonmal weiter den Kopierschutz auszuschließen. Oha schrieb: > Ob das auch für den Inhalt des Flash gilt, steht auf einem anderen > Blatt. Das kam mir tatsächlich noch nicht in den Sinn. Habe zwar auch schon öfter ICs umgelötet, aber noch die geprogrammte uCs. Unterm Strich können wir also festhalten dass das Board wohl nurnoch (bestenfalls) als Development board zu verwenden ist? Frickelfritze schrieb: > ..hätte ich grosse Bedenken.. ...eine Brute-Force- > Methode die vermutlich leicht etwas zerstört.... ...heutzutage...bleifreiem > Zinn. Frickelfritze schrieb: > Ja, das ist er wieder, der Gedanke. > > --> Sparen, koste es was es wolle, Deine Beiträge erhöhen meinen Puls. Offenbar hast du nichts von Substanz beizutragen also bitte ich dich dich woanders wichtig zu machen.
Andreas F. schrieb: > Deine Beiträge erhöhen meinen Puls. Manche Leute können einfach die Wahrheit nicht vertragen. Ich empfehle dir Olafs Tip zur Rettung der Situation.
Til S. schrieb: > Den Schutz gegen die chinesischen Klone > machen wir anders. Naja, das beim Edu einmal am Tag diese "No commercial use only" Nervmeldung hochpoppt ist eher ein Argument für den ChinaClone. Was Segger da geritten hat wird mir ewig unklar bleiben. Gerade im Hobbybereich haben sie sich damit kaum Freunde gemacht.
EyeRoll schrieb: > Naja, das beim Edu einmal am Tag diese "No commercial use only" > Nervmeldung hochpoppt ist eher ein Argument für den ChinaClone. Naja, wer eine zeitlang damit arbeitet wird dennoch die Vorteile der Segger Hard- und Software zu schätzen lernen. Dann lieber einmal (Hoch-)Poppen pro Tag. Aber auf das Anfertigen meiner eigenen J-Link Platine würde ich dann doch lieber gerne verzichten ;-)
Frickelfritze schrieb: > Naja, wer eine zeitlang damit arbeitet wird dennoch die > Vorteile der Segger Hard- und Software zu schätzen lernen. > > Dann lieber einmal (Hoch-)Poppen pro Tag. Machen ja nur die Edu's, die hier auf Arbeit (zum Glück) nicht.
EyeRoll schrieb: > Was Segger da geritten hat wird mir ewig unklar bleiben. Gerade im > Hobbybereich haben sie sich damit kaum Freunde gemacht. Probleme kann man haben! Sollen sie gleich alles verschenken? Ich find die Meldung super, da weiß man wenn 24 Uhr durch ist und man vielleicht mal fertig machen sollte.
Gibt es eigentlich irgendwo eine Übersicht, wo die Vorteile der J-Link Edus gegenüber den ST-Links liegen, wenn man die Plattform-Unterstützung außen vor läßt?
> Gibt es eigentlich irgendwo eine Übersicht, wo die Vorteile der J-Link
Nach meinen Erfahrungen vor allem in der Zuverlaessigkeit.
Andere Dinge wie Netzwerkanbindung und mehrere J-Links an einem PC
wollen wir erstmal wohlwollend ignorieren. .-)
Olaf
Also andersherum: Wenn man keine Netzwerkanbindung braucht, zwei ST-LinkV2 am selben PC funktionieren und auch kein Grund zur Klage aufgrund der Zuverlässigkeit besteht - gibt es auch keinen Grund zum J-Link EDU?
:
Bearbeitet durch User
Dr. Sommer schrieb: > Ich find die Meldung super, da weiß man wenn 24 Uhr durch ist und man > vielleicht mal fertig machen sollte. ROFL. Die Idee bei der Meldung ist ja, dass niemand im kommerziellen Einsatz sagen kann, er hätte nichts von der Limitierung gewusst. Und ich denke einmal am Tag die Meldung wegklicken ist zumutbar. Dafür bekommt man für den gleichen Preis wie der China Klon Qualitäts Hard- und Software und unterstützt nicht illegale Aktivitäten. Walter T. schrieb: > Also andersherum: Wenn man keine Netzwerkanbindung braucht, zwei > ST-LinkV2 am selben PC funktionieren und auch kein Grund zur Klage > aufgrund der Zuverlässigkeit besteht - gibt es auch keinen Grund zum > J-Link EDU? In dem Fall würde ich sagen: Never change a running system. Du kannst aber auch testweise einen onboard ST-Link zu einem J-Link umflashen und es selber ausprobieren: https://www.segger.com/products/debug-probes/j-link/models/other-j-links/st-link-on-board/ Zurückflashen auf die ST-Link Firmware geht natürlich auch. Der J-Link ist im Allgemeinen zuverlässiger und schneller als der ST-Link und wird von unseren Tools wie z.B. Embedded Studio und SystemView unterstützt. Aber es ist wie überall im Leben, es gibt nicht das beste Werkzeug sondern nur das beste Werkzeug für eine bestimmte Aufgabe.
Til S. schrieb: > Du kannst aber auch testweise einen onboard ST-Link zu einem J-Link > umflashen und es selber ausprobieren: Da stellt sich mir spontan die naive Frage: Ist es (legal) möglich meinen EDU MINI neu zu flashen, im Fall dass nur der Flash kompromittiert ist?
Til S. schrieb: > Du kannst aber auch testweise einen onboard ST-Link zu einem J-Link > umflashen Nein. Man kann nur einen ST-Link v2.1 umflashen, was die meisten existierenden Geräte (v2.0) erst mal ausschliest!
Andreas F. schrieb: > Ist es (legal) möglich > meinen EDU MINI neu zu flashen, im Fall dass nur der Flash > kompromittiert ist? Wenn er nicht mehr läuft weil der Flash hinüber ist dann wird der Bootloader (der wohl nicht in Stein gemeisselt ist) auch hinüber sein. Wie willst du ihn dann neu flashen ohne Binary?
Walter T. schrieb: > gibt es auch keinen Grund zum > J-Link EDU? Der J-Link ist auch wesentlich schneller. Wenn man viel debuggt geht einem die Bedenksekunde vom ST-Link bei jedem einzelnen Debugschritt doch irgendwann auf die Nerven. Und zumindest ich hatte jede Menge Probleme mit der Zuverlässigkeit - selbst mit der ST-eigenen Software verweigert der ST-Link bei mir oft den Dienst, und man kann sich zuverlässig aussperren indem man die "WFI"-Instruktion aufruft (ja es gibt Workarounds, aber beim J-Link besteht das Problem gar nicht erst). Der ST-Link auf dem F7 Discovery wollte bei mir partout nicht funktionieren, mit etwas Rumlöten hab ich das mit dem J-Link verbunden, der sofort ging.
Til S. schrieb: > Du kannst aber auch testweise einen onboard ST-Link zu einem J-Link > umflashen und es selber ausprobieren: Das sieht super aus - das habe ich glatt übersehen. Frickelfritze schrieb: > Nein. Man kann nur einen ST-Link v2.1 umflashen, Was mir zum Testen allerdings völlig ausreicht. Das heißt, daß jedes Nucleo-Board funktioniert. Und wer weiß - vielleicht verpflanze ich dann die MCU von meinem Nucleo-Board in den ST-LinkV2/ISOL. :-)
> Was mir zum Testen allerdings völlig ausreicht. Das heißt, daß jedes > Nucleo-Board funktioniert. Und wer weiß - vielleicht verpflanze ich dann > die MCU von meinem Nucleo-Board in den ST-LinkV2/ISOL. :-) Aber nicht wieder mit Heißluft auslöten ;-)
Til S. schrieb: > und wird von unseren Tools wie z.B. Embedded Studio und > SystemView unterstützt Moment mit dem J-Link EDU kann man Profiling auf der Zielplattform durchführen? Ich dachte, das sei den teuren Trace-Tools vorbehalten. Jetzt wird der Abend wohl erst einmal damit vorbeigehen, die Doku von SystemView zu studieren.
Walter T. schrieb: > Moment mit dem J-Link EDU kann man Profiling auf der Zielplattform > durchführen? Ich dachte, das sei den teuren Trace-Tools vorbehalten. > Jetzt wird der Abend wohl erst einmal damit vorbeigehen, die Doku von > SystemView zu studieren. Du musst API Trace und Instruction Trace unterscheiden. SystemView macht API Trace, d.h. wenn du instrumentalisierte Software wie embOS hast, siehst du im SystemView jeden einzelnen API Aufruf mit Profiling Informationen usw. Kann man hier in dem Video ab 38:52 sehen: https://www.youtube.com/watch?v=PHcjYS7OBIs Instruction Trace geht nur mit dem J-Trace Pro (bzw. auch mit dem J-Link, aber dann kein Real-Time Streaming Trace): https://www.youtube.com/watch?v=hl7WdxnD9k0 Andreas F. schrieb: > Da stellt sich mir spontan die naive Frage: Ist es (legal) möglich > meinen EDU MINI neu zu flashen, im Fall dass nur der Flash > kompromittiert ist? Leider nicht legal und auch technisch nicht möglich. Ich schicke dir aber einen neuen J-Link EDU Mini kostenlos zu, wenn du damit ein Unboxing Video auf YouTube machst ;-).
Andreas F. schrieb: > ein Cortex M4 MK22FN128LH10 Andreas F. schrieb: > Quarz ist keiner vorhanden, scheinbar wird der interne Oszillator + PLL > verwendet. Tja. Pech gehabt. Guck zur Unterhaltung mal in's refManual zu diesem Chip. Da wirst du sehen, daß die Leute von Freescale sich einen abgebrochen haben, um den internen 48 MHz RC-Oszillator so hinzukriegen, daß der Chip am USB überhaupt benutzbar ist. Selbst wenn man nen Quarz anschließt, wird das nicht besser, denn die interne FLL will erstens ne Referenz von 32..39 kHz haben und sie liefert einen derart jitternden Takt, daß man damit den USB-Core eben nicht betreiben kann. Eine Sch...konstruktion! Und nun hast du den Chip richtig schön heiß gemacht und damit womöglich den RC-Oszillator soweit verstimmt, daß die (von mir vermutete) Werkskalibrierung weggelaufen ist. Für dich hätte ich allenfalls den Rat, dir irgend ein passendes billiges ST-Evalboard mit einem ST-Link-OB zu besorgen, wo man ggf. den Flash-Teil herausbrechen kann und mit der Software, die du bei Segger finden kannst, zum JLink-OB umzuflashen. Das dürfte billiger sein als nochmal denselben Fehler zu machen. Andreas F. schrieb: > Weil ich Angst > hatte das Teil zu verschlucken habe ich ne anständige Platine mit USB > Typ B Stecker und verschiedenen Debug Connectors (parallel) gebaut. Mannomann, du mußt aber ne ziemlich große Klappe haben... W.S.
Til S. schrieb: > Leider nicht legal und auch technisch nicht möglich. Ich schicke dir > aber einen neuen J-Link EDU Mini kostenlos zu, wenn du damit ein > Unboxing Video auf YouTube machst ;-). Also da bin ich sofort dabei! Hast ne PN. W.S. schrieb: > Guck zur Unterhaltung mal in's refManual zu diesem Chip. Hab ich gemacht, aber auh hier gab es schon entsprechende Threads. Gegenfrage: Wäre dann nicht trotzdem eine von Null verschiedne Spannung an D+ oder D- messbar? Und wie erklärt das den mutmaßlichen Reset Loop? W.S. schrieb: > Mannomann, du mußt aber ne ziemlich große Klappe haben... Check ich nicht. Der Edu Mini ist tatsächlich kaum größer als mein erstes Daumengleid. Wenns funktioniert hätte wärs doch ein tolles Projekt gewesen ¯\_(ツ)_/¯ Von der Idee mit dem ST-Link halte ich nichts. Der Edu Mini ist doch spottbillig. Mir war schon klar dass er dabei abrauchen kann, dann ists beim nächsten Mal halt nur ne Adapterplatine.
Andreas F. schrieb: > Til S. schrieb: >> Leider nicht legal und auch technisch nicht möglich. Ich schicke dir >> aber einen neuen J-Link EDU Mini kostenlos zu, wenn du damit ein >> Unboxing Video auf YouTube machst ;-). > > Also da bin ich sofort dabei! Hast ne PN. Ok, lass ich gleich raus schicken, deine Adresse hast du mir ja schon geschickt. Dein YouTube Video werden wir dann auf unserem Twitter und Facebook Account verlinken. Du hattest mir noch geschrieben, dass du an deiner Hochschule Werbung machen möchtest. Wir haben ein University Programm, mit dem wir Hochschulen/Universitäten unterstützen und z.B. Hard-/und Software sponsern können. Falls an deiner Hochschule Interesse besteht, können wir auch darüber mal reden. Btw. Ich darf hier leider noch nicht zuviel spoilern, aber wir haben bald eine schöne Überraschung für die Hobby Community. Da freue ich mich persönlich schon mega drauf.
Wo hier gerade über J-Link diskutiert wird: Hat jemand zufällig einen Tipp für folgende Situation: Ich habe bei der Codeerzeugung per CubeMX versehentlich das Debuginterface abgeschaltet. Wie schaffe ich es mit dem J-Link wieder dran zu kommen. Mit dem ST-Link geht es per "connect under reset"
Til S. schrieb: > Btw. Ich darf hier leider noch nicht zuviel spoilern, aber wir haben > bald eine schöne Überraschung für die Hobby Community. Da freue ich > mich persönlich schon mega drauf. Du hast es echt drauf, einen Spannungsbogen zu erzeugen... Kannst Du grob sagen, wann "bald" ungefähr sein wird? OT-Frage: Welche Hardwareversion hat der J-Link derzeit? Hat der EDU noch 10.1? http://forum.segger.com/index.php?page=Thread&postID=12795 Ich mußte nun leider lesen, daß mein V8 die M4 (und M7 sowieso) nicht unterstützt und will über Weihnachten mal etwas mit irgendeinem Board spielen. Da muß ich die Lieferzeit ja berücksichtigen.
Lutz schrieb: > OT-Frage: Welche Hardwareversion hat der J-Link derzeit? Hat der EDU > noch 10.1? Ja genau, 10.1 ist noch aktuell.
Andreas F. schrieb: > Til S. schrieb: >> Leider nicht legal und auch technisch nicht möglich. Ich schicke dir >> aber einen neuen J-Link EDU Mini kostenlos zu, wenn du damit ein >> Unboxing Video auf YouTube machst ;-). > > Also da bin ich sofort dabei! Hast ne PN. Und hier das Resultat :-) https://www.youtube.com/watch?v=ZfBEw6pamBE Danke an Andreas!
Til S. schrieb: > Du kannst aber auch testweise einen onboard ST-Link zu einem J-Link > umflashen und es selber ausprobieren: Danke für den Tipp! Ich habe es mal ausprobiert (Grund war Neugier, Anlaß ein bekanntes Problem des ST-Links in Verbindung mit EmBitz unter Windows 10). Was mir bei der "User Experience" des J-Link mit dem GDB-Server von Segger direkt besser gefällt, ist daß sich Verzögerungsschleifen schnell und sauber "übersteppen" lassen. Beim ST-Link V2/1 hatte er sich daran immer verschluckt, so daß man sich schon gewohnheitsmäßig Delay-Schleifen durch das Setzen eine Breakpoints unmittelbar danach beholfen hat. Gefühlt geht das Durch"steppen" leicht langsamer unter EmBitz, wobei der Vergleich etwas hinkt, da es sich um unterschiedliche Rechner handelt (Windows 10 vs. Windows 7). Gefühlt braucht der Segger-GDB-Server auch etwas länger zum Start, so daß es insgesamt vom fertigen Build bis zum ersten Breakpoint ein klein wenig länger dauert - aber noch nicht so, daß es stört. Vielleicht liegt das auch daran, daß die bunt durchrennenden Statusbalken jederzeit das Gefühl vermitteln, daß hier auch etwas passiert. Alles in allem bin ich vom Ergebnis meines vorläufen Umstiegs weder positiv noch negativ überrascht.
Walter T. schrieb: > Danke für den Tipp! Gerne. Vielleicht habe ich es überlesen, welche IDE benutzt du? Im Prinzip ist das Benutzen von Breakpoints und Single Steppen mit dem J-Link durch die Flash-Breakpoints schon sau schnell. Aber die IDE kann da natürlich auch noch Einfluss haben. Noch besser wird es mit IDEs, die nativen J-Link Support haben (der GDB Server fällt dann weg). Das haben heutzutage die meisten IDEs Du könntest zum Vergleich mal Embedded Studio probieren. Ich benutze es die meiste Zeit hier und Debug Session starten geht damit in gefühlt < 1 sec.
Reset schrieb: > Wo hier gerade über J-Link diskutiert wird: Hat jemand zufällig > einen > Tipp für folgende Situation: > > Ich habe bei der Codeerzeugung per CubeMX versehentlich das > Debuginterface abgeschaltet. Wie schaffe ich es mit dem J-Link wieder > dran zu kommen. Mit dem ST-Link geht es per "connect under reset" Die Bottpins so umkonfigurieren, dass der interne bootloader lädt und dann via swd reflashen, dann bootpins wieder zurück.
Jetzt sind fast drei Wochen seit meinem ersten J-Link-Edu-Test herum, also kann ich etwas mehr als den ersten Eindruck schildern. Til S. schrieb: > Gerne. Vielleicht habe ich es überlesen, welche IDE benutzt du? Ich nutze EMBitz. Ursprünglicher Grund dazu war eine hervorragend funktionierende Migration von Projekten aus der CooCox IDE. Jetzt komme ich --zwei Monate später--, bis auf Kleinigkeiten damit gut klar und bleibe erst einmal bei meinem laufenden Projektchen dabei. Ich habe zum Vergleich zwei Nucleo-Boards (STM32F103RB und STM32F446RE) jeweils mit ähnlicher Firmware (gleiches Projekt, für die MCUs natürlich unterschiedlich Kompilierzweige), ersteres mit ST-LinkV2/1-Firmware, letzteres mit J-Link-EDU-Firmware getestet. Diesmal auch am gleichen Rechner und mit der Stoppuhr. Vom "Debug starten" bis zu "bin in main() und warte aufs loslaufen" vergeht bei beiden Varianten ziemlich genau die gleiche Zeit. Das Durchsteppen geht bei der J-Link-Firmware schneller, und diese schafft es auch, im Gegensatz zur ST-Link-V2/1-Firmware, Warteschleifen ohne Timeout zu überleben. Es dauert zwar, aber ich kann irgendwann das Programm wieder fortführen. Beim ST-Link komme ich, wenn ich mit Einzelschritt in ein eine Warteschleifen-delay()-Funktion laufe, dort nicht mehr ohne Reset heraus. Momentan habe ich das "produktiv" verwendete Eval-Board allerdings wieder auf die ursprüngliche ST-Link-V2/1-Firmware zurückgeflasht. Hintergrund ist der, daß ich es mit der J-Link-Firmware nicht schaffe, Variablen zu ändern, ohne das Programm anzuhalten. Oder habe ich irgendeine Option übersehen, mit der das auf beim J-Link Edu funktioniert?
Walter T. schrieb: > Hintergrund ist der, daß ich es mit der J-Link-Firmware nicht schaffe, > Variablen zu ändern, ohne das Programm anzuhalten. Oder habe ich > irgendeine Option übersehen, mit der das auf beim J-Link Edu > funktioniert? Ich denke, dass ist eher eine Frage der IDE. Ich muss gestehen, dass ich mit EMBitz noch nie etwas gemacht habe. Prinzipiell kann man ja beim Cortex-M Speicher lesen und schreiben während der Core läuft. Das benutzen wir z.B. beim J-Link für SystemView bzw. das RTT Protokoll. D.h. ich gehe davon aus, das du z.B. mit dem J-Link Commander problemlos Variablen beschreiben kannst während der Core läuft. Das wäre natürlich nur, um die J-Link Seite zu testen. Du möchtest das wahrscheinlich eher in der IDE im Watch Fenster machen? Ich habe das gerade mit Embedded Studio auf einem STM32F4 getestet und wie erwartet funktioniert alles ohne Probleme. Es gibt auch keine Einschränkungen beim J-Link EDU. Man müsste sich also mal genauer anschauen, was EMBitz da macht.
Til S. schrieb: > D.h. ich gehe davon aus, das du z.B. mit dem J-Link Commander problemlos > Variablen beschreiben kannst während der Core läuft. Das wäre natürlich > nur, um die J-Link Seite zu testen. Du möchtest das wahrscheinlich eher > in der IDE im Watch Fenster machen? Ich habe das gerade mit Embedded > Studio auf einem STM32F4 getestet und wie erwartet funktioniert alles > ohne Probleme. Sowie ich es verstehe, ist der J-Link Commander per Kommandozeile zu bedienen. Gibt es bei Eurem Embedded Studio auch eine elegante Möglichkeit, zur Laufzeit Register und Variablen zu verändern, wie es die IAR-IDE mit ihrem Live-Watch bietet?
Angehängte Dateien:
-
ES.png
6,4 KB
m.n. schrieb: > Sowie ich es verstehe, ist der J-Link Commander per Kommandozeile zu > bedienen. Korrekt, das hatte ich nur erwähnt um zu zeigen, wie man direkt mit dem J-Link ohne IDE schnell was testen kann. m.n. schrieb: > Gibt es bei Eurem Embedded Studio auch eine elegante > Möglichkeit, zur Laufzeit Register und Variablen zu verändern, wie es > die IAR-IDE mit ihrem Live-Watch bietet? Klar, nichts einfacher als das. Einfach im Watch-Window auswählen, wie oft es aktualisiert werden soll. Und Schreiben halt einfach drauf klicken und reinschreiben ;-). CPU Register können nicht ausgelesen werden während der Cortex-M läuft. D.h. dafür müsste man jedesmal den Core anhalten was eher suboptimal wäre. Im Register-Window können auch SFRs angezeigt werden. Weil SFRs in der Regel Memory Mapped sind, könnte man diese zur Laufzeit auslesen. Aber je nach Peripherie kann das zu Problemen führen. Daher machen wir das nicht. Wer das dennoch haben möchte, kann sich natürlich eine entsprechende Expression im Watch-Window hinzufügen.
Hallo Til, weil du gerade mit liest habe ich mal ne Frage der nicht zum Thread passt. Bitte dafür um Nachsicht. Warum hat das Embedded Studio keine Unterstützung für die LPC11Cxx Serie von NXP? Alle anderen sind doch dort auch vertreten?
Til S. schrieb: > Im Register-Window können auch SFRs angezeigt werden. > ... > Wer das dennoch haben möchte, kann sich natürlich eine > entsprechende Expression im Watch-Window hinzufügen. Schade, denn das ist nicht praxistauglich.
m.n. schrieb: > Schade, denn das ist nicht praxistauglich. Ja, das ist etwas umständlich und würde ich persönlich auch eher seltener benutzen. Aber wie gesagt, das leider ein technisch prinzipielle Einschränkung und nicht durch Embedded Studio verursacht. Ich gebe das aber an die Kollegen mal weiter. Vielleicht fällt denen noch etwas schlaues dazu ein. Jürgen L. schrieb: > Bitte dafür um Nachsicht. Warum hat das Embedded Studio keine > Unterstützung für die LPC11Cxx Serie von NXP? Alle anderen sind doch > dort auch vertreten? Kein Problem. Was meinst du mit Unterstützung? Geht es dir darum dafür ein Projekt automatisch generieren zu können, indem die device spezifischen CMSIS Dateien sind? Dafür sind wir immer auf die Chiphersteller angewiesen, die eigentlich die CMSIS Pakete für ihre Devices zur Verfügung stellen sollten. Davon abgesehen kannst du aber Embedded Studio mit jedem Cortex-M verwenden. Du brauchst halt nur eine passende Vector Table und ein Linker File. Aber generell, wenn irgendein Device fehlt, bitte bei uns melden, und wir können dann schauen, ob wir dafür ein Package zur Verfügung stellen können. In dem Fall gebe ich das gleich einfach mal an die Kollegen nebenan weiter.
Ok, also...wir haben zwar im Embedded Studio bereits ein Package für die NXP LPC11xx Serie aber da sind noch keine LPC11Cxx Device mit drin. Leider gab es noch kein neueres CMSIS Device Family Package von NXP (aus diesen generieren wir die Embedded Studio Packages). Aber wie gesagt, das heißt nicht, dass man Embedded Studio nicht mit diesem Device benutzen kann! Man kann sich nur nicht so bequem ein Projekt generieren lassen, wo schon alles drin ist.
Til S. schrieb: > Aber wie gesagt, das leider ein technisch > prinzipielle Einschränkung und nicht durch Embedded Studio verursacht. > Ich gebe das aber an die Kollegen mal weiter. Vielleicht fällt denen > noch etwas schlaues dazu ein. Die Einschränkung betrifft letztlich nur einen Bruchteil von (Status-) Registern der SFRs. Damit muß man leben. Aber der Hauptteil der SFRs sind Konfigurationsregister, die man nach Herzenslust lesen und beschreiben kann, was bei IAR und Keil ganz transparent auch bitweise angeboten wird. Solange es sich wie bei den Cortex M um Mikrocontroller handelt, ist die Peripherie des Chips und damit das Debugging enorm wichtig. Diese Funktion zu implmentieren ist aber sicherlich auch ein Haufen Arbeit! Gut am Embedded Studio finde ich, daß ich damit IAR-Projekte im Nu verwenden und bearbeiten kann. Insbesondere, wenn die 32 K Grenze der kostenfreien IDE gesprengt wird, kann nathlos "weitergeschafft" werden. Zudem ist der Programmstart sehr fix.
m.n. schrieb: > Aber der Hauptteil der SFRs sind Konfigurationsregister, die man nach > Herzenslust lesen und beschreiben kann, was bei IAR und Keil ganz > transparent auch bitweise angeboten wird. > Solange es sich wie bei den Cortex M um Mikrocontroller handelt, ist die > Peripherie des Chips und damit das Debugging enorm wichtig. > Diese Funktion zu implmentieren ist aber sicherlich auch ein Haufen > Arbeit! Ich denke du probierst das erst mal aus, das was du willst ist alles implementiert. Das einzige was verhindert wird ist, die Peripherie zu ändern ohne! dass das Programm auf einem Debugbreak steht. Til S. schrieb: > Leider gab es noch kein neueres CMSIS Device Family Package von NXP (aus > diesen generieren wir die Embedded Studio Packages). Ist doch bei Rowley auch schon immer drin? Oder macht ihr das ernsthaft alles doppelt?
Jürgen L. schrieb: > Ich denke du probierst das erst mal aus, das was du willst ist alles > implementiert. Dann sag mir doch bitte, was ich einstellen muß, um z.B. das Register TIM8_CCMR1 anzuzeigen einschließlich der Bitfelder ICS1S IC1PSC IC1F ICS2S IC2PSC IC2F und das bitteschön, während der Prozessor läuft. Änderungen an den Bitfeldern sollen direkt ausgeführt werden.
m.n. schrieb: > Aber der Hauptteil der SFRs sind Konfigurationsregister, die man nach > Herzenslust lesen und beschreiben kann, was bei IAR und Keil ganz > transparent auch bitweise angeboten wird. Während der Core läuft? Geht das tatsächlich? Ich bin mir da gerade nicht so sicher bzw. müsste das gleich testen. Ich denke auch bei IAR muss ich die Debug Session pausieren damit das Register Window aktualisiert wird und ich dort einen Wert ändern kann. Ich lasse mich da aber gerne eines besseren belehren. Jürgen L. schrieb: > Ist doch bei Rowley auch schon immer drin? Oder macht ihr das ernsthaft > alles doppelt? Die Packages sind tatsächlich getrennt, da CrossWorks unabhängig von SEGGER Embedded Studio weiterentwickelt wird.
Til S. schrieb: > Btw. Ich darf hier leider noch nicht zuviel spoilern, aber wir haben > bald eine schöne Überraschung für die Hobby Community. Da freue ich > mich persönlich schon mega drauf. Ist da mittlerweile schon was offizielles raus und ich habe es übersehen?
Til S. schrieb: > Während der Core läuft? Geht das tatsächlich? Ich bin mir da gerade > nicht so sicher bzw. müsste das gleich testen. Das geht soweit, daß man während irgendein Programm läuft z.B. einen Timer per RCC-Bit freigibt, ihn konfiguriert, zum Schluß sein enable-Bit setzt und zusieht, wie er läuft. Capture-Funktion vergessen? Passende Bits setzen und Capture-Register ansehen, ob alles läuft.
Angehängte Dateien:
-
Segger.png
310 KB
Til S. schrieb: > Während der Core läuft? Geht das tatsächlich? Ich bin mir da gerade > nicht so sicher bzw. müsste das gleich testen. Ok, wir haben uns das gerade nochmal bei IAR und Embedded Studio angeschaut und beide IDEs verhalten sich gleich: 1. Das Register Window wird nicht periodisch upgedated während der Core läuft. 2. Aber SFRs schreiben während der Core läuft funktioniert bei beiden IDEs. Tobias schrieb: > Ist da mittlerweile schon was offizielles raus und ich habe es > übersehen? Nein, noch nicht aber kommt jetzt hoffentlich die nächsten Tage quasi als Weihnachtsgeschenk. Sagen wir mal so, wen bis jetzt die Trial Limitierungen unserer Software gestört haben, wird sich freuen ;-).
m.n. schrieb: > Jürgen L. schrieb: >> Ich denke du probierst das erst mal aus, das was du willst ist alles >> implementiert. > > Dann sag mir doch bitte, was ich einstellen muß, um z.B. das Register > TIM8_CCMR1 anzuzeigen einschließlich der Bitfelder Eine Antwort kommt wohl nicht mehr. Ich habe noch einmal herumgespielt: ohne Erfolg. Til S. schrieb: > 2. Aber SFRs schreiben während der Core läuft funktioniert bei beiden > IDEs. Schön. Aber der Weg bei Eurem Embedded Studio ist wohl steinig. Die 8-stelligen hex-Adressen der Peripherie habe ich leider nicht im Kopf. Beim IAR klicke ich mir das gesuchte Register und darin die betreffenden Bits an und setze den gewünschten Wert: direkt und schnell. Wenn ich TIM8_CNT betrachten will, dann schreibe ich unter Live Watch: TIM8_CNT und fortan wird mir der aktuelle Zählerstand fortlaufend angezeigt. Da kommt Freude auf!
Angehängte Dateien:
-
sfr.png
16 KB
m.n. schrieb: > Schön. Aber der Weg bei Eurem Embedded Studio ist wohl steinig. Jain, wenn es ein passendes SVD File gibt werden die SFRs im Register Window bitweise angezeigt und können dort verändert werden. Also genauso wie bei IAR. Ein Live-Watch für SFRs gibt es tatsächlich so noch nicht. Aber ich stimme dir zu, wir sollten auch so etwas haben, das ist echt praktisch. Danke für dein Feedback!
Angehängte Dateien:
-
sfr.png
18 KB
Til S. schrieb: > Ein Live-Watch für SFRs gibt es tatsächlich so noch nicht. Wie gut, dass ich unsere eigenen Tools so gut kenne... ;-). Geht natürlich doch: Man kann im Register-Window einfach per Rechts-Klick auf ein SFR mit "Add To Watch" ein SFR zum Watch-Window hinzufügen. Das Watch-Window und damit das SFR können dann auch als Live Update dargestellt werden. In dem Screenshot habe ich den Cortex-M SysTick Counter hinzugefügt und lasse ihn mir 2x die Sekunde aktualisieren. Im Projekt muss dafür "Access Variables Within Memory Map Only" auf "No" gestellt sein. Per Default ist das auf "Yes" eingestellt (den Grund dafür kann ich gerne nochmal separat erklären).
Kann man dieses Embedded Studio auch mit Rust-Programmen verwenden? Ich habe bisher meine Rust-Programme auf einem STM32F103 mit Ozone und einem NRF51 Dev Board mit integriertem J-Link debuggt. Funktionierte ganz ok. Werte von Variablen im Watch-Window konnte der aber nicht anzeigen. Wohl weil Ozone die Rust-Datentypen nicht kennt? Nach einem Firmware-Update weigert sich Ozone aber mit dem STM32 zusammen zu arbeiten. Wohl weil das mit dem NRF51-J-Link nicht erlaubt ist? Brauche ich wohl einen richtigen J-Link? Mit dem GDB und STLink war ich überhaupt nicht zufrieden, da funktionierte Ozone viel besser.
cody schrieb: > Kann man dieses Embedded Studio auch mit Rust-Programmen verwenden? Man kann zwar in Embedded Studio andere Compiler einbinden aber das habe ich bis jetzt auch nur mit anderen ARM C Compilern gemacht. cody schrieb: > Nach einem Firmware-Update weigert sich Ozone aber mit dem STM32 > zusammen zu arbeiten. Wohl weil das mit dem NRF51-J-Link nicht erlaubt > ist? Brauche ich wohl einen richtigen J-Link? Ich nehme an, du versucht den J-Link OB auf dem Nordic Semiconductor Evalboard mit einem STM32 zu verwenden? Der J-Link OB ist auf den Chip Hersteller gelockt, um genau das zu verhindern ;-). Du brauchst also einen richtigen J-Link.
Ich hab das nicht nur versucht. Es hat ja bisher problemlos funktioniert.:) Aber damit ich das richtig verstehe: Embedded Studio ist eine richtige IDE mit integriertem Make-System und Code-Editor für C. Ozone ist hingegen nur ein Debugger. Aber sind die Debug-Features unterschiedlich?
Sebastian K. schrieb: > Ich hab das nicht nur versucht. Es hat ja bisher problemlos > funktioniert.:) Schon klar. Sagen wir, es geht halt jetzt nicht mehr ;-). Sebastian K. schrieb: > Embedded Studio ist eine richtige IDE mit integriertem Make-System und > Code-Editor für C. > Ozone ist hingegen nur ein Debugger. Korrekt. Sebastian K. schrieb: > Aber sind die Debug-Features unterschiedlich? Die Idee ist, dass wir die neuesten J-Link/J-Trace Features schnell in Ozone einbauen können. D.h. es kann Debug Features geben, die es schon in Ozone gibt aber noch nicht in Embedded Studio. Für den Normalanwender ist aber alles, was man braucht, im Embedded Studio drin.
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.