STM32F746IGT OpenOCD Problems

[Gabriel]

Hallo,

I designed a motorcontroll board with the STM32F746IGT as core. Now I want to run some tests with the board (flash a single LED). Therefore I duplicated one of the demo programs in ChibiOS and generated a suitable board.cfg, which is different from the F7-Discovery board. Also changed the board.mk path in makefile. The Project is built without errors but when I try to connect OpenOCD on ST-Link V2-1 I get the following error:

Code: Select all

Open On-Chip Debugger 0.9.0-dev-00415-g2d4ae3f-dirty (2015-06-12-17:54)
Licensed under GNU GPL v2
For bug reports, read
   http://openocd.org/doc/doxygen/bugs.html
Warn : Interface already configured, ignoring
Error: already specified hl_layout stlink
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 1800 kHz
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
adapter_nsrst_delay: 100
Info : clock speed 1800 kHz
Error: open failed
in procedure 'init' 
in procedure 'ocd_bouncer'

Does anyone have a suggestion, what the problem may be? Are there some additional changes to do in one of the config files (chconf, halconf, mcuconf, )? Tried it also with STM32 ST-LINK Utility and nothing happend. No errors occur after Program and Verify. The STM32F746IGT starts properly, it is not in some sort of fault-mode. The chip can be programmed with another surface, an error in the circuit diagram can be ruled out. Only with ChibiOS and STM32 ST-LINK Utility it wont work, but I would like to work with ChibiOS.

I hope someone can help me. (Sorry for my bad english)

Best regards
Gabriel

[Giovanni]

Hi,

It is not very clear, does it work with ST-Link utility or not?

If it does not work then I would consider a problem with HW, probably signal related to SWD/JTAG. If you only wire the SWD signals also make sure to select the SWD mode in the ST tool and when using OpenOCD.

If ST tool does work then you should make sure that the SWD/JTAG related pins are programmed correctly in your board files or the debugger cannot establish a connection.

I would try a discovery board as reference and see if it works on your setup.

Giovanni

[Gabriel]

Hi Giovanni,

thanks for the fast reply. It does not work with ST-Link utility. Currently the STM32F7 board is programmed over the programer on the STM32F4-Discovery board. Therefore I removed the two ST-Link jumpers and connected SWCLK, GND, SWDIO and NRST pins to the F7 board. The circuitry for programming the chip on the F7 board corresponds to that of the Discovery board. There should not be a HW problem, but it might be.

I will check the whether the SWD/JTAG related pins are programmed correctly in my board files, or not and if I use the right SWD mode. Furthermore I will try a discovery board as reference. Thanks!

Gabriel

[Gabriel]

Hallo,

I tried to program another discovery board (F4) with my setup over SWD and it works, only with the motocontrol board (F7) it is not working like expected. Is it possible that the SWO pin (pin PB3) is essential for OpenOCD/ST-Link v2-1? I thought it is not necessary for the communication to connect it like in the electrical schematics of the F7 discovery board, so I did not connect it (free Pin).

I also tried another run with ST-Link utility. SWD mode is the default setting. Only frequency (1.8MHz) an mode (Hot Plug) is selectable. It changes nothing, the board does not work.

Any thoughts what else could be wrong? This is my .cfg for OpendOCD on ST-Link V2-1

Code: Select all

# This is an motocontrol board with a single STM32F746IGT chip.
# ### To be updated ### http://www.st.com/internet/evalboard/product/.jsp
#

# This is for using the onboard STLINK/V2-1
source [find interface/stlink-v2-1.cfg]

transport select hla_swd

# increase working area to 256KB
set WORKAREASIZE 0x40000

# chip name
set CHIPNAME STM32F746

source [find target/stm32f7x.cfg]

stm32f7x.cfg is the target file.

Code: Select all

# script for stm32f7x family

#
# stm32f7 devices support both JTAG and SWD transports.
#
source [find target/swj-dp.tcl]
source [find mem_helper.tcl]

if { [info exists CHIPNAME] } {
   set _CHIPNAME $CHIPNAME
} else {
   set _CHIPNAME stm32f7x
}

   set _ENDIAN little

# Work-area is a space in RAM used for flash programming
# By default use 128kB
if { [info exists WORKAREASIZE] } {
   set _WORKAREASIZE $WORKAREASIZE
} else {
   set _WORKAREASIZE 0x20000
}

#jtag scan chain
if { [info exists CPUTAPID] } {
   set _CPUTAPID $CPUTAPID
} else {
   if { [using_jtag] } {
      # See STM Document RM0385
      # Section 40.6.3 - corresponds to Cortex-M7 with FPU r0p0
      set _CPUTAPID 0x5ba00477
   } {
      set _CPUTAPID 0x5ba02477
   }
}

