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
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
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.
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
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.
