Debugging with RAM Code

Sysprogs forums Forums VisualGDB Debugging with RAM Code

This topic contains 4 replies, has 2 voices, and was last updated by  JFerraris 2 months, 1 week ago.

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
    Posts
  • #32859

    JFerraris
    Participant

    Hello!

    Project details: NXP IMXRT1064, Jlink, VisualGDB, pins all muxed

    I have a project in which I need to access the internal flexspi2 flash, and so I need to run code from RAM.

    The debugger gets very finicky and unstable when trying to access the code that is in RAM. I have checked whether the code exists or not where it is pointing and it does. Most of the time I cannot even debug it at all.

    In my linker script, the flexspi and clock driver files are excluded from my .text section and included in my SRAM_ITC region.

    Thank you so much. If you need more information I’ll gladly give it

    #32860

    support
    Keymaster

    ​Please note that VisualGDB is a productivity tool for software developers. It can make developers more productive by providing convenient GUI for common time-consuming tasks, and integrating various external tools into Visual Studio, so that they are always a few mouse clicks away.

    We are able to offer VisualGDB at affordable price, because we focus on developing and supporting functionality that works the same way for multiple users, hence the development and testing effort is reused between multiple license holders.

    We also receive a huge amount of inquiries asking to fix a specific broken project, help make the correct design choice, explain how a specific C++ feature works, or assist porting a library to a different platform. These inquiries require considerable effort to research and communicate the best solution. They do not scale between multiple users. I.e. helping one user solve this type of problem will not automatically help other users. It also does not help the same user avoid the same type of problem in the future. Hence, we are not able to address them within our regular support. If we included this type of help in our support, we would simply not have sufficient resources to provide it at the current license prices, or to allocate any resources to VisualGDB development.

    We are happy to offer project-specific help via our consulting service per Zoom, TeamViewer or any other screen sharing service of your choice. We charge a fixed rate for these sessions (billed in 1/2-hour increments), and are happy to solve any problems our users encounter. The rate includes a detailed follow-up email at the end of the session, that includes an overview of the used techniques and a summary of solved problems and future recommendations.

    #32872

    JFerraris
    Participant

    Hello,

    This question is a question about debugging RAM with VisualGDB, it isn’t a project question or anything like that. I was only giving those details to help understand the problem.

    Thank you.

    #32873

    support
    Keymaster

    Hi,

    As far as VisualGDB is concerned, debugging code in RAM is not different from debugging FLASH. VisualGDB simply instructs the underlying debug tool to set breakpoints in the code and interprets the results reported by the tool.

    #32875

    JFerraris
    Participant

    Hi

    I appreciate the response! Hmm, that was what I did think since you guys just have GDB as the underlying tool.

    For some reason it doesn’t allow me to step into a function that is allocated to RAM though, and if the whole program is, I just get the 0xdeadbeef stack frame and Source Not Available page.

    I will look more at gdb to see if I can deduce the problem too though.

    Thank you

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

You must be logged in to reply to this topic.