Forum: Mikrocontroller und Digitale Elektronik STM32F103 "verfused"? Wie kann ich ihn wiederbeleben?


von Michael (Gast)


Lesenswert?

Hallo,

ich habe eine dringliche Frage an euch:


gibt es eine Möglichkeit, die Taktquellenkonfiguration eines 
STM32F103R8Cb aus einem "toten Zustand" heraus zu verändern und z.B. auf 
den Werksausgangszustand zurückzusetzen? Bei AVRs hätte man 
wahrscheinlich von verfused gesprochen.


Hintergrund:

Ich blicke gerade auf zwei tote STM32F103C8RB. Grund des Ablebens: ich 
habe versucht, sie mit CubeMX zu konfigurieren. Den Ersten, um ein 
Programm zum Laufen zu bringen, den Zweiten, um herauszufinden, warum 
der Erste nichts mehr tut...

Die mit CubeMX erstellte Konfiguration wurde in ein Projekt übernommen 
und mit einem Testprogramm erweitert, kompiliert und anschließend 
mittels STLink V2 debugged. Als IDE verwende ich TrueStudio von Atollic, 
V.9.2.

Ich vermute, dass der Fehler an einer falschen Konfiguration des 
primären Taktgebers liegt, denn das Debugging beginnt normal und kann 
bis einen Schritt nach SystemClock_Config() durchgeführt werden. Dann 
bricht die Verbindung zwischen STLink und Controller ab und kann auch 
durch Neustart des Debuggvorganges oder durch Neuverbindung von STLink 
oder Zielhardware nicht wieder hergestelt werden. Somit ist eine 
weitergehende Untersuchung des Problems für mich schwierig.

Der Takt wird durch einen externen CMOS-Oszillator mit 8MHz vorgegeben. 
Dieser Takt konnte erfolgreich gemessen werden, liegt somit über OSC_IN 
an HSE an. An OSC_32 ist ein 32kHz Quarz angeschlossen.

Da diese Taktquelle nicht funktioniert, wurde für den zweiten Test ein 
8MHz Quarz für OSC_IN verwendet. Dieser schwingt zunächst an und bleibt 
nach dem Erreichen der genannten Programmzeile stehen.

Codebeispiel:

int main(void)
{
  HAL_Init();

  SystemClock_Config();

  // Ab hier bleibt die MCU stehen.
  MX_GPIO_Init();

  MX_SPI1_Init();
  MX_SPI2_Init();

  MX_USART1_UART_Init();

  MX_RTC_Init();

  MX_NVIC_Init();

  uint8_t src[5]="hello";
  while (1)
  {
....

void SystemClock_Config(void)
{
  RCC_OscInitTypeDef RCC_OscInitStruct = {0};
  RCC_ClkInitTypeDef RCC_ClkInitStruct = {0};
  RCC_PeriphCLKInitTypeDef PeriphClkInit = {0};

  /**Initializes the CPU, AHB and APB busses clocks
  */
  RCC_OscInitStruct.OscillatorType = 
RCC_OSCILLATORTYPE_HSE|RCC_OSCILLATORTYPE_LSE;
  RCC_OscInitStruct.HSEState = RCC_HSE_BYPASS;
  RCC_OscInitStruct.HSEPredivValue = RCC_HSE_PREDIV_DIV1;
  RCC_OscInitStruct.LSEState = RCC_LSE_BYPASS;
  RCC_OscInitStruct.HSIState = RCC_HSI_ON;
  RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
  RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;
  RCC_OscInitStruct.PLL.PLLMUL = RCC_PLL_MUL9;
  if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK)
  {
    Error_Handler();
  }
  /**Initializes the CPU, AHB and APB busses clocks
  */
  RCC_ClkInitStruct.ClockType = RCC_CLOCKTYPE_HCLK|RCC_CLOCKTYPE_SYSCLK
                              |RCC_CLOCKTYPE_PCLK1|RCC_CLOCKTYPE_PCLK2;
  RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_PLLCLK;
  RCC_ClkInitStruct.AHBCLKDivider = RCC_SYSCLK_DIV1;
  RCC_ClkInitStruct.APB1CLKDivider = RCC_HCLK_DIV2;
  RCC_ClkInitStruct.APB2CLKDivider = RCC_HCLK_DIV1;

  if (HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_2) != 
HAL_OK)
  {
    Error_Handler();
  }
  PeriphClkInit.PeriphClockSelection = RCC_PERIPHCLK_RTC;
  PeriphClkInit.RTCClockSelection = RCC_RTCCLKSOURCE_LSE;
  if (HAL_RCCEx_PeriphCLKConfig(&PeriphClkInit) != HAL_OK)
  {
    Error_Handler();
  }
}

Vielen Dank für eure Hilfe!

MfG

