STM32 nach dem Flashen nicht mehr erreichbar

[hochsitzcola (Gast)]

Ich habe mir mit STM32CubeMX eine Programmstruktur mit den benötigen 
IOs, Timern etc. erzeugt. Das Ganze ist ohne Fehlermeldung compiliert 
worden (mit OpenSTM32 in Eclipse). Ich habe das erzeugte Hex-file 
spaßeshalber mal geflasht, sinnvollen Inhalt hat der Code ja noch 
keinen, es wird nur die ganze Peripherie initialisiert. Nach dem Flashen 
ist nun der Controller mit dem ST-Link-Utility nicht mehr ansprechbar.
Ich habe die Clock auf internen Oszillator gestellt, da kein externer 
angeschlossen ist.

void SystemClock_Config(void)
{

  RCC_OscInitTypeDef RCC_OscInitStruct;
  RCC_ClkInitTypeDef RCC_ClkInitStruct;
  RCC_PeriphCLKInitTypeDef PeriphClkInit;

    /**Initializes the CPU, AHB and APB busses clocks 
    */
  RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSI;
  RCC_OscInitStruct.HSIState = RCC_HSI_ON;
  RCC_OscInitStruct.HSICalibrationValue = 16;
  RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
  RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSI_DIV2;
  RCC_OscInitStruct.PLL.PLLMUL = RCC_PLL_MUL16;
  if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK)
  {
    _Error_Handler(__FILE__, __LINE__);
  }

    /**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(__FILE__, __LINE__);
  }

  PeriphClkInit.PeriphClockSelection = RCC_PERIPHCLK_ADC;
  PeriphClkInit.AdcClockSelection = RCC_ADCPCLK2_DIV6;
  if (HAL_RCCEx_PeriphCLKConfig(&PeriphClkInit) != HAL_OK)
  {
    _Error_Handler(__FILE__, __LINE__);
  }

    /**Configure the Systick interrupt time 
    */
  HAL_SYSTICK_Config(HAL_RCC_GetHCLKFreq()/1000);

    /**Configure the Systick 
    */
  HAL_SYSTICK_CLKSourceConfig(SYSTICK_CLKSOURCE_HCLK);

  /* SysTick_IRQn interrupt configuration */
  HAL_NVIC_SetPriority(SysTick_IRQn, 0, 0);
}

Hier der Log des ST-Link-Utilities

18:14:26 : Device ID:0x412 
18:14:26 : Device flash Size : 32KBytes
18:14:26 : Device family :STM32F10xx Low-density
18:14:36 : Disconnected from device.
18:20:16 : [OC_01.hex] opened successfully.
18:20:16 : [OC_01.hex] checksum : 0x000DDFEA 
18:20:27 : ST-LINK SN : 53FF6C065178535441492387
18:20:27 : ST-LINK Firmware version : V2J27S6
18:20:27 : Connected via SWD.
18:20:27 : SWD Frequency = 4,0 MHz.
18:20:27 : Connection mode : Normal.
18:20:27 : Debug in Low Power mode enabled.
18:20:27 : Device ID:0x412 
18:20:27 : Device flash Size : 32KBytes
18:20:27 : Device family :STM32F10xx Low-density
18:20:59 : Memory programmed in 1s and 781ms.
18:20:59 : Verification...OK
18:20:59 : Programmed memory Checksum: 0x000DDFEA
18:21:00 : Disconnected from device.
18:21:00 : Connection to device is lost: check power supply and debug connection.
18:21:00 : If the target is in low power mode, please enable "Debug in Low Power mode" option from Target->settings menu.
18:21:13 : Can not connect to target!
                  Please select "Connect Under Reset" mode from Target->Settings menu and try again.
                  If you're trying to connect to a low frequency application , please select a lower SWD Frequency mode from Target->Settings menu.

hat jemand eine Tipp, wie ich den Prozessor wieder zum Leben erwecken 
kann?

Gruß
hochsitzcola

[pegel (Gast)]

Sicher das Übliche.
In CubeMX den SWD nicht eingeschaltet.

[hochsitzcola (Gast)]

Danke für die schnelle Antwort! Und was heißt das? Wie bekomme ich den 
Prozessor wieder ans Leben?
Die Suche nach "SWD nicht eingeschaltet" hat mich nicht 
weitergebracht...

