Received a SIGINT: Interrupt when start debugging

Sysprogs forums Forums VisualGDB Received a SIGINT: Interrupt when start debugging

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

Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
    Posts
  • #27200

    jokn
    Participant

    I just installed VisualGDB and then create my first blinky project for a STM32H750IB device. When using my ST-Link V2 Adapter the download seems not to come to an end. When using Keil ULINK2 as a CMSIS-DAP  flashing of the device get finish but after the SIGINT:Interrupt message appears. I have set a breakpoint at main and started the debugger with F10.

    Attached the GDB log file

     

    Attachments:
    You must be logged in to view attached files.
    #27202

    support
    Keymaster

    Hi,

    The CMSIS-DAP interface is generally very unreliable and slow, so we would recommend simply using ST-Link or J-Link instead.

    You might be able to solve the U-Link issue by analyzing verbose OpenOCD log and patching the OpenOCD scripts, however it may not be practical given that ST-Link and J-Link will very likely just work out-of-the-box.

    #27203

    jokn
    Participant

    Thanks for quick response.

    Of course my first attempt was using  the ST-link. Downloading seens to be OK, but the debugger dos not stop at main or at my breakpoint. When pressing [break al] there is no source available. The dissasemby windows shows be that the processor was running in the nirvana. Mayby sometink is worong with my project. Its a simple blinky template from your project wizzard.

     

    #27210

    support
    Keymaster

    Thanks for pointing it out. We have quickly rechecked the default project generated for the STM32H750IB  device and it appeared to be fine (we don’t have this specific hardware to test it). Hence, the problem you are experiencing might be caused by one of the following issues:

    1. The layout of the project built by VisualGDB doesn’t match the target (e.g. you selected a slightly different device when building the project or there is a bug in our device definitions).
    2. Something is interfering with the debugging (e.g. unstable power).

    The easiest way to narrow this down would be to try using VisualGDB to debug an application for the same board built with the ST’s IDE:

    1. Try building a similar project in the other IDE and locate the .elf file.
    2. Copy the elf file over the one built with VisualGDB (<Project directory>\VisualGDB\Debug\<Project Name>).
    3. Select Tools->Options->Projects and Solutions->Build and Run->On Run->Prompt to Build.
    4. Start debugging. When Visual Studio asks whether to rebuild the project, click “No”.

    Please let us know if a project built outside VisualGDB runs as expected under the VisualGDB’s debugger and we will advise you on the further steps to diagnose this.

    As a quick alternative, you can also try configuring VisualGDB to stop at the reset handler (VisualGDB Project Properties -> Embedded Debug Tweaking) and press F10 instead of F5 to start debugging. This will step into the very first instruction that gets executed after reset, letting you debug the initialization code.

    #27215

    jokn
    Participant

    Your hint to stop after reset handler was  great.  The point is that the flash was not programmed!! And at the moment do not know how get the flash programmed. In Debug settings Programm FLASH memeory is set to always but nevetheless the FLASH is not erased neither programmed.

    BTW when running in RAM it works fine.

    Attachments:
    You must be logged in to view attached files.
    #27217

    support
    Keymaster

    Hi,

    Perhaps the FLASH memory is locked via the fuse bits? Please try completely erasing it via the ST-Link tool.

    #27218

    jokn
    Participant

    hmm – I don’t think so becaus I have MDK-KEIL running in the other side and it works great (also with the ST-Link) I just tried the funktion [Programmand run without debbuging]  with the following log:

    • This reply was modified 1 month ago by  support. Reason: formatting
    #27220

    support
    Keymaster

    Hi,

    Keil might have protected the memory with the fuse bits in a way that cannot be overridden by OpenOCD.

    Either way, feel free to troubleshoot it on your own if you have a better understanding what is going on. If not, please try erasing the memory using the ST-Link tool and then use the “Verify FLASH memory” button in the GDB Session window to see what exactly got programmed into the FLASH memory. This should help narrow down the issue and help us suggest next steps.

    #27221

    jokn
    Participant

    I pointed it out !!

    In The Debug settings, there is a [Debugged device] select. Per default  [Dual Flash bank] was selected. I switched to [Single FLASH bank] and like magic it works.

     

     

     

    Attachments:
    You must be logged in to view attached files.
    #27223

    support
    Keymaster

    Thanks for pointing this out. We have updated the OpenOCD script selection rules to automatically pick the single-bank script for single-bank devices.

    You can get the new rule file by reinstalling the OpenOCD package via Tools->VisualGDB->Manage VisualGDB Packages.

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

You must be logged in to reply to this topic.