[SOLVED] Debugging Microsemi SmartFusion2 with Flashpro device and microsemi cus

[christophe]

Hi,

I’m trying to use VS2017 and VGDB5.4R11 to develop on Microsemi Smartfusion2 (based on a ARM Cortex M3).

The toolchain comes with a custom Openocd built to support their microsemi FlashPro 4 JTAG interface. I’m not able to use the standard openocd because the lack of the support of a specific target.

So, i created a custom GDB sub:

command: link to the specific openocd.exe

argument (copied from the ECLIPSE properties) : –command “set DEVICE M2S090” –file board/microsemi-cortex-m3.cfg -c “gdb_port 3333” -c init -c “reset init”

working directory : pointing to the root dirs where i can find “board” directory

 

TCP port for gdb 3333

check Program with “load” command

 

The first time i start the debug, all is working fine

Here is the log:

../../src/gcc-8-8.3.0/src/configure --with-pkgversion="Raspbian 8.3.0-6+rpi1" --enable-languages=c,c++ --with-gcc-major-version-only --enable-shared --enable-linker-build-id --without-included-gettext --enable-threads=posix --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm --disable-libquadmath --disable-libquadmath-support --enable-plugin --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-sjlj-exceptions --with-arch=armv6 --with-fpu=vfp --with-float=hard --disable-werror --enable-checking=release --target=arm-linux-gnueabihf --with-sysroot=/mnt/f/gnu/raspberry-buster/out/arm-linux-gnueabihf/sysroot --host=i686-w64-mingw32 --prefix /mnt/f/gnu/raspberry-buster/out/ --disable-nls C:\Microsemi\SoftConsole_v6.0\openocd\bin\openocd.exe --command "set DEVICE M2S090" --file board/microsemi-cortex-m3.cfg -c "gdb_port 3333" -c init -c "reset init"
GNU MCU Eclipse (Microsemi - a Microchip company - SoftConsole build) 64-bit Open On-Chip Debugger 0.10.0+dev-00352-gaa6c7e9b-dirty (2018-10-22-10:08)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
M2S090
Info : only one transport option; autoselect 'jtag'
adapter speed: 6000 kHz
cortex_m reset_config sysresetreq
trst_only separate trst_push_pull
do_board_reset_init
fpServer v17 waiting for incoming connections on the port 3334 with API v5
Info : 1 1563885367117 microsemi_flashpro_server.c:1739 microsemi_flashpro_initialize() FlashPro ports available: usb07461, E200NO0TX
Info : 2 1563885367117 microsemi_flashpro_server.c:1740 microsemi_flashpro_initialize() FlashPro port selected: usb07461
Info : clock speed 6000 kHz
Info : JTAG tap: M2S090.tap tap/device found: 0x2f8071cf (mfg: 0x0e7 (GateField), part: 0xf807, ver: 0x2)
Info : JTAG tap: M2S090.tap disabled
Info : JTAG tap: M2S090.cpu enabled
Info : Cortex-M3 IDCODE = 0x4ba00477
Info : M2S090.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : Listening on port 3333 for gdb connections
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x00000190 msp: 0x20010000
lr (/32): 0x00000000
xPSR (/32): 0x01000000
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : accepting 'gdb' connection on tcp/3333

 

But, if i stop and restart the debug, i get an error message box saying “Failed to connect to the debug stub. Please click “view gdb stub log” to see the detailed gdb stub output.

The “gdb stub log” is is the same as the first one.

If i click on retry, it will work.

So, except the first time, everytime i debug, i got this error message box and have to click on retry.

 

I tried to set a startup delay, but the error seems coming before the delay.

 

Can you help me?

 

• This topic was modified 4 years, 9 months ago by support. Reason: formatting
• This topic was modified 4 years, 8 months ago by support. Reason: updated title per user request

Attachments:

You must be logged in to view attached files.

[support]

Hi,

This could happen if an old instance of OpenOCD was still running in the background, preventing the new one from listening on port 3333. As an experiment, please try changing the port (by adding -c “gdb_port 1234” to OpenOCD command line) and update the gdb settings accordingly. If this solves the problem, please double-check that the old OpenOCD instance terminates successfully and that no other program is holding the TCP port open (you can use the netstat tool to do that).

You can also troubleshoot this by starting OpenOCD and trying to telnet to its TCP port. If the connection fails, try disabling the firewall as it sometimes incorrectly prevents programs from connecting to OpenOCD.

[christophe]

Hi,

I tried to change the port, and it didn’t solve the issue. So I’ve checked the netstat info at some point (i returned to port 3333 for these tries)

When I start the second time the debug session (when i receive the error message box), the netstat -a returns:

