0
\$\begingroup\$

Introduction

Getting in touch for the first time with an ARM MCU (the STM32F407ZE), I am trying to generate a first working "Hello world!" blinking led.

For programming the MCU, it seem possible with just a RaspberryPi directly connected to the MCU, through JTAG and using OpenOCD.

First steps are:

  • Getting/Compiling OpenOCD on the Raspberry PI (done)
  • Wiring the JTAG of the Raspberry with the STM32F407ZE (not sure if correct)
  • Trying to open a communication with the chip (failed)

The wiring:

Documentation about the MCU (p.43 and 47-59)

╔═══════╦══════════╦══════════╦═════════════╗
║ Name  ║ GPIO pin ║ MCU port ║ Cable color ║
╠═══════╬══════════╬══════════╬═════════════╣
║ JTCK  ║ 22       ║ 109      ║ blue        ║
║ JTMS  ║ 13       ║ 105      ║ red         ║
║ JTDI  ║ 37       ║ 110      ║ white       ║  
║ JTDO  ║ 18       ║ 133      ║ green       ║  
║ RSTS  ║ 12       ║ 134      ║ violet      ║  
╚═══════╩══════════╩══════════╩═════════════╝

The GND of the RP2 is connected to the MCU VSS pin 107 (black)
I tried with and without the 3.3V of the RP2 connected to VDD-108 (yellow)

Wiring

OpenOCD configuration

The only configuration which is modified is the one of the raspberry pi:

/usr/local/share/openocd/scripts/interface/raspberrypi2-native.cfg

#
# Config for using Raspberry Pi's expansion header
#
# This is best used with a fast enough buffer but also
# is suitable for direct connection if the target voltage
# matches RPi's 3.3V and the cable is short enough.
#
# Do not forget the GND connection, pin 6 of the expansion header.
#

interface bcm2835gpio

bcm2835gpio_peripheral_base 0x3F000000

# Transition delay calculation: SPEED_COEFF/khz - SPEED_OFFSET
# These depend on system clock, calibrated for stock 700MHz
# bcm2835gpio_speed SPEED_COEFF SPEED_OFFSET
bcm2835gpio_speed_coeffs 146203 36

# Each of the JTAG lines need a gpio number set: tck tms tdi tdo
# Header pin numbers: 22  13  37  18
bcm2835gpio_jtag_nums 25  27  26  24

# Each of the SWD lines need a gpio number set: swclk swdio
# Header pin numbers: 23 22
#bcm2835gpio_swd_nums 11 25

# If you define trst or srst, use appropriate reset_config
# Header pin numbers: TRST - 26, SRST - 18

# bcm2835gpio_trst_num 7
# reset_config trst_only

bcm2835gpio_srst_num 18
reset_config srst_only srst_push_pull

# or if you have both connected,
# reset_config trst_and_srst srst_push_pull

Usage and result

Calling openOCD with the following command:

> sudo openocd -f ./my_raspberrrypi2-native.cfg -f target/stm32f4x.cfg

The output is:

Open On-Chip Debugger 0.10.0+dev-00410-gf0767a31 (2018-05-18-20:15)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
BCM2835 GPIO config: tck = 25, tms = 27, tdi = 26, tdo = 24
BCM2835 GPIO config: srst = 18
srst_only separate srst_gates_jtag srst_push_pull connect_deassert_srst
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
adapter speed: 2000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
srst_only separate srst_nogate srst_push_pull connect_deassert_srst
cortex_m reset_config sysresetreq
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : BCM2835 GPIO JTAG/SWD bitbang driver
Info : JTAG only mode enabled (specify swclk and swdio gpio to add SWD mode)
Info : clock speed 2002 kHz
Error: JTAG scan chain interrogation failed: all zeroes
Error: Check JTAG interface, timings, target power, etc.
Error: Trying to use configured scan chain anyway...
Error: stm32f4x.cpu: IR capture error; saw 0x00 not 0x01
Warn : Bypassing JTAG setup events due to errors
Error: Invalid ACK (0) in DAP response
Error: Invalid ACK (0) in DAP response
... //some removed here
Error: Invalid ACK (0) in DAP response
Error: Invalid ACK (0) in DAP response
in procedure 'init'
in procedure 'ocd_bouncer'