Gruß
hochsitzcola

[pegel (Gast)]

In CubeMX unter:

System Core -> SYS -> Debug
Serial Wire

auswählen.

Während ST-Link-Utility verbinden will, Reset drücken.

[pegel (Gast)]

Vor dem nächsten flash Versuch natürlich noch einmal kompilieren.

[hochsitzcola (Gast)]

OK, werde ich morgen mal probieren. Ich komme an den Reset-Pin nicht so 
ohne weiteres ran...

Gruß
hochsitzcola

[Stefan ⛄ F. (stefanus)]

Vermutlich deaktiviert dein Programm die SWD Schnittstelle.

Während des Reset ist sie aktiv. Du musst dann die Einstellung "Connect 
under Reset" benutzen, den Reset Knopf gedrückt halten und im richtigen 
Moment beim Verbindungsaufbau loslassen.

[hochsitzcola (Gast)]

Hat funktioniert, vielen Dank für die Hilfe!

Gruß
hochsitzcola

[pegel (Gast)]

Aber wieso nimmst du das ST-Link-Utility?

Das SW4STM32 hat ein OpenOcd zum debuggen und flashen eingebaut.

[Stefan ⛄ F. (stefanus)]

pegel schrieb:
> Aber wieso nimmst du das ST-Link-Utility?
> Das SW4STM32 hat ein OpenOcd zum debuggen und flashen eingebaut.

Ist doch egal, das macht hier keinen Unterschied.

[pegel (Gast)]

Noch nicht, aber vielleicht für die Zukunft.

[hochsitzcola (Gast)]

pegel schrieb:
> Das SW4STM32 hat ein OpenOcd zum debuggen und flashen eingebaut.

Das habe ich nicht ans Laufen bekommen. Es gibt Fehlermeldungen in einem 
PopUp-Fenster:

Error in final launch sequence
Failed to execute MI command:
load C:\\LishuiFOC\\Generated\\LishuiFOC_01\\Debug\\LishuiFOC_01.elf 

Error message from debugger back end:
Error erasing flash with vFlashErase packet
Error erasing flash with vFlashErase packet

In der Console kommen diese Meldungen

Open On-Chip Debugger 0.10.0-dev-00015-gaaf1808 (2018-11-13-13:07)
Licensed under GNU GPL v2
For bug reports, read
  http://openocd.org/doc/doxygen/bugs.html
srst_only separate srst_nogate srst_open_drain connect_assert_srst
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter_nsrst_delay: 100
adapter speed: 950 kHz
Info : clock speed 950 kHz
Info : STLINK v2 JTAG v27 API v2 SWIM v6 VID 0x0483 PID 0x3748
Info : vid/pid are not identical: 0x0483/0x374B 0x0483/0x3748
Info : using stlink api v2
Info : Target voltage: 3.519368
Info : Stlink adapter speed set to 950 kHz
Info : STM32F103C6Tx.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'gdb' connection on tcp/3333
Info : Stlink adapter speed set to 950 kHz
adapter speed: 950 kHz
Error: timed out while waiting for target halted
TARGET: STM32F103C6Tx.cpu - Not halted
in procedure 'reset' 
in procedure 'ocd_bouncer'



Info : device id = 0x10006412
Info : flash size = 32kbytes
Info : Stlink adapter speed set to 950 kHz
adapter speed: 950 kHz
Error: timed out while waiting for target halted
TARGET: STM32F103C6Tx.cpu - Not halted
in procedure 'reset' 
in procedure 'ocd_bouncer'



Error: Target not halted
Error: failed erasing sectors 0 to 8
Error: flash_erase returned -304

