- This topic has 12 replies, 2 voices, and was last updated 4 years, 5 months ago by
.
-
Posts
-
I am trying to setup a new project using the Nucleo-H745ZI. I have my own custom board built but I am trying to test using a Nucleo-H745ZI first.
I have followed the tutorial at https://visualgdb.com/tutorials/arm/stm32/multicore/
I have two projects M7 and M4 both all defaults except M7 toggles LED GPIOB Pin_0 (Nucleo LED 1) and M4 toggles GPIOE Pin_1 (Nucleo LED 2). The projects are just the default template toggle LED project as outlined in the tutorial.
I start the m7 core and debug. The LED 1 blinks as expected.
The tutorial says to put a break point and start the other project So I do this hit a breakpoint, and try to start the M4 core I get the error message of “Error: open failed (no matching adapter found)”
with the following GDB stub log:
C:\Users\D\AppData\Local\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.openocd\bin\openocd.exe -c “gdb_port 59335” -c “telnet_port 59334” -f interface/stlink.cfg -f target/stm32h7x_dual_core.cfg -c init -c “reset init” -c “echo VisualGDB_OpenOCD_Ready”
Open On-Chip Debugger 0.10.0 (2020-03-10) [https://github.com/sysprogs/openocd]
Licensed under GNU GPL v2
libusb1 09e75e98b4d9ea7909e8837b7a3f00dda4589dc3
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport “hla_swd”. To override use ‘transport select <transport>’.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : clock speed 4000 kHz
Error: libusb_open() failed with LIBUSB_ERROR_NOT_SUPPORTED
Error: libusb_open() failed with LIBUSB_ERROR_ACCESS
Error: open failed (no matching adapter found)To me it looks like libusb is not allowing another connection or I must be missing a setting somewhere but so far I cannot find it.
Also if I stop the M7 core and start the M4 core the debugger start but program never leaves the reset handler.
I have gone through the tutorial 3 times now being careful to check every selection but some of the screens have changed since the tutorial was published. For example there is no longer an option to put project and solution in the same directory though I believe this is the default behavior now. I also tried putting both projects into the same directory without success.
I am not super concerned about debugging simultaneously but would really like to start the second core and so far I cannot see how to do this. On my custom board I will be using a Segger JLink debugger.
I have tried the examples from STM32H7 Cube for dual core and it seems to work fine.
Thanks,
DP
Hi,
This might be caused by the way STM32H7 devices initialize the secondary core. We have a separate tutorial explaining it.
Please also make sure you are using VisualGDB 5.5 Preview 7 and not v5.4.
If it doesn’t help, please let us know and we will look further into this.
I installed version 5.5 preview 7 and now debugging starts as you would expect but still the M4 core will not start.
Following the steps in your tutorial The M7 core starts fine but M4 does not start and stays huge in the reset handler.
I suspect I am missing some essential code needed to start the M4 code.
Thanks,
I also tried importing the keil project included in the Cube H7 package.
While it works in keil. After importing I can start M7 core but M4 core never leaves reset while debugging with VisualGDB.
Thanks,
D
No problem, we can help you get this to work. Please try modifying the code to control one of the LEDs from the M4 core. Then check if the core gets started when you are not debugging it (i.e. program the FLASH both memory banks and power cycle the device).
If the second core never starts outside the debugger as well, please try comparing the startup code on the first core with some example that manages to start the second core successfully. Most likely, the example is missing some code for actually starting the M4 core.
The second core never starts with or without debugger.
As mentioned I imported example that works in keil, After setting up the projects the M7 core will start but the M4 core will never start in visualGDB.
Note when importing the project and selecting the MCU there is no separate option for STM32H745zi_M4 like there is when you start a new project but I was able to hand configure the parameters for the core but something is still wrong.
Lastly I went a did a very simple example for core and could make it work in other products but could not make it work with visual GDB.
Thanks,
Sorry about that. We have double-checked the STM32H745ZI support with the latest OpenOCD and it did work as expected. Please make sure you install the latest VisualGDB 5.5 Preview 7 and update the OpenOCD package and the STM32 BSP via Tools->VisualGDB->Manage VisualGDB Packages.
Please also try erasing the entire FLASH memory of the device via the STM32 ST-Link Utility.
If it still doesn’t help, please share the screenshots of the GUI that is missing the M4 option you mentioned, and we will help you understand what is going on.
Would it be possible for you to post the projects files from the tutorial at? https://visualgdb.com/tutorials/arm/stm32/multicore/
With these I could test it and see if I can find the problem.
Maybe your projects that worked for you will work for me. Otherwise I have tried everything I can think of to bring up the second core.
Thanks,
DPNo problem, you can find them here: https://github.com/sysprogs/tutorials/tree/master/visualgdb/ARM/stm32/STM32MultiCoreDemo
Thanks for your help on this. I am now certain this problem is related to the Nucleo-STM32H745. I tested it today on my custom boards using that has a STM32H745ZI with a segger J-link and works just as your tutorial says. So I think all is good with the software but might be a problem with the Dual Core Nucleo board.
Thanks for confirming this. There might be indeed minor differences between STM32H745 and STM32H747 that could be affecting this. E.g. the M4 core might start suspended and may need to be explicitly started by the M7 core.
If you would like to narrow it down, please consider cloning some of the multi-core STM32CubeMX samples for the Nucleo board, rather than using the default LEDBlink example. These samples come directly from ST and should account for differences between the boards.
I don’t know what the problem is with the nucleo but I tried two of them with the same result. But using the same processor STM32H745ZI in my board worked fine.
I suspect it might be related the power source of the processor Nucleo STM32H745 are configured for PWR_DIRECT_SMPS_SUPPLY
But I do not need any more help at the moment I am up and building on my board and that is all that matters but wanted to let you know if you run into again.
- You must be logged in to reply to this topic.