Michael

von Johannes S. (Gast)


Lesenswert?

Die BOOT Pins so setzen das der Controller in den Bootloader startet.

von pegel (Gast)


Lesenswert?

Bedeutet das, du kannst das debuggen immer wieder erfolgreich neu 
starte?
Auch nach Stromlos machen?

Hänge mal deine .ioc Datei an.

von Michael (Gast)


Lesenswert?

Hallo Johannes,

ich bin mit den STM32 noch nicht so vertraut, habe aber auch an 
derartiges gedacht und die BOOT0/1 Konfiguration variiert, bislang ohne 
Erfolg.

Könntest du mir den Prozess etwas genauer beschreiben?

1.
Datasheet, stm32f103tb.pdf:

Boot modes
At startup, boot pins are used to select one of three boot options:
• Boot from User Flash
• Boot from System Memory
• Boot from embedded SRAM
The boot loader is located in System Memory. It is used to reprogram the 
Flash memory by
using USART1. For further details please refer to AN2606.

2.
AN2606

13. STM32F10xxx devices bootloader

Boot0(pin) = 1 and Boot1(pin) = 0

3. Nach AN2606 wird der Controller initialisiert und wartet dann am 
USART auf das Kommando 0x7F. Solange bleibt der Chip in einer Schleife.

Kann ich in dieser Schleife über SWD auf den Chip zugreifen oder muss 
ich zwingend den USART verwenden? Benötige ich hierfür ein 
weitergehendes Tool?

Ich werde das morgen gleich testen.

Vielen Dank für deinen Tipp, ich hoffe, er hilft mir weiter.

MfG

Michael

von Michael (Gast)


Lesenswert?

Hallo pegel,

das geht natürlich nicht :).

Ablauf:

1. ich starte eine Debugsession und übertrage den Code in einen 
werksneuen  Mikrocontroller.
2. Das Programm kann ich dann ab initialem Einsprungspunkt schrittweise 
druchlaufen.
3. An besagter Stelle bleibt der Debugger stehen und rührt sich nicht 
mehr.
4. Nachdem ich die Debugsession neu gestartet habe, findet TrueStudio 
kein Device am Debugger. Dieser Zustand bleibt auch bestehen, nachdem 
ich die Zielhardware und/oder den Debugger stromfrei geschaltet habe.

Daher schrieb ich von "tot".

Die erbetene Datei habe ich auf einem anderen Rechner, werde sie aber 
gerne ab morgen beilegen.

MfG

Michael

von pegel (Gast)


Lesenswert?

Na dann ist es wieder das Übliche.
Du musst in CubeMX das SWD aktivieren.

von Jim M. (turboj)


Lesenswert?

Bei den STLinks (und anderen Programmern für STM32) gibt es 
normalerweise die "Connect under Reset" Option genau für den Fall dass 
man sich die Debug Pins oder Taktquelle abschiesst.

von Jan W. (gaffel-k)


Lesenswert?

Ich hatte letztens auch einen verfusten STM32F103, habe natürlich 
vergessen in CubeMX die SWD Schnittstelle zu aktivieren.

Wiederbeleben konnte ich ihn mit STM32CubeProgrammer. Man muss die 
Verbindung herstellen wenn die Reset-Taste gedrückt ist, dann connected 
der sich.
Dann ein mal "Full Chip Erase" und bei mir lief es wieder.

Jan

von Mike R. (thesealion)


Lesenswert?

Die einzige Möglichkeit einen STM32F103 zu "verfusen" ist es im Option 
Byte das Read Out Flag Level 2 zu setzen.