It seem the raspberry pi is sending, but the MCU does not respond. JTDO stay silent.

Logic analyser result Note: the second view is a zoom on the part seemingly containing data.

Question

Is the approach for programming the ARM MCU acceptable?

Why is the MCU not communicating through JTAG?

\$\endgroup\$
  • 1
    \$\begingroup\$ Disconnect JTDO from the Raspberry Pi, so that it is only between the target MCU and the logic analyzer. Now do you get transitions? You may need pullup resistors (or for some signals, pulldown). \$\endgroup\$ – Ben Voigt May 20 '18 at 2:12
  • 1
    \$\begingroup\$ Also, if your MCU is socketed in a universal breakout board, rather than one designed specifically for it, then it won't have power and ground signals routed. You will have to connect ALL of the MCU's power and ground pins, plus bypass capacitors, in order to make it happy. (If the "pin type" shows as "S" in the datasheet table of pins, you need to hook it up) \$\endgroup\$ – Ben Voigt May 20 '18 at 2:19
  • \$\begingroup\$ Thanks, I am used to simple PICs (e.g. PIC16F170x) which you connect and run. This seem more advanced. I will come back after a bit of investigation and testing. The JTDO suggestion is good but did not made any difference. \$\endgroup\$ – Adrian Maire May 20 '18 at 15:36
  • 1
    \$\begingroup\$ The JTDO suggestion was not a "fix" but a troubleshooting step designed to gather information. Since the target MCU alone is not generating JTDO transitions, the problem is not the Raspberry Pi's configuration / connection, but that the target MCU is not properly powered. Note that the difference from your past experience is almost certainly not between PIC and ARM, but between 14/20 pin chip and 144 pin chip. High pin count PIC chips also require multiple power and ground connections. \$\endgroup\$ – Ben Voigt May 20 '18 at 17:07
  • \$\begingroup\$ I just tried to conned VDD and VSS with the filtering capacitors, the BOOT pin and CAP pins, but that seem not enough. It seem I need "divide e impera" ;-). @BenVoigt: if you want to write your comments in an answer, I will accept it. Otherwise, I will put some answer myself as soon (supposing) I make it works. \$\endgroup\$ – Adrian Maire May 20 '18 at 21:44
1
\$\begingroup\$

First You need to connect all VDD pins on the MCU to 3.3V and all VSS pins to GND. The approach in general seems reasonable.

If You are only starting I strongly suggest getting a Discovery oraz Nucleo board.

\$\endgroup\$
  • \$\begingroup\$ @BenVoigt just an autocorrect typo. Corrected, thank you. \$\endgroup\$ – Jan Dorniak May 21 '18 at 9:21
0
\$\begingroup\$

Exactly as @BenVoigt suggested, the minimal circuit for the STM32F407ZE is a bit more complex:

Looking the datasheet of the chip, the following requirements apply:

  • All VSS and VSSA pins must be connected to GND.
  • All VDD, VDDA and VREF must be connected to 3.3V
  • Each VDD must have a close 1nF bypass capacitor to GND
  • A single 4.7uF bypass capacitor should connect any VDD to GND
  • VDDA and VREF must have a 100nF and a 1uF bypass in parallel close to the pin.
  • VCAP_1 and VCAP_2 must each be connected to GND through an 2.2uF capacitor (serie).

My understanding of the schematic:

(Notes: NJTRST = RSTS in the pin table above)

schematic

simulate this circuit – Schematic created using CircuitLab

Copy of the schematic from the specification (5.1.6 Power supply scheme):

enter image description here

Other issues:

I also discovered the bad way that the pin specification in the datasheet is rotated 90º with respect to the chip label.

Current state:

At the moment, I still miss several of the components for this diagram. The result is the communication is poor, and even if it seem to randomly communicate correctly, it also trigger several ACK errors every few seconds. This could also be related with the long wires used over the bread-board.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.