Ich habe hier ein Curiosity Nano, welches sich nicht mehr am USB meldet. Target ist ein AVR128DA48, aber das dürfte keine größere Rolle spielen. Das Teil hat mal funktioniert, einige Einstellungen wie die Target-Spannung existieren noch so, wie sie mal gesetzt worden sind. Am USB meldet es sich rein gar nicht mehr, weder im Normal-Modus, noch im Bootloader-Modus (das Boot-Pin beim Powerup nach GND verbunden). In letzterem Fall blinkt allerdings die LED, was ich so deute, dass die eigentliche Firmware darin noch funktioniert, nur eben der USB geht nicht mehr. DM und DP von der USB-Buchse gehen direkt ohne irgendwelche Widerstände oder Schutzschaltung an den SAMD21, dazwischen kann also nichts ausgefallen sein. Die Lötstellen sowohl an der USB-Buchse (hier noch Mini-USB) als auch am SAMD21 sehen alle gut aus, da ist auch nichts abgerissen. Bleibt also nur der SAMD21 selbst. Nun kann man den zwar wechseln, aber wie bekomme ich dann die entsprechende EDBG-Firmware wieder drauf?
Hallo, Fortsetzung von hier: Beitrag "Re: USB Design mit AVR16DU14, bitte um Review" Jörg W. schrieb: > Veit D. schrieb: >> Ich denke da kann ich helfen. > > Bist du dir sicher, dass das auch auf einem jungfräulichen SAMD21 > funktioniert? Ich müsste ja den existierenden komplett tauschen. > > Aber lass uns einen separaten Thread dafür eröffnen. ----------------------------------------------------------------------- Hallo, ich denke das muss auch mit nackten µC funktionieren. Bei anderen wie AVR kann man auch den Bootloader jederzeit frisch aufspielen und später ändern und alles mit dem gleichen Tool. Gleiches Vorgehen beim Programm flashen. Klar ein gewisses Restrisiko ist da, würde auf einen Versuch ankommen. Oder man fragt vorher bei Microchip nach. Ist ja ein legaler Wunsch. :-) Anders gefragt. Welche Gründe würden dagegen sprechen?
Laut des Schaltplans eines anderen Boards mit "On-Board Nano Debugger" gibt es ein "DEBUGGER TESTPOINT" Array mit SWD. Falls der Chip nicht gesperrt ist könnte man darüber die Firmware auslesen.
Dieter S. schrieb: > Falls der Chip nicht gesperrt ist könnte man darüber die Firmware > auslesen. Ich gehe (leider) aber davon aus, dass er gesperrt ist, und ich würde daher auch vermuten, dass die EDBG-Firmware irgendwie verschlüsselt ist und der Bootloader einen passenden Key bräuchte. Aber ja, auf einem separaten SAMD21-Board kann ich das natürlich auch mal probieren. Meiner Erinnerung nach haben die SAMxx ja (im Gegensatz zu den AVRs) einen Bootloader ab Werk drin.
Veit D. schrieb: > Oder man fragt vorher bei Microchip nach. Haben wir in meiner früheren Firma mal gemacht. Sie verkaufen einem fertige EDBG-Chips, allerdings für relativ viel Geld. Aber selbst, wenn man sie als Einzelstücke bekäme: der Aufwand (Versand eines Einzelstücks) würde den Nutzen (Reparatur eines weniger als 15 Euro teuren devboards) bei weitem übersteigen.
Hallo, also du meinst die Firmwaredatei zum Download von Microchip ist nicht das komplette Programm? Der SAM hat eine Art Bootloader den es nur von Microchip mit SAM gibt und die Firmwaredatei zum Download ist das reine Programm was ausgeführt wird. Und ohne dem "Bootloader" läuft das eigentliche Programm nicht. Meinst du das so? Wäre natürlich doof. Ich würde dennoch bei Microchip nachfragen. Mir erschließt sich der Sinn nicht warum ein Teil davon Geheim ist. Das läuft doch eh nur auf deren SAM Controllern.
Hallo nochmal, wie verstehst du diesen Text? https://onlinedocs.microchip.com/oxy/GUID-B4A268FD-55AC-4EA1-A026-5F06B0F3D18E-en-US-1/GUID-CC0DF034-CA1F-4218-9211-F502EFA8C3B4.html? Ist alles im Intel .hex File drin oder doch nicht? Ich denke eine Nachfrage lohnt sich vorm Controller austauschen.
:
Bearbeitet durch User
Veit D. schrieb: > also du meinst die Firmwaredatei zum Download von Microchip ist nicht > das komplette Programm? Ich denke, dass die Firmware verschlüsselt ist und nur sinnvoll auf ein device ladbar ist, welches im Bootloader den passenden Schlüssel hat.
Hallo, also je mehr ich darüber nachdenke was im Link steht, so wie ich ihn verstehe, umso mehr denke ich man kann es legal flashen. Das besagte .hex File liegt auf meiner Platte im Studio Ordner und in der avrtools_fw.xml steht drin <avrtools_firmware build="404" date="2017-09-04" release="" tool="EDBG"><image build="438" description="Debugger MCU Firmware" fileid="1330" filename="edbg.enc" license=" ... Das alles liegt im EDBG Ordner. Das ist nicht der Ordner für die Updates. Die lauten mEDBG und nEDBG. Also für mein Verständnis kann man es riskieren den SAM zu tauschen. Einen Atmel ICE Programmer hätte ich, müsste man noch ein Kabel basteln und den SAM kontaktieren können.
Veit D. schrieb: > filename="edbg.enc" Nun darfst du raten, wofür die Endung ".enc" da ist. :-) Schon beim STK500 hatten sie die Firmware nur verschlüsselt ausgeliefert, aber damals wurde sie noch vor dem Flashen entschlüsselt, weil der Bootloader ein stinknormaler AT90S1200 (später ATtiny2313) mit einer AVR109-Firmware war. Also ja, ich kann mir mal anschauen, ob sie das auch heute noch so machen (und man mithin einen jungfräulichen SAMD21 damit flashen kann), würde mich aber wirklich wundern. Kann ich ja extern machen an einem separaten SAMD21, ich müsste irgendwo noch einen haben.
:
Bearbeitet durch Moderator
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.