Mit der Takt Konfiguration ist es nicht möglich sich komplett 
auszusperren (Der Controller startet immer mit dem internen Oszillator 
und wechseln die Taktquelle erst durch deine Firmware.

von Marcel (Gast)


Lesenswert?

Du nutzt als PLL Quelle den externen Taktgeber
1
RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;

aber aktivierst HSE nicht als Taktquellle
1
RCC_OscInitStruct.HSEState = RCC_HSE_BYPASS;

Also entweder RCC_HSE_ON setzen oder die PLL Quelle auf HSI ändern.

von Bimbo. (Gast)


Lesenswert?

SWD benutzen und dann auch die Reset Leitung verwenden (NRST). Die STM32 
kann man nicht verfusen und ein programmieren geht immer!

Wenn man natürlich SWD ohne Resetleitung verwendet kann es schwierig 
werden.

von STM Doctor (Gast)


Lesenswert?

Bimbo. schrieb:
> Wenn man natürlich SWD ohne Resetleitung verwendet kann es schwierig
> werden.

Ein bisschen Fingerspitzengefühl an der Reset-Taste, und
schon ist der Programmierer wieder glücklich.

von Bimbo. (Gast)


Lesenswert?

STM Doctor schrieb:
> Ein bisschen Fingerspitzengefühl an der Reset-Taste, und
> schon ist der Programmierer wieder glücklich.

Und wer bezahlt dir diesen Einsatz, wenn du einen STM ca. 10 mal pro 
Stunde neu programmieren möchtest und da jedesmal 5 Minuten für 
brauchst, weil du GLÜCK brauchst, damit du mal durch kommst? NRST 
verwenden, als andere ist Glücksspiel.

von STM Doctor (Gast)


Lesenswert?

Wer seinen STM dauernd ver-fused hat es offensichtlich versäumt
aus seinen Erfahrungen die entsprechenden Lehren zu ziehen.

Dann muss er eben auf diese Weise Lehrgeld zahlen ....

Bimbo. schrieb:
> weil du GLÜCK brauchst

Ich brauche kein "GLÜCK".

von Axel S. (a-za-z0-9)


Lesenswert?

Jan W. schrieb:
> Ich hatte letztens auch einen verfusten STM32F103

Weil ich das jetzt schon zum zweiten Mal lese: das mit "verfused" ist 
Unsinn. EIn STM32 hat keine Fuses für die Taktversorgung oder für SWD. 
Wenn das abgeschaltet (SWD) bzw. fehlkonfiguriert ist (Takt), dann 
passiert das im Programm. Der STM32 startet immer mit aktiviertem SWD 
und einer funktionierenden (weil internen) Taktquelle.

Und damit ist auch klar, wie man da raus kommt: man muß verhindern, daß 
das (eigene) Programm in Flash ausgeführt wird. Entweder indem man den 
STM in den Bootloader springen läßt. Oder indem man mit dem ST-Link 
(oder was immer man als SWD-Adapter verwendet) ein "connect under reset" 
macht. Dabei wird Reset des µC auf L gehalten und währenddessen eine 
SWD-Verbindung gemacht. Das setzt natürlich voraus, daß man die nRST 
Leitung des Targets rausgeführt und mit dem Adapter verbunden hat.

von STM Doctor (Gast)


Lesenswert?

Schon klar, Axelo .... verfused ist hier der lasche
Ausdruck für eine Fehl-Konfiguration via Programm ...

Axel S. schrieb:
> Das setzt natürlich voraus, daß man die nRST
> Leitung des Targets rausgeführt und mit dem Adapter verbunden hat.

Wie breits gesagt, mit Fingerspitzengefühl geht's auch mit der
Reset-Taste.

von Jan W. (gaffel-k)


Lesenswert?

Ok, habe "verfust" nur aufgenommen, weil der TO das beschrieben hat.

Bei mir war halt einfach nur die SWD Schnittstelle nicht aktiviert durch 
mein Programm, deswegen musste das erst mal wieder gelöscht werden.

Hab es übrigens auch mit "Fingerspitzengefühl" hinbekommen, Leitung an 
NRST habe ich mir gesparrt.

Jan

: Bearbeitet durch User
von pegel (Gast)


Lesenswert?

Jan W. schrieb:
> Leitung an NRST habe ich mir gesparrt.

Funktioniert bei billig ST-Link ohne Umbau so oder so nicht.

von Bimbo. (Gast)


Lesenswert?

Jan W. schrieb:
> Bei mir war halt einfach nur die SWD Schnittstelle nicht aktiviert durch
> mein Programm, deswegen musste das erst mal wieder gelöscht werden.
>
> Hab es übrigens auch mit "Fingerspitzengefühl" hinbekommen, Leitung an
> NRST habe ich mir gesparrt.

Dann in Zukunft immer NRST + originalen ST-Link verwenden. Dann kannst 
du dich auch nicht aussperren.

von W.S. (Gast)


Lesenswert?

Michael schrieb:
> 1. ich starte eine Debugsession und übertrage den Code in einen
> werksneuen  Mikrocontroller.

Tja.

Es ist eben immer vorteilhaft, sowohl die BOOTx Pin(s) als auch Reset 
und RxD und TxD vom ersten UART an irgend einen Steck oder wenigstens an 
ein Testpad zu legen, um mittels Bootlader an den Chip heranzukommen.

W.S.

von Stefan F. (Gast)


Lesenswert?

Jan W. schrieb:
> Bei mir war halt einfach nur die SWD Schnittstelle nicht aktiviert

Eigentlich anders herum: Dien Programm hat sie absichtlich deaktiviert. 
Denn aktiviert ist die defaultmäßig schon während und nach dem Reset.

Dass CubeMX plötzlich den deaktivierten Zustand zur Vorgabe gemacht hat, 
ist einer von vielen kleinen Gründen, warum ich CubeMX nicht mag.

Bitte 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
Noch kein Account? Hier anmelden.