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
Die BOOT Pins so setzen das der Controller in den Bootloader startet.
Bedeutet das, du kannst das debuggen immer wieder erfolgreich neu starte? Auch nach Stromlos machen? Hänge mal deine .ioc Datei an.
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
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
Na dann ist es wieder das Übliche. Du musst in CubeMX das SWD aktivieren.
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.
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
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.
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.
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.
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.
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.
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".
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.
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.
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
Jan W. schrieb: > Leitung an NRST habe ich mir gesparrt. Funktioniert bei billig ST-Link ohne Umbau so oder so nicht.
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.
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.
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.
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.