STM32 F407 - CJMCU

[vfdev-5]

Hi

Being a novice on the subject, I would like to ask some support on few questions about programming and executing Chibios demo examples on a chip with STM32F407 http://www.goodluckbuy.com/cjmcu-407-stm32f407vgt6-pic-single-chip-development-board-microcontrollers-chip.html.
As this chip does not have intergrated st-link part (as Nucleo or discovery boards), I try to use SWD of STM32F401 board.
I followed https://geekilyinteresting.wordpress.com/2014/05/04/using-your-stm32f4-discovery-board-as-a-programmer-and-debugger/ and I connect similarly :
* VDD_TARGET (ST-LINK SWD F401) <-> VCC (F407)
* SW_CLK (ST-LINK SWD F401) <-> PA14 (F407)
* GND (ST-LINK SWD F401) <-> GND (F407)
* SWDIO (ST-LINK SWD F401) <-> PA13 (F407)

As there is no pin NRST on the CJMCU board, a cable (yellow on the image) was soldered to the reset button. So, NRST pin of ST-LINK SWD F401 is connected with this yellow cable on F407. My first question would be is it normal that there is no NRST pin.
To power on the chip I use micro USB cable.

Then, under Ubuntu 16.04, I am using openocd to flash a demo of Chibios on the MCU:
```
openocd.exe -f board/stm32f4discovery.cfg -c "program C:/ChibiStudio/chibios161/testhal/STM32/STM32F4xx/USB_CDC/build/ch.elf verify reset exit"
```
and this ends up with the following error :
```
GNU ARM Eclipse 64-bits Open On-Chip Debugger 0.10.0-00113-g0f83948 (2017-01-24-18:48)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 2000 kHz
adapter_nsrst_delay: 100
none separate
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : clock speed 1800 kHz
Info : STLINK v2 JTAG v19 API v2 SWIM v3 VID 0x0483 PID 0x374B
Info : using stlink api v2
Info : Target voltage: 3.254104
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
adapter speed: 2000 kHz
target halted due to debug-request, current mode: Thread
xPSR: 00000000 pc: 0xa5fd5ae0 msp: 0x913d02c0
adapter speed: 8000 kHz
** Programming Started **
auto erase enabled
Info : device id = 0x10076413
Info : flash size = 1024kbytes
Error: timeout waiting for algorithm, a target reset is recommended
Error: error executing stm32x flash write algorithm
Error: flash write failed = 00000040
Error: error writing to flash at address 0x08000000 at offset 0x00000000
** Programming Failed **
shutdown command invoked
```

I would be very grateful if somebody can hint where the problem can be.
Thanks

Victor

[Giovanni]

Hi,

I don't know, also try on the OpenOCD forum or mailing list.

What I can suggest is to use the ST-Link utility and see if the device is accessible, if so, erase it.

Giovanni

[RoccoMarco]

Hi, you have to halt the target before to issue the program command

[vfdev-5]

Thank you, Giovanni, Marco, for your answers.

I'll give another try to ST-LINK utility under Windows. I also previously tried under linux, texane/st-link (e.g. stlink-gui), and I managed to connect to the mcu and read the memory but can not flash.

Marco, can you explain, please, what do you exactly mean by "halt the target" ?

Cheers,
Victor

[Guillaume227]

Hello,
I have been checking with STLink utility on windows on behalf of @vfdev-5 and I can confirm it flashed that chip successfully, thanks for the suggestion.
On a side note, I wanted to leverage the great ChibiStudio debugging features after flashing it using STLink utility but in the debug configuration I see 'openocd, flash and run' always combined. So it keeps failing because of the flash step with the same error output as what vfdev-5 reported above.
Looking at the configuration options, I don't see a way to skip the flash step so it can just use the program flashed with STLink Utility and attach to it.
Do you know of a way to achieve that ?
Note that I have been running example code on a nucleo f401 board and setting breakpoints in ChibiStudio: it works like a charm so I have the basics right. It's just that particular f407 board is proving tricky to flash/debug from ChibiStudio.

[RoccoMarco]

Hi, it is a command issued by debugger which stops the execution of code. Usually when you use openocd before to start the program procedure you have to halt the target (whereas target is a keyword used to indicate the MCU targeted by the debugger).

Edit.
If you are using an eclipse plugin (usually it has a checkbox in setting to halt target before program). I have used "GNU ARM Plugin which as a GDB server" but indeed I prefer "Eclipse GDB hardware debugging".

The portable version of ChibiStudio for windows comes with Eclipse GBD hardware debugging. You could install and take a look to how launch files are configured

Edit 2

[steved]

Hello,
Looking at the configuration options, I don't see a way to skip the flash step so it can just use the program flashed with STLink Utility and attach to it.
Do you know of a way to achieve that ?

If you look at the 'debug configurations' option on the debug menu, it's possible to clone and edit different configurations to do different things. For example, I usually end up with three configurations - "Make, Flash and Run", "Flash and Run", and "Run"
There's an example of this, I think, in the project I uploaded in this thread

[Guillaume227]

@rocco, @steved: thanks !
I have installed ChibiStudio on Windows, it's great.

By comparing the two debug configuration xml files provided in steved's project, I notice the flash step is enabled by this :
<booleanAttribute key="org.eclipse.cdt.debug.gdbjtag.core.loadImage" value="false"/>
Now I see that it maps to the Load Image checkbox on the Startup tab, makes sense, that's the flash step.

Just to make sure I understand, the "Reset and Delay", "Halt" checkboxes and the text field below relate to the open OCD step right?