Das gleiche Problem wurde im OpenSTM32 Forum auch schon beschrieben aber 
nicht gelöst :-(

http://www.openstm32.org/forumthread4969

Gruß
hochsitzcola

[pegel (Gast)]

Bei meinem BluePill hatte ich Anfangs auch solche Probleme.

1. in der <Projekt>.cfg musste das srst_only entfernt werden
2. Pfad und Dateiname waren zu lang
3. habe die <Projekt>.cfg in den workspace (einen Pfad höher) gelegt und 
ihr einen kürzeren Namen gegeben
4. diese in der Debug configuration auswählen

[hochsitzcola (Gast)]

Hm, die .cfg Datei wird bei jedem Mal neu erzeugt. Somit kann ich die 
Zeilen mit dem reset auskommentieren, das wird gleich wieder 
überschrieben...

# This is an LishuiFOC_01 board with a single STM32F103C6Tx chip
#
# Generated by System Workbench for STM32
# Take care that such file, as generated, may be overridden without any early notice. Please have a look to debug launch configuration setup(s)

source [find interface/stlink.cfg] 

set WORKAREASIZE 0x2800

transport select "hla_swd"

set CHIPNAME STM32F103C6Tx
set BOARDNAME LishuiFOC_01

# Enable debug when in low power modes
set ENABLE_LOW_POWER 1

# Stop Watchdog counters when halt
set STOP_WATCHDOG 1

# STlink Debug clock frequency
set CLOCK_FREQ 4000

# use hardware reset, connect under reset
# connect_assert_srst needed if low power mode application running (WFI...)
reset_config srst_only srst_nogate connect_assert_srst
set CONNECT_UNDER_RESET 1

source [find target/stm32f1x.cfg]

Gruß
hochsitzcola

[Stefan ⛄ F. (stefanus)]

hochsitzcola schrieb:
> Error: timed out while waiting for target halted
> TARGET: STM32F103C6Tx.cpu - Not halted
> in procedure 'reset'

Du hast hier wie gesagt das gleiche Problem wie mit der ST-Link 
Software. Er kann die CPU nicht anhalten, weil SWD deaktiviert ist. Auch 
hier kannst du die Option "Connect under Reset" mit manuellem Druck auf 
die Reset Taste kombinieren.

[pegel (Gast)]

Deswegen kopiere sie ein Verzeichnis höher, ändere die, benutze die.

[Max D. (max_d)]

Also in sw4stm32 kann man bei neueren Versionen bei den 
Starteinstellungen das Script konfigurieren und eine der Optionen ist 
für Hardware/Software reset.

[Stefan ⛄ F. (stefanus)]

> Hm, die .cfg Datei wird bei jedem Mal neu erzeugt.

Nicht wenn du in den Debugger Optionen bei "Configuration Script" die 
Option "User Defined" einstellt.

> Also in sw4stm32 kann man bei neueren Versionen bei den
> Starteinstellungen das Script konfigurieren und eine der
> Optionen ist für Hardware/Software reset.

Genau. Lies das mal:
http://stefanfrings.de/stm32/index.html#swj

[pegel (Gast)]

"Er kann die CPU nicht anhalten, weil SWD deaktiviert ist."

Nicht wirklich.
In dem Fall ist es das srst_only, hat mit SWD abschalten nichts zu tun.

[hochsitzcola (Gast)]

Ahh, ich musste die "generator options" erst ausklappen. Jetzt habe ich 
auf "Software system reset" gestellt, jetzt klappt es!

Vielen Dank für die Hilfe!

Gruß
hochsitzcola

[Stefan ⛄ F. (stefanus)]

hochsitzcola schrieb:
> Jetzt habe ich
> auf "Software system reset" gestellt, jetzt klappt es!

Dann ist bei Dir die SWD Schnittstelle nicht deaktiviert. So ist es 
praktischer.

[Theor (Gast)]

hochsitzcola schrieb:
> Hm, die .cfg Datei wird bei jedem Mal neu erzeugt. Somit kann ich die
> Zeilen mit dem reset auskommentieren, das wird gleich wieder
> überschrieben...
>
>

> 
> # This is an LishuiFOC_01 board with a single STM32F103C6Tx chip
...
>

Ist denn Dein Board das oben bezeichnete? Oder ist es ein Anderes?

Das der Verbindungsaufbau mit einem manuellen Reset funktioniert, sonst 
aber nicht, ist mit den Informationen die ich hier sonst lese, erst mal 
ein Zeichen, dass Reset entweder nicht angeschlossen ist oder irgendwie 
exotisch verdrahtet; was ja vorkommt.
Dass es mit Entfernung von srst_only geht, könnte das bestätigen, 
widerspricht dem jedenfalls nicht. Vermutlich nutzt er dann das 
JTAG-Reset.

Um das für die Zukunft und andere Fälle resp. Fragesteller nutzen zu 
können, wären ein paar Details hilfreich. Mindestens aber, die 
Bezeichnung des Boards bzw. der Schaltplan.