swj_newdap $_CHIPNAME cpu -irlen 1 -ircapture 0x1 -irmask 0xf -expected-id $_CPUTAPID

if { [info exists BSTAPID] } {
   set _BSTAPID1 $BSTAPID
} else {
  # See STM Document RM0385
  # Section 40.6.1
  # STM32F75xxG
  set _BSTAPID1 0x06449041
}

if {[using_jtag]} {
 swj_newdap $_CHIPNAME bs -irlen 2 -expected-id $_BSTAPID1
}

set _TARGETNAME $_CHIPNAME.cpu
target create $_TARGETNAME cortex_m -endian $_ENDIAN -chain-position $_TARGETNAME

$_TARGETNAME configure -work-area-phys 0x20000000 -work-area-size $_WORKAREASIZE -work-area-backup 0

set _FLASHNAME $_CHIPNAME.flash
flash bank $_FLASHNAME stm32f7x 0 0 0 0 $_TARGETNAME

# adapter speed should be <= F_CPU/6. F_CPU after reset is 16MHz, so use F_JTAG = 2MHz
adapter_khz 1800

# use hardware reset, connect under reset
reset_config srst_only srst_nogate

adapter_nsrst_delay 100
if {[using_jtag]} {
 jtag_ntrst_delay 100
}

if {![using_hla]} {
   # if srst is not fitted use SYSRESETREQ to
   # perform a soft reset
   cortex_m reset_config sysresetreq
}

proc stm32f7x_default_reset_start {} {
   # Reset clock is HSI (16 MHz)
   adapter_khz 1000
}

$_TARGETNAME configure -event examine-end {
   # Enable debug during low power modes (uses more power)
   # DBGMCU_CR |= DBG_STANDBY | DBG_STOP | DBG_SLEEP
   mmw 0xE0042004 0x00000007 0

   # Stop watchdog counters during halt
   # DBGMCU_APB1_FZ = DBG_IWDG_STOP | DBG_WWDG_STOP
   mww 0xE0042008 0x00001800
}

$_TARGETNAME configure -event trace-config {
   # Set TRACE_IOEN; TRACE_MODE is set to async; when using sync
   # change this value accordingly to configure trace pins
   # assignment
   mmw 0xE0042004 0x00000020 0
}

$_TARGETNAME configure -event reset-init {
   # Configure PLL to boost clock to HSI x 4 (64 MHz)
   mww 0x40023804 0x08012008   ;# RCC_PLLCFGR 16 Mhz /8 (M) * 128 (N) /4(P)
   mww 0x40023C00 0x00000102   ;# FLASH_ACR = PRFTBE | 2(Latency)
   mmw 0x40023800 0x01000000 0 ;# RCC_CR |= PLLON
   sleep 10                    ;# Wait for PLL to lock
   mmw 0x40023808 0x00001000 0 ;# RCC_CFGR |= RCC_CFGR_PPRE1_DIV2
   mmw 0x40023808 0x00000002 0 ;# RCC_CFGR |= RCC_CFGR_SW_PLL

   # Boost JTAG frequency
   adapter_khz 8000
}

Gabriel

[Giovanni]

You should be able the same CFG of the discovery board.

Anyway, you should try an F7 discovery board, if it works then there is something with your HW.

Also make sure that the OpenOCD you are using actually supports the F7, latest stable release does not support it yet.

Giovanni

[Gabriel]

Hi,

thanks for the reply. Ok I will try it with the F7 discovery board and check what version of OpenOCD I'm using.

Gabriel

[Gabriel]

I tried it with the F7 discovery board and it works. Only one difference occured between the F4 and F7 discovery board. With the F4 I use ST-Link v2-1 however with the F7 I have to use ST-Link v2. Thats a little bit confusing, because the programer on the F4 discovery board works with ST-Link v2.

Now I'm able to use OpenOCD on the motocontrol board. I Changed the hardware reset to a software reset in the target folder.

Code: Select all

# reset_config srst_only srst_nogate
reset_config none separate

The debugging makes problems. It starts automatically and does nothing.

Code: Select all

Loading section startup, size 0x200 lma 0x8000000
Loading section .text, size 0xc1d0 lma 0x8000200
Loading section .rodata, size 0x19fc lma 0x800c3d0
Loading section .data, size 0xdc lma 0x800ddcc
Start address 0x200201, load size 57000
Transfer rate: 36 KB/sec, 8142 bytes/write.
tbreak main
Temporary breakpoint 1 at 0x20c0f0: file main.c, line 140.
continue

Does anybody know what causes this problem?

[Giovanni]

Try halting the application, it is possible it is stuck somewhere before reaching the main.

Giovanni

[Gabriel]

Hi Giovanni,

thanks for the fast reply. I will try to halt the application and hope to find the error.

Gabriel

[Giovanni]

Check clock settings, clock initialization happens before reaching the main function.

Giovanni