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

Sysprogs forums Forums VisualGDB [SOLVED] Debugging Microsemi SmartFusion2 with Flashpro device and microsemi cus

This topic contains 12 replies, has 2 voices, and was last updated by  support 1 month, 3 weeks ago.

Viewing 13 posts - 1 through 13 (of 13 total)
  • Author
    Posts
  • #25426

    christophe
    Participant

    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:

     

    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 2 months ago by  support. Reason: formatting
    • This topic was modified 1 month, 3 weeks ago by  support. Reason: updated title per user request
    Attachments:
    You must be logged in to view attached files.
    #25431

    support
    Keymaster

    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.

    #25440

    christophe
    Participant

    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

     

     

     

     

    #25442

    support
    Keymaster

    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.

    #25457

    christophe
    Participant

    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.
    #25460

    support
    Keymaster

    Thanks, the relevant part of the log is this:

    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.

    #25467

    christophe
    Participant

    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 ?

     

     

    #25489

    support
    Keymaster

    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.

    #25490

    christophe
    Participant

    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

    #25495

    support
    Keymaster

    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.

    #25535

    christophe
    Participant

    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.

     

     

     

    #25536

    christophe
    Participant

    Could you please update the post title to

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

     

     

     

    #25548

    support
    Keymaster

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

Viewing 13 posts - 1 through 13 (of 13 total)

You must be logged in to reply to this topic.