Moderne Controller besitzen einen Bootloader. Dies ist ein im Controller
2
befindliches Programm, dessen Aufgabe es ist das eigentliche Programm
3
in den Speicher zu laden. Bootloader gibt es in vielfältiger Ausprägung.
4
Zumeist ist es ein fest im Controller integriertes Programm wie beim
5
C166 oder 68HC11. Dieses ermöglicht das Laden des Programms über die
6
Serielle Schnittstelle.
Damit könnte man auch fabrikneue Chips über eine sowieso vorhandene
Schnittstelle vom PC aus flashen -- ohne J-Link oder ähnliches. Das
lohnt sich noch viel mehr, wenn in einem Gerät mehrere uC verbaut sind.
Nur einer müsste mit dem PC verbunden sein und der könnte die restlichen
flashen -- ganz ohne ein zusätzliche Stecker und Kabel.
Auf dem Weg könnte auch ein Benutzer selbst Updates machen. Dabei dürfte
sogar der Strom ausfallen, der Bootloader selbst wäre praktisch
unkaputtbar, auch, weil der nie ein Update braucht. Bei selbstgebauten
Bootloadern kommt man eher in Versuchung und kann damit das Gerät
schrotten.
Zurück in die Gegenwart: Mit STM32, EFM32, LPCxxx ist das alles
Realität, aber
PittyJ schrieb:> Ich fand die ATSAMD irgendwie in der Zeit sehen geblieben,> so aus dem letzten Jahrtausend.
Anscheinend haben nur die ATSAME70/S70/V70 so einen Bootloader. Wie
werden die anderen ATSAM in der Kleinserie programmiert, also ohne
Nadelbett und Roboter? Nutzt man den Programmier-Service von Microchip?
Fummelt man wirklich dieses filigrane 10-polige SWD-Flachkabel an jeden
einzelnen Baustein? Oder was übersehe ich da?
Die SWD-Schnittstelle an sich ist ja nicht schlecht, klein und stark und
quasi genormt. Aber gerade deshalb möchte man ja keinen anderen Stecker
verwenden. Oder?
Falls mehrere uC auf einer Platine sitzen, könnte einer die restlichen
per Bit-Bang-SWD programmieren. Die Pins muss man eben opfern. Aber die
Software? Laut "ARM Debug Interface® Architecture Specification" ist
fast alles optional und müsste deshalb von Atmel dokumentiert werden.
Ziemlich aussichtslos, oder kennt jemand eine "lib"?
1) https://www.mikrocontroller.net/articles/Bootloader
Bauform B. schrieb:> Nutzt man den Programmier-Service von Microchip?
Nö.
> Fummelt man wirklich dieses filigrane 10-polige SWD-Flachkabel an jeden> einzelnen Baustein?
Was gibt es da zu fummeln? Auf dem Board ist ein Stecker, dort steckt
man sich an, fertig.
> Die SWD-Schnittstelle an sich ist ja nicht schlecht, klein und stark und> quasi genormt. Aber gerade deshalb möchte man ja keinen anderen Stecker> verwenden. Oder?
Oder.
> Falls mehrere uC auf einer Platine sitzen, könnte einer die restlichen> per Bit-Bang-SWD programmieren.
Wozu? Weil du zu faul bist, das Kabel umzustecken und eine andere
Firmware zu brennen? OMG!
> Die Pins muss man eben opfern. Aber die> Software? Laut "ARM Debug Interface® Architecture Specification" ist> fast alles optional und müsste deshalb von Atmel dokumentiert werden.> Ziemlich aussichtslos, oder kennt jemand eine "lib"?
Wozu? Klingt so al ob du ein Problem suchst, das nicht da ist.
Bauform B. schrieb:> Anscheinend haben nur die ATSAME70/S70/V70 so einen Bootloader. Wie> werden die anderen ATSAM in der Kleinserie programmiert, also ohne> Nadelbett und Roboter? Nutzt man den Programmier-Service von Microchip?> Fummelt man wirklich dieses filigrane 10-polige SWD-Flachkabel an jeden> einzelnen Baustein? Oder was übersehe ich da?
Üblicherweise werden Leiterplatten in einem Nutzen gefertigt und später
vereinzelt. Bei der üblichen maschinellen Bestückung findet diese auch
vor der Vereinzelung statt. Dabei hat man einen Rahmen mit
Passerbohrungen und eventuell Testcoupons für Impedanzkontrolle.
JTAG erlaubt den Aufbau einer Kette, in der alle Controller eines
Nutzens hintereinander geschaltet sind. Man kann den Rahmen und die
Frässtege nutzen, um diese Kette zu erstellen und auf einen Stecker am
Nutzenrand zu führen. So kann man dann alle Controller eines Nutzens
ohne Umzustecken programmieren und ggf auch den gesamten Nutzen per JTAG
Boundary Scan testen. Bei der Vereinzelung werden die Verbindungen dann
getrennt, und die Boards können später einzeln geupdatet werden.
SWD kann keine Kette bilden. Daher ist bei Controllern, die kein JTAG
haben, so nicht anwendbar. Hier müsste man ggf. mit externen
Multiplexern im Programmier-Rig arbeiten.
Wenn Deine Serie so klein ist, dass Du nicht mit Nutzen arbeitest, dann
kannst Du genauso gut den manuellen Weg gehen.
Andere Möglichkeit: Pogo-Pins a la TagConnect. Probe draufhalten,
Programmieren, nächster. Auchh wenn die TagConnect-Kabel teuer sind - so
viele brauchst Du ja nicht.
fchk
Bauform B. schrieb:> Anscheinend haben nur die ATSAME70/S70/V70 so einen Bootloader. Wie> werden die anderen ATSAM in der Kleinserie programmiert, also ohne> Nadelbett und Roboter?
Was die Bootlader betrifft: Da gibt es eine breite Vielfalt von µC mit
Bootlader bis hin zu µC ohne alles. Bei Nuvoton z.B. wird Flash in einem
extra Bereich (LDROM) außerhalb des normalen Adreßbereiches vorgehalten,
wo man seinen eigenen Bootlader hineinprogrammieren könnte.
Für Bastel-LP baut man sich am besten einen passenden Steckverbinder mit
auf die LP. Für Serienfertigung ist das zu unbequem, da hab ich bislang
irgendwo am LP-Rand ein paar Kontaktflächen vorgesehen, wo man dann per
Nadeladapter draufpieksen kann. Am Rand deshalb, weil man da zumeist am
besten den Kontaktdruck erzeugen kann, ohne dabei auf irgendwelche
Bauteile drücken zu müssen. Also für Serien eine Programmierfassung für
die LP.
W.S.
Ich flashe über den SWD Stecker einen Bootloader auf meine ATSAM.
Mein CAN Bootloader arbeitet mit dem von mir gewünschten Protokoll bei
den Parametern die ich für den Bus brauche - Datenrate / Identifier.
Unser USB Bootloader arbeitet mit unserer Produkt-ID und Vendor-ID
Die Bootloader kennen die Platinen und blinken mit der Debug-LED.
Ich habe jetzt auch Platinen mit GD32C103CBT6.
Die haben einen eingebauten Bootloader der auch USB unterstützt.
Dieser Bootloader hat zum einen eine fest vergebene Produkt-ID und
Vendor-ID, ob das wirklich DFU ist bin ich noch nicht sicher und die
Enumeration scheitert erst einmal mit dazugehörigen Fehlern unter
Windows, weil ich einen Quarz angeschlossen habe.
Und ohne Software auf dem Gerät muss Boot0 auf High gezogen werden,
dafür musste ich auf die Platinen extra einen Taster eindesignen. Und da
ich kein Freund von Resets über das USB-Kabel bin habe ich zusätzlich
noch einen Reset-Taster mit drauf gepackt.
Also wenn ich mir das so ansehe, dann möchte ich eigentlich einen
eigenen USB Bootloader per SWD auf den GD32C103CBT6 flashen.
Und meine Platine hat einen Standard SWD Anschluss, das scheint bei
STM32 Boards leider völlig unüblich zu sein.
Frank K. schrieb:> Üblicherweise werden Leiterplatten in einem Nutzen gefertigt und später> vereinzelt.> Wenn Deine Serie so klein ist, dass Du nicht mit Nutzen arbeitest,> dann kannst Du genauso gut den manuellen Weg gehen.
Na klar, es wäre ja auch schon ein Fortschritt, früher mussten 5 EPROMs
programmiert werden. Aber am Wochenende darf man doch mal kucken was
geht ;)
Nutzen sind das nächste Problem. Ein Beispiel für 1+6 uC wäre ein
6-phasiger DC/DC-Wandler. Das ist eine Platine ungefähr im DIN-A4
Format. Die geht ohne Nutzen, aber was ist mit Europakarten? Da müssen
mindestens die langen Kanten glatt sein, also gibt es bisher auch keinen
Nutzen.
> JTAG erlaubt den Aufbau einer Kette
Diese Mehrfach-Programmierung wäre die klassische JTAG-Aufgabe.
Natürlich haben die beliebten M0+ kein JTAG.
> Pogo-Pins a la TagConnect. Probe draufhalten, Programmieren, nächster.
Hab' ich leichtsinnigerweise gemacht, "das werden ja nur 10 Stück".
Inzwischen sind es bald 500 geworden, aber schön nach und nach, damit
keiner auf Idee kommt, die Platine zu ändern.
W.S. schrieb:> Für Bastel-LP baut man sich am besten einen passenden Steckverbinder mit> auf die LP. Für Serienfertigung ist das zu unbequem, da hab ich bislang> irgendwo am LP-Rand ein paar Kontaktflächen vorgesehen
Sag' ich doch. Noch bequemer wären natürlich die sowieso vorhandenen
Stecker, nur will man auf denen keine SWD-Signale haben.
> Da gibt es eine breite Vielfalt von µC mit Bootlader
Ja? Verrat mir welche Cortex-M von Atmel?
Rudolph R. schrieb:> Ich flashe über den SWD Stecker einen Bootloader auf meine ATSAM.
Genau das spart man bei vielen anderen uC. Deshalb hoffte ich, dass es
auch für die ATSAM eine andere Lösung als SWD gibt.
> ohne Software auf dem Gerät muss Boot0 auf High gezogen werden,> dafür musste ich auf die Platinen extra einen Taster eindesignen.
Ja, direkt geschenkt gibt es nichts. Ich hab' für BOOT und RESET mal
einen HC4060 und 5 Kleinteile spendiert, damit wird der integrierte
Bootloader per seriellem Break gestartet. Das ist Mega komfortabel bei
der Entwicklung, funktioniert aber eben auch für Updates ohne das Gerät
zu zerlegen.
> Und meine Platine hat einen Standard SWD Anschluss, das scheint bei> STM32 Boards leider völlig unüblich zu sein.
Wer verbaut denn auch irgendwelche Demo-Boards?
Rudolph R. schrieb:> Und ohne Software auf dem Gerät muss Boot0 auf High gezogen werden,> dafür musste ich auf die Platinen extra einen Taster eindesignen.
Dafür werde ich dich bei passender Gelegenheit mal nach Kräften
bedauern.
Sowas macht man mit passenden Kontaktflächen auf der LP, wo eben auch
Reset und Boot (bei ARM's) anliegen, ansonsten je nach Controller. Wenn
es auf der LP nur ein paar Kontaktflächen sind, dann trägt das
kostenmäßig nicht auf.
Es wird nur dann schwierig, wenn der Controller mehr an
Versorgungsspannung beim Programmieren braucht als beim normalen Lauf -
sowas ist mir aber noch nicht untergekommen.
W.S.
Bauform B. schrieb:>> Ich flashe über den SWD Stecker einen Bootloader auf meine ATSAM.>> Genau das spart man bei vielen anderen uC.
Und was genau spart man sich da?
Ob man sich nun einen Standard SWD auf die Platine baut oder einen
eigenen SWD oder Teile um per USB/Seriell Adapter den eingebauten
Bootloader mitsamt Umschaltung von Boot0 zu nutzen - wo ist der
Unterschied?
Vor allem wenn man dann trotzdem einen eigenen Bootloader braucht?
Nur kann man über den SWD dann auch gleich noch Debuggen.
Bauform B. schrieb:> Verrat mir welche Cortex-M von Atmel?
Deswegen nimmt man Cortex-M von Atmel nur wenn es nicht anders geht.
Es gibt noch die Möglichkeit, welche mit Arduino Bootloader zu
bestellen.
Der hat aber gegenüber dem ROM-Bootloader von anderen Herstellern den
Nachteil, dass das Programm nicht mehr bei 0x0000 beginnen kann.
Ich hatte schon mal gefragt, warum Atmel ganz früher mal ROM-Bootloader
standardmässig hatte z.B. bei den AT89 / FLIP und dann auf einmal nicht
mehr, konnte keiner sagen.
Rudolph R. schrieb:> Vor allem wenn man dann trotzdem einen eigenen Bootloader braucht?> Nur kann man über den SWD dann auch gleich noch Debuggen.
Was du nur mit dem ewigen Ruf nach Debuggen hast? Wenn ein µC auf einer
Leiterplatte sitzt und alles zusammen in ein Gerät eingebaut wird, dann
wird vermutlich kein Kunde, der dieses Gerät kauft, auf den Gedanken
kommen, dort irgend etwas debuggen zu wollen.
Also, für den Entwickler des Gerätes mag die Debug-Möglichkeit durchaus
interessant sein, nicht jedoch für Fertigung, Versand, Verkauf und
Kunden. Und wenn man da irgend einen teuren Steckverbinder oder einen
zusätzlichen Schaltkreis oder sonstwas, das Geld kostet, einbaut bloß um
debuggen zu können, dann ist das unökonomisch. Und ein ab Hersteller im
Chip befindlicher Bootlader, der obendrein auch noch in einem anderen
Speichervolumen steht, was nicht zum normalen Programmspeicher gehört,
stört nicht mit sich selbst die Firmware. Er hat aber (hoffentlich) die
zwei großen Vorteile: erstens sollte er die zum Chip genau passenden
Programmieralgorithmen haben und zweitens sollte er mit der Außenwelt
über ein Interface verkehren, was kein spezielles und damit auch teures
Programmiergeschirre erfordert. Und das gilt auch für den Bastler,
sofern dieser ein paar Sekunden Zeit hat für's Brennen und nicht
vornehmlich mit dem Debugger "programmiert".
W.S.
Rudolph R. schrieb:> Bauform B. schrieb:>>> Ich flashe über den SWD Stecker einen Bootloader auf meine ATSAM.>>>> Genau das spart man bei vielen anderen uC.>> Und was genau spart man sich da?
Arbeit in der Produktion, das Gefummel mit den SWD-Kabeln. Ein USB-Kabel
zum PC reicht dann für alle uC auf der Platine.
> Ob man sich nun einen Standard SWD auf die Platine baut oder einen> eigenen SWD oder Teile um per USB/Seriell Adapter den eingebauten> Bootloader mitsamt Umschaltung von Boot0 zu nutzen - wo ist der> Unterschied?
Für die Entwicklung will man natürlich einen SWD-Stecker, später muss
der nicht mehr bestückt werden. In der Produktion will man Stecker für
Grobmotoriker und davon möglichst wenig. Beim Kunden will man garkeine
Stecker anfassen (wenigstens, wenn sowieso etwas PC-ähnliches verbaut
ist).
> Vor allem wenn man dann trotzdem einen eigenen Bootloader braucht?
Den braucht man eben nur, wenn die Anwendung den braucht. Und dann ist
er praktisch ein Teil des normalen Anwendungsprogramms. Jedenfalls von
der Handhabung in der Produktion her.
Lothar schrieb:> Deswegen nimmt man Cortex-M von Atmel nur wenn es nicht anders geht.>> Es gibt noch die Möglichkeit, welche mit Arduino Bootloader zu> bestellen.
Microchip bietet auch einen Programmier-Service, sogar für 0(!) bis 500
Stück. Notfalls würde ich da meinen eigenen Bootloader flashen lassen.
> Der [Arduino-Bootloader] hat aber gegenüber dem ROM-Bootloader> von anderen Herstellern den Nachteil, dass das Programm nicht> mehr bei 0x0000 beginnen kann.
Naja, es muss irgendeinen Mechanismus zur Auswahl Bootloader/Anwendung
geben. Ansonsten ist das doch egal.
> Ich hatte schon mal gefragt, warum Atmel ganz früher mal ROM-Bootloader> standardmässig hatte z.B. bei den AT89 / FLIP und dann auf einmal nicht> mehr, konnte keiner sagen.
Unglaublich. Und es kommt schlimmer: Viele Typen gibt es immer noch mit
Bootloader, aber nur im WLCSP mit 0.4mm Pitch.
W.S. schrieb:> Er hat aber (hoffentlich) die zwei großen Vorteile: erstens sollte er> die zum Chip genau passenden Programmieralgorithmen haben und zweitens> sollte er mit der Außenwelt über ein Interface verkehren, was kein> spezielles und damit auch teures Programmiergeschirre erfordert.
Vor allem erstens, und das ohne Updates für das Programmiergerät.
Warum gibt es dafür einen Minuspunkt? Wer war das?
Also den internen Bootloader nutzen denke ich für Produktion nur wenige.
UARt ist einfach ein Krampf, weil langsam und was anderes macht auch
nicht wirklich Sinn.
Wenn du das Ganze richtig machst, hast du irgendwo Testpunkte auf der
Platine wo sich in der Fertigungsstraße der Nadeladapter andockt und
dann kannst du über JTAG dein Programm reinpumpen. In der Regel muss ja
eh noch mehr gemacht werden als das Programmieren. In der Regel müssen
zumindes tirgendwelche Spannungen geprüft, eventuell analogwerte
abgeglichen, LEDs getestet... werden.
Zu teilen machen wir das so:
- Über JTAG wird mittels Boundary SCAN die umliegende HW getestet.
(Verbindung zum EEPROM wird geprüft etc.). Dann wird die FW
reingeschrieben.
- JTAG geht manchen aber zu Recht irgendwie auf den Keks. Teilweise
haben wir deshalb eine Test-Firmware, die wir ebenfalls über JTAG
reinflashen. Dann wird über UART mit dieser Test-SW kommuniziert und man
kann alles mal wackeln lassen. Wenn der Test dann durch ist, wird das
finale Programm über JTAG reingebrannt.
Es gibt keinen richtigen Grund einen Bootloader zu verwenden. (So gut
wie)Jeder Chip hat einen JTAG Port und kann da mit ordentlich
Geschwindigkeit geflasht werden.
Wenn du ganz groß bist kannst du natürlich auch dein fertiges Programm
an den Chiphersteller schicken und dir dort eine Teilenummer dafür holen
und dann brennen sie dir das im Endmessen rein.
Bauform B. schrieb:> Anscheinend haben nur die ATSAME70/S70/V70 so einen Bootloader. Wie> werden die anderen ATSAM in der Kleinserie programmiert, also ohne> Nadelbett und Roboter? Nutzt man den Programmier-Service von Microchip?> Fummelt man wirklich dieses filigrane 10-polige SWD-Flachkabel an jeden> einzelnen Baustein? Oder was übersehe ich da?
Also selbst für Kleinserie lohnt sich ein "Nadeladapter". Ich habe
selbst privat einen:
https://www.digikey.de/en/products/detail/tag-connect-llc/TC2050-IDC-NL/2605367?utm_adgroup=Accessories&utm_source=google&utm_medium=cpc&utm_campaign=Dynamic%20Search_EN_Product&utm_term=&productid=&gclid=EAIaIQobChMImMCS4LTw-AIVBbDtCh1Y1APEEAAYASAAEgLF9PD_BwE
Über die Jahre habe ich das Geld für den Stecker glaube ich schon durch
gesparte Wannenstecker wieder drin., obwohl ich ihn mir initial nur
zugelegt habe, weil ich es interessant fand und damit spielen wollte.
Für eine Firma ist sowas natürlich überhaupt keine Investition. Einfach
Testpunkte auf die Platine und gut isses.
M. H. schrieb:> Also den internen Bootloader nutzen denke ich für Produktion nur wenige.> UARt ist einfach ein Krampf, weil langsam und was anderes macht auch> nicht wirklich Sinn.
Je nachdem welche Schnittstelle drauf ist bieten die meisten Hersteller
ROM-Bootloader für UART, USB, CAN, Ethernet
Bauform B. schrieb:> Aber gerade deshalb möchte man ja keinen anderen Stecker verwenden.> Oder?
Wenn dich der 10polige genormte Stecker stört: letztlich kannst du ihn
auf drei Leitungen reduzieren, also genauso viel oder wenig wie bei
einer UART (GND, SWCLK, SWDIO). Die Referenzspannung muss ja nicht
unbedingt wirklich vom Target kommen, wenn man mit einem UART-Protokoll
programmiert, würde sie auch nicht daher kommen.
Außerdem ist das SWD-Protokoll ja auch genormt, du kannst also
irgendwas nehmen, was SWD spricht. Wenn es die denn mal wieder zu
kaufen gibt, kann das ein MPSSE-fähiger FTDI sein, den kannst du dann
auch gleich mit drauf montieren auf was auch immer als
Inbetriebnahme-Einrichtung nötig ist (oder wenn du willst, auch gleich
mit aufs Board selbst, bei einem FT2232 kann der zweite Kanal dann noch
eine UART übernehmen).
Niemand schreibt dir vor, dass es unbedingt ein Atmel-ICE sein muss …
selbst einen STlink kannst du dafür nehmen, ich fand die immer nur
irgendwie ein bissel "störrischer" und habe es lieber andersrum gemacht
(Atmel-ICE für STM32Fxxx).
M. H. schrieb:> In der Regel muss ja eh noch mehr gemacht werden als das> Programmieren. In der Regel müssen zumindes tirgendwelche> Spannungen geprüft, eventuell analogwerte abgeglichen,> LEDs getestet... werden.
Genau, und dafür reichen meistens die Stecker, die sowieso vorhanden
sind und das SWD-Kabel wäre ein Stecker mehr.
> Teilweise haben wir deshalb eine Test-Firmware, die wir ebenfalls> über JTAG reinflashen. Dann wird über UART mit dieser Test-SW> kommuniziert und man kann alles mal wackeln lassen. Wenn der Test> dann durch ist, wird das finale Programm über JTAG reingebrannt.
Mit dem STM32-Bootloader kann ich das Testprogramm sogar ins RAM laden,
der EFM32-Bootloader kann nur Flash.
> Es gibt keinen richtigen Grund einen Bootloader zu verwenden. (So gut> wie)Jeder Chip hat einen JTAG Port und kann da mit ordentlich> Geschwindigkeit geflasht werden.
Rein zum flashen geht SWD doch genauso gut, es könnte sogar schneller
sein?
> Wenn du ganz groß bist kannst du natürlich auch dein fertiges Programm> an den Chiphersteller schicken und dir dort eine Teilenummer dafür holen> und dann brennen sie dir das im Endmessen rein.
Groß ist relativ, die Preisliste bei Microchip fängt mit 0-500 an :)
> Also selbst für Kleinserie lohnt sich ein "Nadeladapter". Ich habe> selbst privat einen:
Zum Debuggen taugt das nicht, also muss ich den Platz für den 10-poligen
Stecker sowieso spendieren. Und der braucht weniger Platz als ein
Tag-Connect mit Führungsstiften. Alles schon probiert :(
Jörg W. schrieb:> Wenn dich der 10polige genormte Stecker stört: letztlich kannst du ihn> auf drei Leitungen reduzieren, also genauso viel oder wenig wie bei> einer UART (GND, SWCLK, SWDIO).
Da fehlt auf jeden Fall noch Reset. Aber der große Unterschied ist: UART
braucht in dem Vergleich NULL Pins, weil die Signale sowieso für das
Gerät gebraucht werden. Gegen den 10-poligen an sich habe ich garnichts,
das ist der Standard und alles andere wäre nur anders bzw. hätte andere
Nachteile.
> Außerdem ist das SWD-Protokoll ja auch genormt, du kannst also> irgendwas nehmen, was SWD spricht. Wenn es die denn mal wieder zu> kaufen gibt, kann das ein MPSSE-fähiger FTDI sein, den kannst du dann> auch gleich mit drauf montieren auf was auch immer als> Inbetriebnahme-Einrichtung nötig ist (oder wenn du willst, auch gleich> mit aufs Board selbst, bei einem FT2232 kann der zweite Kanal dann noch> eine UART übernehmen).
Selbst das ist mit einem UART-Bootloader einfacher, dafür reicht der
simpelste FT230X.
> Niemand schreibt dir vor, dass es unbedingt ein Atmel-ICE sein muss #> selbst einen STlink kannst du dafür nehmen, ich fand die immer nur> irgendwie ein bissel "störrischer" und habe es lieber andersrum gemacht> (Atmel-ICE für STM32Fxxx).
Black Magic Probe, auch nicht lieferbar, aber sowas ist ja in jedem
ordentlichen Haushalt vorhanden ;)
Aber schön langsam macht ihr mich nachdenklich...
Bauform B. schrieb:>> Wenn dich der 10polige genormte Stecker stört: letztlich kannst du ihn>> auf drei Leitungen reduzieren, also genauso viel oder wenig wie bei>> einer UART (GND, SWCLK, SWDIO).> Da fehlt auf jeden Fall noch Reset.
Ist optional, braucht man nicht immer und unbedingt, insbesondere nicht
im Auslieferungszustand.
Wenn man drüber debuggen will, sollte man es aber auf jeden Fall dabei
haben, um für alle Fälle gerüstet zu sein.
> Aber der große Unterschied ist: UART> braucht in dem Vergleich NULL Pins, weil die Signale sowieso für das> Gerät gebraucht werden.
Muss nicht bei jedem so sein. Kann auch gut sein, dass andere für den
Rest dann USB bevorzugen.
> Selbst das ist mit einem UART-Bootloader einfacher, dafür reicht der> simpelste FT230X.
Nur debuggen kann man damit nicht.
Wenn ich das gleiche Board aber während der Entwicklungsarbeit debuggen
können möchte, was ich dann später auch ausliefere, dann brauche ich eh
SWD drauf, in der einen oder anderen Form.
Wie schon (mal) geschrieben, bei einem früheren Brötchengeber haben wir
dann tasächlich einfach einen FT2232 drauf gepackt. Das spart die
Stöpselei mit dem SWD-Kabel, man kann damit flashen und debuggen und hat
außerdem noch einen UART-Kanal.
Blöd nur, dass die Chipkrise die Dinger auf längere Zeit ins Reich des
Unobtainium verlagert hat. :(
Bauform B. schrieb:> M. H. schrieb:>> In der Regel muss ja eh noch mehr gemacht werden als das>> Programmieren. In der Regel müssen zumindes tirgendwelche>> Spannungen geprüft, eventuell analogwerte abgeglichen,>> LEDs getestet... werden.>> Genau, und dafür reichen meistens die Stecker, die sowieso vorhanden> sind und das SWD-Kabel wäre ein Stecker mehr.
Wenn man nur die Hälfte liest und quotet hast Du Recht.
Aber irgendwie zieht sich das durch den ganzen Thread, Du liest nur
einen Teil und hast keine Argumente.
M.H. hat berichtet das ganz ohne Stecker zu machen, zwei Nadeln mehr auf
dem Adapter machen ja nichts.
Wir haben eine Platine in Kleinst-Serie, da lohnt sich der Nadel-Adapter
nicht, für die Basis-Inbetriebnahme messe ich mehrere Spannungen auf dem
Board nach die auf keinem Stecker liegen.
Theorethisch hätte der Aurix Controller auf der Platine auch einen
ROM-Bootloader über die serielle Schnittstelle, aber benutzen will den
niemand und so wurde nicht mal der Versuch unternommen den regulär
benutzbar zu machen. Da ist ein DAP Anschluss drauf, 10pol 1,27mm wie
SWD, über den wird einer unser eigenen Bootloader geflasht.
Bauform B. schrieb:>> Es gibt keinen richtigen Grund einen Bootloader zu verwenden. (So gut>> wie)Jeder Chip hat einen JTAG Port und kann da mit ordentlich>> Geschwindigkeit geflasht werden.>> Rein zum flashen geht SWD doch genauso gut, es könnte sogar schneller> sein?
Wie er schrieb, über JTAG machen die einen Boundary Scan, damit ist JTAG
da schon mal gesetzt und ob der Controller überhaupt SWD unterstützt ist
quasi egal.
Bauform B. schrieb:>> Also selbst für Kleinserie lohnt sich ein "Nadeladapter". Ich habe>> selbst privat einen:>> Zum Debuggen taugt das nicht, also muss ich den Platz für den 10-poligen> Stecker sowieso spendieren. Und der braucht weniger Platz als ein> Tag-Connect mit Führungsstiften. Alles schon probiert :(
Mir sind die Tag-Connect auch zu fett, in dem Raster und vor allem mit
den Löchern drum herum und Durchkontaktiert.
Ein Teil meiner Platinen hat für SWD einen BM05B-SRSS drauf, das ist ein
einreihiger 5pol Stecker im 1mm Raster. V+/SWCLK/SWDIO/Reset/GND.
Funktioniert super und braucht nur ca. 50% von dem normalen SWD Stecker
in 1,27mm.
Nur brauche ich dafür eine zusätzliche Adapter-Platine, sowas wird
schnell sehr lästig wenn man die Platine nicht nur selber nutzt.
Jörg W. schrieb:> Wenn dich der 10polige genormte Stecker stört: letztlich kannst du ihn> auf drei Leitungen reduzieren, also genauso viel oder wenig wie bei> einer UART (GND, SWCLK, SWDIO). Die Referenzspannung muss ja nicht> unbedingt wirklich vom Target kommen, wenn man mit einem UART-Protokoll> programmiert, würde sie auch nicht daher kommen.
Über den Verzicht von Reset bin ich bei einem ATSAMC21 schon mal
gestolpert, der Controller war nicht mehr ansprechbar. Und bei VRef
kommt es halt auf den Adapter an, mit einem JLink Edu Mini auf 3,3V
dürfte das gar kein Problem sein, der AtmelICE dürfte so nicht
funktionieren.
Lothar schrieb:> Je nachdem welche Schnittstelle drauf ist bieten die meisten Hersteller> ROM-Bootloader für UART, USB, CAN, Ethernet
Ja, sowas gibt es.
Nur, wie ich oben schrieb, was macht man wenn der CAN-Bootloader mit den
falschen Identifiern arbeitet und/oder den falschen Paramern? Dazu noch
das Protokoll. Richtig, einen eigenen CAN-Bootloader flashen.
Ich meine bei den LPC zum Beispiel war das so das man die ROM Funktionen
für einen eigenen Bootloader nutzen kann, das macht den eigenen
Bootloader schlanker und robuster, wenn ich sowas hätte würde ich auch
versuchen das zu benutzen. Nur trotzdem nicht den ganzen Bootloader.
So, jetzt habe ich ein Steuergerät und will dieses über den im
Controller eingebauten ROM-Bootloader flashen, der CAN liegt ja schon
auf meinem Stecker.
Wie starte ich den ROM Bootloader?
Ein Jumper geht gar nicht, das Signal auf den vorhandenen Stecker zu
legen ist auch keine Option.
Den ROM Bootloader immer zu starten geht nur wenn der zum einen schnell
genug die Applikation startet und zum anderen den Bus nicht stört.
Den ROM Bootloader per Software zu starten geht erst wenn man Software
auf dem Gerät hat.
Oder im Falle von dem GD32C103CBT6 - wie bringen ich dem USB ROM
Bootloader bei von alleine zu starten und dabei keine Fehler in Windows
zu erzeugen?
Eher gar nicht, einfach nur das USB-Kabel zu stecken wird nichts.
Die Windows-Fehler sind evtl. weg wenn ich einen 25MHz Quarz verwende,
der Test steht noch aus, eigentlich wollte ich 16MHz verwenden und
musste den schon auf 8MHz ändern.
Beim RP2040 ist es glaube ich so das der Bootloader automatisch startet
wenn das Flash leer ist, zumindest passiert das nachdem man die Datei
flash_nuke.uf2 geflasht hat, dann kommt nach dem Anstecken vom USB Kabel
automatisch der UF2 Bootloader hoch auch ohne das man den Boot-Taster
betätigen muss.
Ich bin kein Freund von dem UF2 oder dem RP2040, aber das der Bootloader
automatisch startet wenn kein Programm da ist - nice.
Nur, wie aktualisiert man die Software ohne den Boot-Taster zu
betätigen?
M. H. schrieb:> Also selbst für Kleinserie lohnt sich ein "Nadeladapter". Ich habe> selbst privat einen:> https://www.digikey.de/en/products/detail/tag-connect-llc/TC2050-IDC-NL/2605367?utm_adgroup=Accessories&utm_source=google&utm_medium=cpc&utm_campaign=Dynamic%20Search_EN_Product&utm_term=&productid=&gclid=EAIaIQobChMImMCS4LTw-AIVBbDtCh1Y1APEEAAYASAAEgLF9PD_BwE
Ich würde Tag-Connect nicht als Nadeladapter bezeichnen, zu viel
Verwechslungsgefahr mit richtigen Prüfadaptern, welche sich für
Kleinserie definitiv nicht lohnen, je nach Komplexität eines solchen
Prüfadapters kann man den Gegenwert eines gut ausgestatteten
Mittelklasse Fahrzeugs dafür hinlegen.
Ich war mal für einen Hersteller von ICT Hardware mit eigenem Adapterbau
(Federkontakt und Starrnadel) tätig, praktisch gibt es nach oben keine
Begrenzung, wenn der Prüfadapter speziell dafür entwickelte Elektronik
enthält, für ein einfaches Modell, dessen Nadeln direkt auf die
Anschlussblöcke verdrahtet wurde, war man aber schon mit 5000€ bis
15000€ dabei (je nach Art und Anzahl der benötigten Nadeln)
Aber so muss ich sagen ist Tag-Connect schon ne schöne Sache.
Rudolph R. schrieb:> Wenn man nur die Hälfte liest und quotet hast Du Recht.> Aber irgendwie zieht sich das durch den ganzen Thread, Du liest nur> einen Teil und hast keine Argumente.
Natürlich lese ich alles, ich will doch etwas lernen. Eben "Wie werden
fabrikneue ATSAM geflasht?" oder anders gefragt "stört sich jemand außer
mir am fehlenden Bootloader?". Die Frage ist beantwortet, anscheinend
hat die Mehrheit keinen Stress mit SWD/JTAG in der Fertigung.
Für die Frage sollte ich garkeine Argumente haben, ich will ja
niemandem zu etwas überreden. Ich versuche nur zu erklären, wie und
warum ich diesen Stecker sparen will. Mit dem STM32-Bootloader
funktioniert es ja problemlos, davon bin ich wohl verwöhnt.
> So, jetzt habe ich ein Steuergerät und will dieses über den im> Controller eingebauten ROM-Bootloader flashen, der CAN liegt ja schon> auf meinem Stecker.> Wie starte ich den ROM Bootloader?> Ein Jumper geht gar nicht, das Signal auf den vorhandenen Stecker zu> legen ist auch keine Option.> Den ROM Bootloader immer zu starten geht nur wenn der zum einen schnell> genug die Applikation startet und zum anderen den Bus nicht stört.> Den ROM Bootloader per Software zu starten geht erst wenn man Software> auf dem Gerät hat.
Auch das kann schief gehen. Wenn ein Update abgebrochen wird oder jemand
eine falsche Firmware aufspielt, kann der Bootloader nicht mehr
gestartet werden. In dem Fall hilft es auch nichts, wenn der Bootloader
immer startet, es ist ja Firmware vorhanden. Selbst CRC über die
komplette Firmware hilft nur gegen ein abgebrochenes Update. Taster oder
Jumper will niemand, also bleibt nur ein Signal vom Programmiergerät
oder übergeordneten Rechner.
Rudolph R. schrieb:> Über den Verzicht von Reset bin ich bei einem ATSAMC21 schon mal> gestolpert, der Controller war nicht mehr ansprechbar.
Ja, schrieb ich ja: für einen neuen (unprogrammierten) Controller sollte
es immer ohne funktionieren.
Ich würde ansonsten auch nicht drauf verzichten, vor allem nicht, wenn
damit wirklich debuggt werden soll.
> Und bei VRef> kommt es halt auf den Adapter an, mit einem JLink Edu Mini auf 3,3V> dürfte das gar kein Problem sein, der AtmelICE dürfte so nicht> funktionieren.
Man kann es aber halt auf der Seite des ICE "synthetisieren". Ist ja nur
das Referenzpotenzial für die Pegelwandler. Wenn man weiß, dass auf dem
Board 3,3 V sind, dann kann man die genauso gut extern einspeisen und
braucht (wenn der Platz wirklich knapp ist) einen Draht weniger am
Connector.
Bauform B. schrieb:>> Niemand schreibt dir vor, dass es unbedingt ein Atmel-ICE sein muss #>> selbst einen STlink kannst du dafür nehmen, ich fand die immer nur>> irgendwie ein bissel "störrischer" und habe es lieber andersrum gemacht>> (Atmel-ICE für STM32Fxxx).>> Black Magic Probe, auch nicht lieferbar, aber sowas ist ja in jedem> ordentlichen Haushalt vorhanden ;)
Für die ATSAMC21 und C20 braucht man wahrscheinlich einen Programmer und
die spezielle PC-Software von Atmel. Die Chips haben eine Device Service
Unit zwischen den SWD-Pins und dem ARM-Kern:
1
13.5.1 I/O Lines
2
The SWCLK pin is by default assigned to the DSU module to allow
3
debugger probe detection and to stretch the CPU reset phase.
4
For more information, refer to 13.6.3. Debugger Probe Detection.
Weil diese Unit der "Intellectual Property Protection" dient, dürfte es
aussichtslos sein, diese Chips mit der BMP zu flashen oder zu debuggen.
Die ATSAMx70 stehen auch nicht in dieser Liste
https://black-magic.org/knowledge/faq.html, aber das sind halbwegs
normale Chips, die müsste man selbst nachrüsten können.
Bauform B. schrieb:> Für die ATSAMC21 und C20 braucht man wahrscheinlich einen Programmer und> die spezielle PC-Software von Atmel.
Müsste ich mir mal ein Demoboard beschaffen.
> Die ATSAMx70 stehen auch nicht in dieser Liste> https://black-magic.org/knowledge/faq.html, aber das sind halbwegs> normale Chips, die müsste man selbst nachrüsten können.
SAME70 haben wir mit FT2232 programmiert und debuggt.
Wir hatten hier schon öfter bei EFM32 und EFM8 dass man über SWD nicht
mehr rein kam. Das Problem ist unten beschrieben.
Der EFM8 hat aber einen Bootloader im schreibgeschützten Flash ab 0xFA00
und damit kann man auch dann das Programm ab 0x0000 löschen und der uC
funktioniert wieder.
Beim EFM32 ist (wie auch beim Arduino) der Bootloader ab 0x0000 und das
Programm ab 0x1000 und es ist zu schaffen, den Bootloader zu
überschreiben und nicht mehr über SWD rein zu kommen, dann kann man das
Board wegwerfen.
Daher ist ein ROM Bootloader (wie bei LPC) oder ein geschützter
Bootloader (wie bei EFM8) durchaus wichtig, nicht nur für Field Updates.
https://community.silabs.com/s/article/unlock-a-bricked-efm32?language=en_US
Lothar schrieb:> Beim EFM32 ist (wie auch beim Arduino) der Bootloader ab 0x0000
"Beim Arduino" ist sehr allgemein, da es mittlerweile ja auch Arduinos
auf ARM-Basis gibt.
Bei den AVRs ist der Bootloader nicht ab Adresse 0. Bei den ganz
kleinen, die keine SPM protection kennen, könnte man ihn theoretisch
dahin legen, aber solche werden bei Arduinos eh nicht benutzt. Bei allen
anderen muss zumindest der Teil, der den SPM-Befehl ausführt, im für den
Bootloader reservierten Bereich im hinteren Teil des Flashs liegen (das
selbst dann, wenn man keinen Bootloader benutzen will, sondern bspw. aus
der Applikation heraus Konfigurationdaten oder dergleichen in den Flash
schreiben möchte).
> Daher ist ein ROM Bootloader (wie bei LPC) oder ein geschützter> Bootloader (wie bei EFM8) durchaus wichtig, nicht nur für Field Updates.
Nur, weil das bei den EFMs so ist, heißt das nicht, dass das überall so
sein muss. Andere Controller lassen sich über das Debuginterface
wiederherstellen, aber dafür wird die bereits erwähnte /RESET-Leitung
dann benötigt (damit man verhindern kann, dass die bereits gestartete
Firmware das Debuginterface deaktiviert).
Bauform B. schrieb:> Für die ATSAMC21 und C20 braucht man wahrscheinlich einen Programmer und> die spezielle PC-Software von Atmel.
Die ATSAMC21 flashe ich auch gelegentlich mal mit einem Segger JLink Edu
Mini.
Ich habe gerade mal das Segger J-Flash Lite V7-66b gestartet, da sind
alle ATSAMC20 und ATSAMC21 drin zu finden.
Nur wenn man den ATSAMC2x mit 5V betreibt sollte man zum Flashen nicht
den kleinen JLink verwenden, der ist nur für 3,3V.
Damit geht das auch in der Kommandozeile, mit Linux oder MacOS.
Und den JLink kann man auch mit dem Microchip Studio benutzen.
Lothar schrieb:> Daher ist ein ROM Bootloader (wie bei LPC) oder ein geschützter> Bootloader (wie bei EFM8) durchaus wichtig, nicht nur für Field Updates.
Den Bootloader-Bereich kann man mindestens bei den ATSAMC2x und ATSAMD5x
/ ATSAME5x schützen, der Bootloader sollte allerdings auch nicht so
stumpf sein sich selber zu löschen.
Rudolph R. schrieb:> der Bootloader sollte allerdings auch nicht so stumpf sein sich selber> zu löschen.
Das halte ich eigentlich für ein essenzielles Feature eines Bootloaders.
:-)
Lothar schrieb:> Beim EFM32 ist (wie auch beim Arduino) der Bootloader ab 0x0000 und das> Programm ab 0x1000 und es ist zu schaffen, den Bootloader zu> überschreiben und nicht mehr über SWD rein zu kommen, dann kann man das> Board wegwerfen.
Eine wertvolle Warnung, danke. Allerdings behauptet der Beitrag hinter
deinem Link, dass man es reparieren kann? Zumindest mit dem richtigen
Spezialwerkzeug? Ja, das muss man erstmal haben...
Rudolph R. schrieb:> Ich habe gerade mal das Segger J-Flash Lite V7-66b gestartet, da sind> alle ATSAMC20 und ATSAMC21 drin zu finden.
Das will ich doch stark hoffen. Alternativen sind immer gut, aber es ist
eben auch Spezialwerkzeug. Warum funktioniert sowas beim STM32 viel
einfacher und ohne Tricks? Ja, o.k., connect under reset könnte man als
Trick bezeichnen. Aber: die STM32 haben ein Selbstzerstörungs-Bit das
wirklich und endgültig funktioniert :)
Bauform B. schrieb:> Warum funktioniert sowas beim STM32 viel einfacher und ohne Tricks?
Was genau funktioniert da "einfacher und ohne Tricks"?
Ich habe zwischen STM32 und SAMxx in dieser Hinsicht keine großen
Unterschiede erlebt. Beide sind da eher einfach in der Handhabung.
Jörg W. schrieb:> Bauform B. schrieb:>> Warum funktioniert sowas beim STM32 viel einfacher und ohne Tricks?> Was genau funktioniert da "einfacher und ohne Tricks"?
Die STM32 haben diese "Device Service Unit" nicht, oder sie ist so
transparent, dass ich noch nicht darüber gestolpert bin. Beim ATSAMC2x
verstehe ich das Reference Manual so, dass der Debugger da irgendwas
"entriegeln" muss. Wenn ich das falsch verstehe, ist es ein Mangel des
Manuals ;) Jedenfalls wird es mit der BMP erstmal nicht funktionieren
und der target driver wäre deutlich komplizierter als normal.
Ich sehe da nichts in der Beschreibung, was du "entriegeln" müsstest.
Es steht nur, dass man mit einer Fuse (NVMCTRL) da Zugriffe sperren
kann, das ist ein ganz gewöhnliches Locking, damit man den Flash gegen
Auslesen schützen kann. Sowas wird STM32 ganz sicher auch haben. :-)
Jörg W. schrieb:> Rudolph R. schrieb:>> der Bootloader sollte allerdings auch nicht so stumpf sein sich selber>> zu löschen.>> Das halte ich eigentlich für ein essenzielles Feature eines Bootloaders.> :-)
In der Tat, aber man erlebt auch immer wieder Überraschungen. :-)
Ich habe zum Beispiel mal Marlin auf eine 3D Drucker Platine mit einem
M1284 geflasht und das Binary war knapp zu groß.
Ich hoffe nur, dass das am vom Hersteller installierten Arduino
Bootloader lag das der sich selber zerlegt hat.
Bauform B. schrieb:> Das will ich doch stark hoffen. Alternativen sind immer gut, aber es ist> eben auch Spezialwerkzeug. Warum funktioniert sowas beim STM32 viel> einfacher und ohne Tricks?
Selbst ein USB/Seriell Wandler fällt doch unter Spezialwerkzeug. :-)
Und die STM32 sowie GD32 kann ich mit dem JLink auch Flashen.
Oder auch den EFM32PG22 der hier noch so herum liegt.
Damit ist das eher ein Universal-Werkzeug. :-)
Lothar schrieb:> Beim EFM32 ist (wie auch beim Arduino) der Bootloader ab 0x0000 und das
Das kommt auf den EFM32 an. Bei dem EFM32, der hier gerade vor mir
liegt, sitzt der Bootloader in einem eigenen Bereich ab 0x0FE10000.
Bauform B. schrieb:> Beim ATSAMC2x verstehe ich das Reference Manual so, dass der Debugger da> irgendwas "entriegeln" muss.
Wie schon geschrieben, ich weiß nicht, an welcher Stelle du das heraus
gelesen haben willst.
Habe hier ein älteres, selbst gestricktes Testboard mit einem SAMD20.
Habe ich sonst immer mit dem Atmel-ICE bedient (aber auch nur generisch
mit OpenOCD, nicht mit irgendwelchen Studios oder Atmel- oder
Microchip-Programmen). Habe spaßeshalber mal mein FT232H-Modul dran
gehängt (nur SWDIO, SWDCLK und GND, nichtmal /RESET), funktioniert
problemlos. Kann damit den Speicher auslesen, das Programm anhalten,
Register lesen, NVM Fuse row lesen, den Flash löschen und mit dem vorher
ausgelesenen Image wieder überschreiben.
Diese Device Service Unit ist also erst einmal dem SWD nicht im Weg.
ps: Das Einzige, was ohne /RESET nicht ging (und daher einen power cycle
brauchte): nach dem Löschen des Flashs ist das Ding natürlich sofort in
einen hard fault gerannt. Da es natürlich auch keinen hard fault handler
gibt, entsteht daraus ein double fault, der lässt sich ohne einen Reset
nicht auflösen.
Jörg W. schrieb:> Bauform B. schrieb:>> Beim ATSAMC2x verstehe ich das Reference Manual so, dass der Debugger da>> irgendwas "entriegeln" muss.>> Wie schon geschrieben, ich weiß nicht, an welcher Stelle du das heraus> gelesen haben willst.
1
13.5.1 I/O Lines
2
The SWCLK pin is by default assigned to the DSU module to allow
3
debugger probe detection and to stretch the CPU reset phase.
Bis hier ist es eindeutig, der Debugger bekommt keine Verbindung zur CPU
oder zum Bus.
1
13.6.2 CPU Reset Extension
2
“CPU reset extension” refers to the extension of the reset phase
3
of the CPU core after the external reset is released. This ensures
4
that the CPU is not executing code at startup while a debugger is
5
connects to the system. The debugger is detected on a RESET release
6
event when SWCLK is low. (...) To release the CPU, write a '1' to
7
STATUSA.CRSTEXT.
Das heißt, wenn SWCLK low ist, muss der Debugger diese '1' schreiben,
sonst geht garnichts. Soweit ist immer noch klar, dass der Debugger
diesen Mechanismus kennen muss. Ein Debugger, der die ATSAMD2x, C2x
nicht ausdrücklich unterstützt, kann das evt. nicht.
An der Stelle hatte ich aufgegeben, aber es gibt drei Möglichkeiten,
warum es trotzdem funktionieren könnte. Natürlich mit einem
Original-Atmel Debugger oder einem J-Link. Zweitens: falls SWCLK
normalerweise high ist, wird die Reset Extension wahrscheinlich nicht
aktiv. Drittens: dieser Mechanismus ist Standard, alle SWD-Debugger
kennen den sowieso, nur ich nicht, weil STM den nie erwähnt.
Natürlich ist das kein Problem, wenn man rechtzeitig einen J-Link
bekommt. Und weil man für diese Chips sowieso etwas solides für die
Fertigung braucht, muss das wohl sein. Haben die kleineren J-Link
eigentlich einen eingebauten gdb-Server?
Übrigens ist der fehlende Bootloader ein Vorteil: man muss einen
eigenen schreiben. Bei Chips mit Bootloader versucht man erstmal den zu
benutzen und schreibt am Ende doch einen eigenen ;)
Bauform B. schrieb:> Allerdings behauptet der Beitrag hinter> deinem Link, dass man es reparieren kann? Zumindest mit dem richtigen> Spezialwerkzeug?
Ja mit dem "Spezialwerkzeug" J-Link nur hat ja schon einer geschrieben,
dass es damit auch nicht ging, weil das Zeitfenster sehr kurz ist.
> Natürlich mit einem Original-Atmel Debugger oder einem J-Link
Es gibt ja nicht nur die J-Link SWD Debugger sondern auch "High-Speed"
SWD Programmer, die wir noch nie genutzt haben, aber scheinbar für
Production Programming gedacht?
https://www.segger.com/products/debug-probes/j-link/models/model-overview/https://www.segger.com/supported-devices/flasher/
Bauform B. schrieb:> Bis hier ist es eindeutig, der Debugger bekommt keine Verbindung zur CPU> oder zum Bus.
Nein, das lese ich da nicht raus.
Die device service unit überwacht lediglich SWDCLK, um einen Debugger zu
erkennen.
> An der Stelle hatte ich aufgegeben, aber es gibt drei Möglichkeiten,> warum es trotzdem funktionieren könnte. Natürlich mit einem> Original-Atmel Debugger oder einem J-Link.
Wie ich schrieb, habe ich den extra nicht benutzt, sondern einen
generischen FTDI-Bitbanger.
> Zweitens: falls SWCLK> normalerweise high ist, wird die Reset Extension wahrscheinlich nicht> aktiv.
Möglich.
Habe jetzt versucht, ob ich in OpenOCD irgendwelches Spezial-Handling
dafür finde, aber sieht mir nicht danach aus. Also gut möglich, dass die
Reset Extension da einfach gar nicht aktiviert wird.
> Drittens: dieser Mechanismus ist Standard, alle SWD-Debugger> kennen den sowieso, nur ich nicht, weil STM den nie erwähnt.
Wenn man nach STATUSA.CRSTEXT gugelt, scheint das tatsächlich nur die
SAMxx zu betreffen.
> Natürlich ist das kein Problem, wenn man rechtzeitig einen J-Link> bekommt.
Wie geschrieben, ich habe einen FTDI benutzt und damit das SWD gemacht.
Wenn es damit geht, sollte es folglich mit jedem gehen, der SWD
überhaupt kann.
> Und weil man für diese Chips sowieso etwas solides für die> Fertigung braucht, muss das wohl sein. Haben die kleineren J-Link> eigentlich einen eingebauten gdb-Server?
Der GDB-Server ist ja immer auf der PC-Seite (zumindest, solange der
Debugger kein eigenes Ethernet hat). Aber ja, den gibt's für den
Segger-Kram meines Wissens überall.
Ansonsten geht natürlich auch OpenOCD mit J-Link, und da ist ebenfalls
immer ein GDB-Server dabei (wenn man ihn nicht per Konfiguration
abschaltet).
Den ATSAMC2x, ATSAMD2x und ATSAMD5x / ATSAME5x soll man am SWCLK einen
Pullup verpassen.
So im Gegensatz zu dem GD32C103 der an SWDIO und SWCLK einen Pulldown
haben möchte.
Die DSU nutzen wir in den USB/CAN und USB/LIN Interfaces für eine
CRC-32.
Aber das man mit der ein Chip-Erase per Software auslösen kann, ugh,
vielleicht doch mal schauen wie man den PAC (Peripheral Access
Controller) benutzt. :-)
Rudolph schrieb:> Den ATSAMC2x, ATSAMD2x und ATSAMD5x / ATSAME5x soll man am SWCLK einen> Pullup verpassen.> So im Gegensatz zu dem GD32C103 der an SWDIO und SWCLK einen Pulldown> haben möchte.
Die EFM32 und STM32 haben intern am SWCLK einen Pulldown und am SWDIO
einen Pullup. Die LPC (mindestens der LPC5410x) braucht extern an beiden
Pins einen Pullup. Das gute an Standards ist, dass es so viele davon
gibt :)
Jörg W. schrieb:> Wenn man nach STATUSA.CRSTEXT gugelt, scheint das tatsächlich nur die> SAMxx zu betreffen.
Wenn man das alles zusammenzählt, kann man wohl vergessen, mal eben
einen neuen target driver für die Black Magic Probe zu schreiben :(
Rudolph schrieb:> Aber das man mit der ein Chip-Erase per Software auslösen kann, ugh,> vielleicht doch mal schauen wie man den PAC (Peripheral Access> Controller) benutzt. :-)
Warum? Der Chip ist doch danach wie neu ;)
Bauform B. schrieb:> Wenn man das alles zusammenzählt, kann man wohl vergessen, mal eben> einen neuen target driver für die Black Magic Probe zu schreiben :(
Da wirst du nichts schreiben müssen.
Reicht es nicht, dass ich dir nun mehr als einmal erläutert habe, dass
sich das Ding problemlos mit einem völlig generischen SWD-Treiber auf
Basis eines FT232H benutzen lässt? Noch generischer geht's wohl kaum,
und das wird deine geliebte Black Magic Probe dann sicher auch können.
Ich kenne die Black Magic Probe nicht weiter. Wenn du willst, kannst du
sie mir gern zum Testen her senden.
Bauform B. schrieb:> Wenn man das alles zusammenzählt, kann man wohl vergessen, mal eben> einen neuen target driver für die Black Magic Probe zu schreiben :(
Die ATSAMD2x werden doch schon unterstützt, an vielen Stellen sind die
identisch mit den ATSAMC2x.
Bauform B. schrieb:> Rudolph schrieb:>> Aber das man mit der ein Chip-Erase per Software auslösen kann, ugh,>> vielleicht doch mal schauen wie man den PAC (Peripheral Access>> Controller) benutzt. :-)>> Warum? Der Chip ist doch danach wie neu ;)
Das ist aber etwas schwierig dem Kunden das als Vorteil zu verkaufen
dessen Gerät unverhofft gestorben ist. :-)
Ja nun, passiert nicht einfach so, aber funktionale Sicherheit und so...
Jörg W. schrieb:> Reicht es nicht, dass ich dir nun mehr als einmal erläutert habe, dass> sich das Ding problemlos mit einem völlig generischen SWD-Treiber auf> Basis eines FT232H benutzen lässt? Noch generischer geht's wohl kaum,> und das wird deine geliebte Black Magic Probe dann sicher auch können.
Die Hardware, hier der FT232H, kann das natürlich auf jeden Fall. Aber
welches Bit man wann setzen muss, weiß ja nur das Programm auf dem PC.
Bei der BMP läuft das entsprechende Programm auf einem STM32F103. Aber
egal wo, jemand muss diese Spezialfunktion programmiert haben (oder eben
nicht).
> Ich kenne die Black Magic Probe nicht weiter. Wenn du willst, kannst du> sie mir gern zum Testen her senden.
Sehr nett, danke! Ich hoffe, dass ich nicht darauf zurückkommen muss.
Ich könnte mir ja einfach ein Evaluation Board besorgen.
Bauform B. schrieb:> Die Hardware, hier der FT232H, kann das natürlich auf jeden Fall. Aber> welches Bit man wann setzen muss, weiß ja nur das Programm auf dem PC.
OpenOCD hat zwar ein entsprechendes Kommando (dsu_reset_deassert)
implementiert, aber da ich das nicht benutzen musste, wird's wohl auch
mit der Black Magic Probe gehen.
Rudolph schrieb:> Die ATSAMD2x werden doch schon unterstützt, an vielen Stellen sind die> identisch mit den ATSAMC2x.
An dieser Stelle sind zumindest Blockdiagramme und Beschreibungen
gleich.
Rudolph schrieb:> Die ATSAMD2x werden doch schon unterstützt, an vielen Stellen sind die> identisch mit den ATSAMC2x.
Stimmt auch wieder; gerade die DSU sieht sehr ähnlich aus. Die D2 hatte
ich gleich wieder vergessen, kein CAN, kein Bootloader, auch kaum
lieferbar...
Jörg W. schrieb:> dsu_reset_deassert
ein gutes Stichwort, der Nebel lichtet sich ;)
Thread beobachten
Seitenaufteilung abschalten