Sysprogs forums › Forums › VisualGDB › Debugging with RAM Code
Tagged: imxrt 1064, NXP, ram code
- This topic has 4 replies, 2 voices, and was last updated 2 years, 3 months ago by JFerraris.
-
AuthorPosts
-
July 22, 2022 at 11:59 #32859JFerrarisParticipant
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 mySRAM_ITC
region.Thank you so much. If you need more information I’ll gladly give it
July 22, 2022 at 12:04 #32860supportKeymaster​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.
July 25, 2022 at 07:13 #32872JFerrarisParticipantHello,
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.
July 25, 2022 at 08:26 #32873supportKeymasterHi,
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.
July 25, 2022 at 08:40 #32875JFerrarisParticipantHi
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 andSource Not Available
page.I will look more at gdb to see if I can deduce the problem too though.
Thank you
-
AuthorPosts
- You must be logged in to reply to this topic.