TCP 127.0.0.1:3333  xxxMyPcNamexxx LISTENING

TCP 127.0.0.1:3334  xxxMyPcNamexxx:57364 ESTABLISHED

TCP 127.0.0.1:4444  xxxMyPcNamexxx LISTENING

As soon as i click on the Retry button, i got

TCP 127.0.0.1:3333  xxxMyPcNamexxx LISTENING

TCP 127.0.0.1:3333  xxxMyPcNamexxx:57372 ESTABLISHED

TCP 127.0.0.1:3334  xxxMyPcNamexxx:57364 ESTABLISHED

TCP 127.0.0.1:4444  xxxMyPcNamexxx LISTENING

When I stop the debug session, all the listening ports are properly removed

 

 

 

 

[support]

Thanks for the update. It looks like the connection succeeds, so the error might be caused by something else.

Please try switching the GDB Session log to “All GDB Interaction” and check the GDB output for a specific error.

If you are not sure, please create a full gdb session log and attach it here so that we can review it.

[christophe]

Hi,

here are 2 files :

abort.txt is the gdb log when i click on the abort button

retry.txt is the log when i click on the retry button

Attachments:

You must be logged in to view attached files.

[support]

Thanks, the relevant part of the log is this:

[     105 ms] -target-select remote :3333
[    1122 ms] ^error,msg=":3333: No connection could be made because the target machine actively refused it."

It looks like gdb is indeed trying to connect to port 3333. Please try the following steps:

1. Reproduce the problem, but don’t press Retry yet.
2. Run “telnet localhost 3333” from another window (you may need to install Telnet client via Add/Remove Programs -> Windows Features).
3. If the telnet connection succeeds, close the telnet window and retry the gdb connection.
4. If the telnet connection fails, double-check that OpenOCD is listening on the port via netstat and that it doesn’t show any errors in the output window when you try to connect to it.

If you still cannot connect to OpenOCD, please try running it manually and check whether connecting via telnet works.

[christophe]

The telnet connection succeeded.

As explained in a previous message, we checked that the port is in listening mode when the error message box is dispayed (before pressing any button)

It seems that gdb attempts to connect to the port 3333 a little bit too early.

Is it possible to specify a delay between the execution of openocd and when gdb attempts to connect to it ?

 

 

[support]

Oops, sorry we missed that the connection worked after you pressed ‘retry’.

If you are using the “Custom GDB stub” mode, you can specify additional delay via VisualGDB Project Properties -> Debug Settings -> Startup Delay.

If not, please let us know what debug mode you are using and we will help you configure the delay.

[christophe]

Hello,

 

I ve already tried the delay option. Whatever the delay i put,  I always get the error message box directly. But when i click on retry,  I can see the delay.

I use a custom gdb stub

[support]

Strange. Please try setting the delay to something large (e.g. 1 minute) and then enable gdb logging via Advanced GDB Settings. Once VisualGDB begins waiting for the stub to start (i.e. delaying for 1 minute), please double-check in the gdb session log that the ‘target remote’ command hasn’t been issued yet.

If it is indeed being issued before the delay elapses, please let us know and we will investigate. If it is issued after the delay, please try the following:

• Start OpenOCD manually before the session and switch from “custom gdb stub” to “custom mode”. Check if this works as expected.
• Start OpenOCD via the “custom gdb stub” mode and set a long delay (e.g. 10 minutes). Once the delay counter appears, run gdb manually and try connecting to OpenOCD.

This should help narrow the problem down.

[christophe]

Great news, it works !

So, when i tried the delay option, I still was on an old 5.3 version. It seems that the delay didn’t work as it should.

On the 5.4 R11, I set a delay to somehting like 250ms and it works as expected.

 

So, for people who want to debug Microsemi SmartFusion 2 with VisualGDB :

1. Choose as debug method : Custom GDB Stub
2. point the cutsom OpenOCD.exe in the installation of SoftConsole (dev env by microsemi based on eclipse)
3. add the following command line arg : -c “gdb_port 3333” -f board/microsemi_cortex_m3 -c “set DEVICE M2S090”
4. In the working dir field, set the OpenOCD scripts directory (in the SoftConsole installation dir)

Set the Delay to a 250ms

This configuration allows to debug in internal SRAM (the script configure the VTOR register to the SRAM base address.

Do not forget to use the xxx-sram/ld linker script provided in the SoftConsole Source package.

 

 

 

[christophe]

Could you please update the post title to

[SOLVED] Debugging Microsemi SmartFusion2 with Flashpro device and microsemi custom version of OpenOCD

 

 

 

[support]

Thanks for sharing the solution! We have updated the post.

[Author]

Posts