Hallo. Ich hab da ein etwas dubioses Problem mit mehreren (3 Stück) STM32F051, die sich nicht flashen lassen wollen. Chips sind neu, verbaut auf 4 lagiger Platine mit guter stabiler Stromversorgung, entkoppelt, und lassen sich per SWD auch ansprechen. Dummerweise scheint aus irgendeinem Grund das Option Byte in Speicherstelle 0x1ffff800 den Wert 0xffffff02 zu haben, was so viel heisst wie dass die Readout-Protection gesetzt ist, und sich das Ding also nicht flashen lässt. Zurücksetzen des Optionsbytes mit dem ST ST-link funktioniert nicht (Timeout nach ca. 1 Minute herumgeblinke mit dem Hinweis "reset target and try again"). Selbes Ergebnis mit OpenOCD. Weder "stm32f1x unlock 0" noch manuell die magische Sequenz per mww nach 0x4002200xx zum Entsperren der Optionbytes reinklopfen und schreiben nach 0x1ffff800 funktioniert. Beim finalen Schreibzugriff auf 0x1ffff800 gibts einen Fehler in der swd state machine. texane/st-link tools von github funktionieren auch nicht. st-flash erase geht zwar ohne Fehler durch, tut aber nichts. st-flash write bricht mit Fehler ab. Versuche das Ding über den Bootloader zu flashen sind bis jetzt auch gescheitert, er scheint zwar den Bootloader zu aktivieren (extern BOOT0 auf high), man sieht das wenn man per OpenOCD den Prozessor anhält, aber Kontakt über USART konnte ich keinen herstellen. Programmiergerät ist ein st-link v2.1 von einem nucleo L476 board. Funktioniert mit anderen STM32Fx (auch STM32F051) tadellos. Bin etwas ratlos. Hat wer eine Idee was man noch überprüfen könnten.
So einen Kandidaten hatte ich auch schon mal. Mit durchprobieren der verschiedenen "Reset Mode" im STM32CubeProgrammer habe ich es dann irgendwie geschafft das Problem zu lösen.
pegel schrieb: > Mit durchprobieren der verschiedenen "Reset Mode" im STM32CubeProgrammer > habe ich es dann irgendwie geschafft das Problem zu lösen. Verschiedene reset-configs haben keinen Unterschied gemacht, ich glaub auch nicht, dass es daran liegt, ich kann per OpenOCD ja mit dem Target kommunizieren, verschiedene Speicherstellen lesen und schreiben, und das tut auch. Die FLASH und OPT unlock-Sequenz führt eindeutig zu den folgerichtig gesetzten Bits im FLASH_CR Register.
Wird immer seltsamer. Option bytes kann man löschen/programmieren. Das einzige, was sich nicht machen lässt, ist die Readout-Protection entfernen.
Hast du schon die neueste Version 1.1.0 vom STM32CubeProgrammer probiert? Vielleicht gibt es da neue Möglichkeiten.
Es könnte irgendein Bug im internen Status-Handling des ST-Links sein. Der macht da ja relativ viel selbständig und kann vom OpenOCD nicht vollkommen frei angesteuert werden. Hast Du die neueste Firmware in Deinem ST-Link? Hast Du zufällig auch noch etwas anderes als den ST-Link zur Hand? Z.B. ein FTDI-Adapter der von OpenOCD unterstützt wird, eine Black Magic Probe, ein J-Link etc.? Du könntest auch mal versuchen den ST-Link auf dem Nucleo-Board zu einem J-Link OB umzuflashen. Dafür gibt es ja bei ST das Tool von Segger zum Download. Das kann man auch verwenden um später wieder zum ST-Link zurückzuwechseln wenn man möchte.
Ich hab jetzt einen RaspberryPi mit OpenOCD und SWD über GPIO ausprobiert, selbes Ergebnis. Bin gerade dabei den Cube-Programmer zu versuchen. Einen ST-Link auf BlackMagic zu flashen hab ich auch noch vor, und ich glaub eine Segger-Firmware gäbs auch für den ST-Link. Bin aber nicht besonders optimistisch, die unlock-Scripts hier https://wiki.segger.com/STM32 kann man auch zu Fuss per OpenOCD nachvollziehen, und das tut nichts.
Robert S. schrieb: > Ich hab jetzt einen RaspberryPi mit OpenOCD und SWD über GPIO > ausprobiert, selbes Ergebnis. ok, mit den Raspi-GPIOs ist das OpenOCD nicht mehr von irgendwelchen internen Routinen eines ST-Links abhängig, sondern kann selbst frei schalten und walten. Klingt mir ein wenig als ob ST die Dinger mit falschen Daten im Hersteller-Flash ausgeliefert hat. Scheint selten aber dennoch vorzukommen. Ich erinnere mich daß mal hier im Forum Leute von seltsamen Werten im Register für die Flashgröße berichtet haben. Das ist ja genauso wie die Kalibrierwerte auch etwas, was ST einmalig bei der Herstellung schreibt und diesen Bereich dann irgendwie auf Nur-Lesen umschaltet. Ich könnte mir jetzt gut vorstellen daß dieser Vorgang intern mit der selben Einheit gemacht wird, die die Option Bytes verwaltet und daher ein Fehler dort Auswirkungen auf die Option Bytes haben kann.
1 | ~/local/STMicroelectronics/STM32Cube/STM32CubeProgrammer/bin$ ./STM32_Programmer_CLI -c port=SWD mode=UR reset=hwrst -rdu |
2 | ------------------------------------------------------------------- |
3 | STM32CubeProgrammer v1.1.0 |
4 | ------------------------------------------------------------------- |
5 | |
6 | ST-LINK SN : 066DFF505052876767042327 |
7 | ST-LINK FW : V2J29M18 |
8 | Voltage : 3.26V |
9 | SWD freq : 4000 KHz |
10 | Connect mode: Under Reset |
11 | Reset mode : Hardware reset |
12 | Device ID : 0x440 |
13 | Device name : STM32F051x4/STM32F051x6/STM32F051x8/STM32F030x8 |
14 | Device type : MCU |
15 | Device CPU : Cortex-M0 |
16 | |
17 | |
18 | Disabling memory Read Protection... |
19 | |
20 | |
21 | Reconnecting... |
22 | ST-LINK SN : 066DFF505052876767042327 |
23 | ST-LINK FW : V2J29M18 |
24 | Voltage : 3.26V |
25 | SWD freq : 4000 KHz |
26 | Connect mode: Under Reset |
27 | Reset mode : Hardware reset |
28 | Device ID : 0x440 |
29 | Reconnected ! |
30 | |
31 | Error: Disabling memory Read Protection failed |
Diverse andere Kombinationen von Reset-Methoden führen auch zu keinem anderen Ergebnis. -ob displ liefert auch nichts Interessantes:
1 | ./STM32_Programmer_CLI -c port=SWD mode=UR reset=hwrst -ob displ |
2 | ------------------------------------------------------------------- |
3 | STM32CubeProgrammer v1.1.0 |
4 | ------------------------------------------------------------------- |
5 | |
6 | ST-LINK SN : 066DFF505052876767042327 |
7 | ST-LINK FW : V2J29M18 |
8 | Voltage : 3.26V |
9 | SWD freq : 4000 KHz |
10 | Connect mode: Under Reset |
11 | Reset mode : Hardware reset |
12 | Device ID : 0x440 |
13 | Device name : STM32F051x4/STM32F051x6/STM32F051x8/STM32F030x8 |
14 | Device type : MCU |
15 | Device CPU : Cortex-M0 |
16 | |
17 | |
18 | UPLOADING OPTION BYTES DATA ... |
19 | |
20 | Bank : 0x00 |
21 | Address : 0x1ffff800 |
22 | Size : 16 Bytes |
23 | |
24 | [==================================================] 100% |
25 | |
26 | |
27 | OPTION BYTES BANK: 0 |
28 | |
29 | Read Out Protection: |
30 | |
31 | RDP : 0xFF (Level 1, read protection of memories) |
32 | |
33 | User Configuration: |
34 | |
35 | WDG_SW : 0x1 (Software watchdog) |
36 | nRST_STOP : 0x1 (No reset generated) |
37 | nRST_STDBY : 0x1 (No reset generated) |
38 | nBOOT1 : 0x1 (Boot from system memory when BOOT0=1) |
39 | VDDA_MONITOR : 0x1 (VDDA power supply supervisor enabled) |
40 | RAM_PARITY : 0x1 (RAM parity check disabled) |
41 | |
42 | User Data: |
43 | |
44 | Data0 : 0xFF (0xFF) |
45 | Data1 : 0xFF (0xFF) |
46 | |
47 | Write Protection: |
48 | |
49 | nWRP0 : 0x1 (Write protection not active on this sector) |
50 | nWRP1 : 0x1 (Write protection not active on this sector) |
51 | nWRP2 : 0x1 (Write protection not active on this sector) |
52 | nWRP3 : 0x1 (Write protection not active on this sector) |
53 | nWRP4 : 0x1 (Write protection not active on this sector) |
54 | nWRP5 : 0x1 (Write protection not active on this sector) |
55 | nWRP6 : 0x1 (Write protection not active on this sector) |
56 | nWRP7 : 0x1 (Write protection not active on this sector) |
57 | nWRP8 : 0x1 (Write protection not active on this sector) |
58 | nWRP9 : 0x1 (Write protection not active on this sector) |
59 | nWRP10 : 0x1 (Write protection not active on this sector) |
60 | nWRP11 : 0x1 (Write protection not active on this sector) |
61 | nWRP12 : 0x1 (Write protection not active on this sector) |
62 | nWRP13 : 0x1 (Write protection not active on this sector) |
63 | nWRP14 : 0x1 (Write protection not active on this sector) |
64 | nWRP15 : 0x1 (Write protection not active on this sector) |
Ich werds dann bleiben lassen und die MCUs tauschen. Irgendwas an den Dingern ist definitiv sehr seltsam. Wollte nur sichergehen dass ich nichts Offensichtliches übersehen habe. Danke für alle Hinweise.
:
Bearbeitet durch User
Was mich dabei wundert: Read Protection != Write protection D.h. du solltest über ST Link oder Bootloader eine Firmware flashen können. Bzw. sollte der Bootloader auch mit dem STM kommunizieren können und dich dann darauf hinweisen das es einen Read Protection gibt. Und noch mehr wundert mich, dass es gleich 3 Chips betreffen soll. Kannst du mal einen Schaltplan (wenigstens von der STM belegeung) posten? Ich hab da vielleicht eine Idee.
Angehängte Dateien:
-
stm32f051.png
8,9 KB
john schrieb: > Read Protection != Write protection > > D.h. du solltest über ST Link oder Bootloader eine Firmware flashen > können. > Bzw. sollte der Bootloader auch mit dem STM kommunizieren können und > dich dann darauf hinweisen das es einen Read Protection gibt. naja, mich wundert das ja auch ;-) Das mit dem Bootloader ist nicht ganz so einfach, da die Chips UFQFPN32 sind (STM32F051K8U), und die Pins PA9/PA10 bzw. PA15 auf eine Art verschaltet sind dass man das in circuit nicht so leicht abgreifen bzw. vom Rest der Schaltung isolieren kann. Werde das aber auch noch probieren, muss dazu allerdings noch etwas explantieren. Hab den relevanten Teil des Schaltplans angehängt, der Rest sind ein opamps, i²c geräte und ein paar Transistoren/Treiber. Anm.: ja, der Connector ist ungewöhnlich verschaltet. Die 100p auf den SWD-Leitungen machen auch keinen Unterschied zwischen bestückt/nicht bestückt.
:
Bearbeitet durch User
Eine Theorie von mir ist noch Brown Out beim Löschen des Flash-Speichers, eventuell durch mangelhafte Lötverbindung im Massepad. Lässt sich im sichtbaren EM-Spektrum aber nur schwer überprüfen ob das passt.
Robert S. schrieb: > Hab den relevanten Teil des Schaltplans angehängt Nichts an den Pins des STM32 dran? oder nur rausgelöscht für uns? Was mir spontan eingefallen war. Es gibt mehrere Bootloader, auszuwählen über Boot0 und Boot1. Wenn bei dir Boot1 (ich glaube PB2) auf High oder Low gezogen wird, könnte ein Bootloader aktiviert werden der dir in die Suppe spukt. Die 2. Idee: deine I2C geräte. Der Bootloader im STM32 kann auch über I2C (oder SPI usw) den flash updaten. Diesen Fehler hatte ichauch schonmal. Wenn über I2C als erstes irgendwelche Signale kommen (vor der Uart), dann hört der Bootloader nur noch auf die I2C und nicht auf die UART. Es reicht eventuell schon eine flanke auf der I2C. Der Bootloader muss immer funktionieren, zumindest die Verbindung. Ich ziehe den Bootloader immer der SWD vor, weil dieser Problemlos läuft und mit jedem UART-USB Kabel nutzbar ist.
Robert S. schrieb: > Ich hab da ein etwas dubioses Problem mit mehreren (3 Stück) STM32F051, > die sich nicht flashen lassen wollen. Chips sind neu, verbaut auf 4 > lagiger Platine mit guter stabiler Stromversorgung, entkoppelt, und > lassen sich per SWD auch ansprechen. Poste mal ein paar Fotos und die Leiterplattenfiles
john schrieb: > Es gibt mehrere Bootloader Besser gesagt Boot Pattern. "The STM32F05xxx and STM32F030x8 devices boot loader is activated by applying pattern2" Pattern2 = UART 1&2 "Pattern2 Boot0(pin) = 1 and Boot1(bit) = 1" Das mit dem I2C Bootloader scheint es nicht bei STM32F051 zu geben. War bei mir am F4 der Fall.
Bosk schrieb: > Poste mal ein paar Fotos und die Leiterplattenfiles kann ich nicht veröffentlichen, aber es ist alles sauber gelötet, die dinger sind prototypen, bestückt und gelötet in einer fertigungslinie. 4 lagiger aufbau, die inneren lagen haben GND und +3V3. Den Massepads hätte man eventuell etwas mehr als eine dicke Duko verpassen können, aber dass es daran liegt finde ich unwahrscheinlich. Mit Prozessoren aus einer anderen Charge funktioniert der Aufbau und lässt sich anstandslos flashen und debuggen. Ob der Bootloader aktiv ist oder nicht sehe ich wenn ich mit dem Debugger verbinde, ohne gesetzten BOOT0 Pin landet er im Debugger in einem HardFault weil bei gesetzter RDP das Flash unlesbar wird sobald man SWD aktiviert und auf irgendeinen Bus zugreift. Nichtsdestotrotz sollte sich das Ding auch über SWD flashen lassen, vor allem von den ST eigenen Interfaces und der ST-Software. Seltsam finde ich auch die CPU-ID im MCU_DBG Register, die liefert als Revision 0x2000, das sollte es aber beim F051 gar nicht geben laut RefMan.
:
Bearbeitet durch User
Nochmal zusammengefasst: * Ab Werk Zustand der Option-Bytes war "gelöscht", d.h. alle auf 0xffffffff, das impliziert aktivierte Readout-Protection Level 1 * Option bytes lassen sich über OpenOCD löschen * Option bytes lassen sich über OpenOCD programmieren, ausser * 0x1ffff800 lassen sich alle probierten Werte ausser 0x55aa schreiben, da gibts Reset. Aktivierung von RDP level 2 hab ich nicht probiert (da nicht reversibel) * STM Cube Programmer und ST-Link-Tools können über st-link auch nichts ausrichten * OpenOCD über ST-Link und RaspberryPi GPIO versucht * linux st-link tools ditto * bootloader ist aktivierbar (sieht man weil bei Verbindung mit openocd der PC in einer Adresse zwischen 0x1FFFEC00 und SRAM steht), ist aber nicht gesprächig
Robert S. schrieb: > Mit Prozessoren aus einer anderen Charge funktioniert der Aufbau und > lässt sich anstandslos flashen und debuggen. China clone?
Robert S. schrieb: > Seltsam finde ich auch die CPU-ID im MCU_DBG Register, die liefert als > Revision 0x2000, das sollte es aber beim F051 gar nicht geben laut > RefMan. Das ist ein ziemlich sicheres Zeichen daß das welche sind, bei denen die initiale Programmierung in der Fabrik von ST nicht korrekt durchgelaufen ist.
So, jetzt ist mit einem Austausch-Prozessor das selbe "passiert". Lässt sich von jetzt auf da nicht mehr programmieren, readout-protection ist aktiviert. Option bytes kann man löschen und auch programmieren, nur der magische Wert zum Rücksetzen der Readout-Protection funktioniert nicht. Prozessor wurde insgesamt vielleicht 20mal programmiert.
Reset nach dem Programmieren der Option Bytes ausgefuehrt?
UweBonnes schrieb: > Reset nach dem Programmieren der Option Bytes ausgefuehrt? Der Controller macht von selber einen Reset. Manuell ausgeführter Reset oder Powercycle macht alles keinen Unterschied. Auf einem "guten" µC lässt sich nach Setzen der Readout-Protection mit dem Verfahren oben selbige rücksetzen, auf den "schlechten" gibts reset und sonst passiert nichts.
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.