STM32H7x7 and STM32H7x5 devices contains two cores : CM7 + CM4
The second core creation is only done when
* DUAL_CORE variable is set to true
* non HLA interface is used
A second check for the second core existence is done in cpu1 examine-end
Once the second core is detected it gets examined.
Furthermore, the script provides a configurable CTI usage in order to halt
the cores simultaneously.
Tested on Rev X and V devices.
PS: the indentation was a mix of spaces and tabs, all changed to tabs.
Change-Id: Iad9c30826965ddb9be5dee628bc2e63f953bbcb8
Signed-off-by: Tarek BOCHKATI <tarek.bouchkati@gmail.com>
Reviewed-on: http://openocd.zylin.com/5130
Tested-by: jenkins
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
The STM32H7 has three access ports. The DBGMCU component is available
through AP0 at 0x5C001000 and through AP2 at 0xE00E1000. Using the
latter is preferable for early configuration because it works in all
power states and while SRST is asserted, whereas the former does not.
Change-Id: Iaf8f01d769efb6655040060a8e1e951e1f7e50ab
Signed-off-by: Christopher Head <chead@zaber.com>
Signed-off-by: Tarek BOCHKATI <tarek.bouchkati@gmail.com>
Reviewed-on: http://openocd.zylin.com/4742
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
The stm32h7x.cfg does not specify connect_assert_srst or
connect_deassert_srst in its reset_config. The comment claims that it
will therefore connect in reset. However, per the manual, the default
configuration is actually connect_deassert_srst, not
connect_assert_srst. In actual fact, connect_assert_srst does not work
on the STM32H7 because, while SRST is asserted, everything on the AXI
bus is inaccessible. The CPU core is accessible, but since the
examine-end event handler also pokes at the DBGMCU peripheral, that will
fail in connect_assert_srst mode. So using connect_deassert_srst is
appropriate, so fix the comment accordingly.
Change-Id: If3e32e871fb19cc61183bdf911b7c5efd80b62e2
Signed-off-by: Christopher Head <chead@zaber.com>
Reviewed-on: http://openocd.zylin.com/4741
Tested-by: jenkins
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
When using stlink for CM7 targets we have to rely on its firmware
to do the right thing as direct DAP access is not possible.
Change-Id: Ieee69f4eeea5c911f89f060f31ce86ed043bdfd0
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Reviewed-on: http://openocd.zylin.com/4732
Tested-by: jenkins
Reviewed-by: Matthias Welwarsky <matthias@welwarsky.de>
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
Change-Id: I7c5c9720ded329848647f17db95f845e46c01c19
Signed-off-by: Christopher Head <chead@zaber.com>
Reviewed-on: http://openocd.zylin.com/4674
Tested-by: jenkins
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
- add 'dap create' command to create dap instances
- move all dap subcmmand into the dap instance commands
- keep 'dap info' for convenience
- change all armv7 and armv8 targets to take a dap
instance instead of a jtag chain position
- restructure tap/dap/target relations, jtag tap no
longer references the dap, daps are now independently
created and initialized.
- clean up swd connect
- re-initialize DAP also on JTAG errors (e.g. after reset,
power cycle)
- update documentation
- update target files
Change-Id: I322cf3969b5407c25d1d3962f9d9b9bc1df067d9
Signed-off-by: Matthias Welwarsky <matthias.welwarsky@sysgo.com>
Reviewed-on: http://openocd.zylin.com/4468
Tested-by: jenkins
Reviewed-by: Matthias Welwarsky <matthias@welwarsky.de>
Antonio Borneo
Tarek BOCHKATI
Christopher Head
Paul Fertser
Matthias Welwarsky
Alexandre Torgue