- This topic has 7 replies, 2 voices, and was last updated 2 years, 6 months ago by
.
-
Posts
-
Wondering if anyone can help me get VisualGDB settings set correctly for the IMXRT1050-EVKB development board. I have been trying to download the GUI Guider example to the board. If I open the same project in the MCUExpresso IDE and download to the board all is well. I have studied the command line for VisualGDB and MCUExpresso IDE and I believe I have the settings the same.
If I check the *.o files from VisualGDB and MUCExpress IDE the file are different sizes. I have change the VisualGDB settings but cannot get the file size to match or the contents to be the same.
I continue to get from VisualGDB cannot write to flash error. I like the VisualGDB concept but I am at the point where I will probably ditch VisualGDB if I cannot solve this.
Does anyone have any tips to point me in the right direction.
Hi,
The i.MXRT devices might require additional initialization in order to get some parts of the memory working. MCUXpresso would do it automatically (since it has proprietary device definitions), while the OpenOCD tool you are currently using with VisualGDB may require scripting it manually. Another option would be that some build-time options are set incorrectly.
In general, you can try using Embedded Quick Debug on the ELF file produced by the MCUXpresso IDE. If it works fine with VisualGDB, the issue is due to the build settings. You can try dumping the memory layout of both images with objdump and comparing them to see what could be causing the difference.
If debugging the image produced by MCUXpresso IDE is not working, you may need to run some additional initialization on the OpenOCD level. You can try issuing the “monitor mdw” and “monitor mww” commands via the GDB Session window to read/write various memory addresses directly via OpenOCD, and use it to understand what memory regions are turned off, and enable them by writing the device configuration registers.
Another option would be to try Segger J-Link with the J-Link software. It provides better out-of-the-box support for many devices, compared to OpenOCD, and VisualGDB works with it just fine.
I understand requires additional initialization but finding this is my problem.
I was hoping for comments might help me more forward.
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 consulting 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.
Alternatively, please consider browsing our documentation and tutorials. Our documentation lists most VisualGDB settings, and the tutorials show how to use VisualGDB for in many real-world scenarios. Our technical support is limited to issues in VisualGDB itself, that can be reproduced from scratch per our problem reporting guidelines (i.e. do not depend on external projects that can potentially contain errors).
I understanding, I was hoping than someone from the forum might be able to help me, as I have tried several times to get some tip / direction from VisualGDB.
I know you have fixed consulting rate for these sessions (billed in 1/2-hour increments) However your rate is $300/hr, I think this is very high.
It is a shame that VisualGDB take this approach with the product. I think the product is good and can be a good tool for the developer.
However if I can’t get it to work then it is useless to me.
Very very disappointed.
As we suggested before, you can try using Segger J-Link. It comes with its own software that supports more devices out-of-the-box compared to OpenOCD and include sits own support for low-level issues like this one.
If you are specifically looking for someone to get OpenOCD working with a specific example on a specific chip, unfortunately it is not something we could do without charging our consulting rate. Feel free to ask around on freelancing sites – perhaps someone can offer to do it at a lower rate. This is not specific to VisualGDB and does not rely on any VisualGDB-specific knowledge.
Please also note that we have tried including more device-specific help with our product support earlier, but it didn’t really work. It took us considerable time to investigate each project and point out the cause. The users were thankful at the moment, but they would soon come back with other issues with other projects, expecting a faster turnaround, more insights into internals of various devices, and help fixing/explaining various code originating from external sources. So unless we would agree to keep up allocating continuously increasing amount of resources to it, there was always disappointment.
Solving this at our consulting rate works for companies that prefer focusing on their domain-specific issues and occasionally outsource infrequent platform-specific issues. It saves them time and allows us allocate the resources necessary to handle it. If you are constantly working with multiple hardware platforms and encounter a large amount of issues, we advise planning sufficient time to study the documentation of each platform and find the correct platform-specific settings for each setup.
I believe that the issues has nothing to do with OpenOCD, If build the same project with VisualGDB and MCUExpress IDE and copying each of the bin files directly to the RT1050-EVKB via Windows Explorer (RT1050-EVKB is show as a drive), the VisualGDB bin file does not work and the MCUExpresso IDE does work.
I have also tried the MCU-LINK PCB via the JTAG connector, again the VisualGDB fails (FLASH write error) and the MCUExpresso IDE works everytime.How can this be an issue with OpenOCD?
If the image produced by VisualGDB is not working, while the same project built with MCUXpresso works with the same uploading/debugging method, most likely the two projects are using different memory layout. VisualGDB imports the default settings from the MCUXpresso SDK, and the SDKs generated for the MCUXpresso IDE and generic GCC (used by VisualGDB) could be slightly different.
As suggested in our first reply, you can try using the objdump tool to dump the layouts of both projects into text files, and compare the addresses of the critical parts (vector table, stack pointer, initialization code, etc.). If they are different, please double-check the linker scripts used by both versions of the project and make sure they are consistent with each other.
Ultimately, both MCUXpresso and VisualGDB use the same GCC compiler, so if the executables produced by them are different, some arguments to the compiler do not match between the 2 setups. Running objdump could help track it down, and you can also try running the command lines from both sides manually as shown in this tutorial (it is about Keil, but the VisualGDB-side steps for the GCC compiler will be similar).
- You must be logged in to reply to this topic.