Build Error after Uodate

[meldano]

Hi,

I updated Visual GDB and BSD from an old 2020 Visual GDB to actual Version.

I got following build error

 

C:\Users\xxx\AppData\Local\Temp\ccMH3DTk.s: Assembler messages:
C:\Users\melne\AppData\Local\Temp\ccMH3DTk.s:253: Error: garbage following instruction — `tst lr,#4 n ite eq n mrseq r0,msp n mrsne r0,psp n ldr r1,[r0,#24] n ldr r2,handler2_address_const n bx r2 n handler2_address_const:.word prvGetRegistersFromStack n’
Failed to compile main.c. arm-none-eabi-gcc.exe exited with code 1

 

The File does not exist and when I click the message, I got a error message box

I clean/rebuidl with no solution.

Can anybody help me?

Thanks

Daniel

[meldano]

The message box

Attachments:

You must be logged in to view attached files.

[support]

Unfortunately, it is hard to suggest anything specific based on the description you provided.
In order for us to provide any help with this, we need to be able to reproduce the problem on our side.
Please provide complete and detailed steps to reproduce the issue as described below:

1. The steps should begin with launching Visual Studio. They should include every step necessary to create the project from scratch and reproduce the issue.
2. Please make sure the steps do not involve any 3rd-party code as we will not be able to review it. If the problem only happens with a specific project, please make sure you can reproduce it on a clean project created from scratch.
3. The steps should include uncropped screenshots of all wizard pages, VisualGDB Project Properties pages and any other GUI involved in reproducing the problem. This is critical for us to be able to reproduce the problem on our side.

You can read more about the best way to report VisualGDB issues in our problem reporting guidelines, If you do not wish to document the repro steps and save the screenshots, please consider recording a screen video instead and sending us a link to it.

Please note that many VisualGDB issues are caused by selecting an incompatible combination of settings at some point. We are generally not able to review specific projects and find the specific settings that were set incorrectly. We recommend checking the projects into source control and keeping a track of all changed settings to avoid breaking the projects.

Another common cause of errors is updating to a new toolchain/BSP/SDK. Many of these components are maintained by device vendors or communities, and require minor adjustments to the project when switching to newer versions. If you have recently updated any of such components, please consider reverting back to the old version as described here. There is no need to downgrade VisualGDB itself, as it is updated separately from such components.

You can also try checking various diagnostic output from various parts of VisualGDB as described on this page. Although we won’t be able to review it for a specific project unless the we can reproduce the problem from scratch, checking it might provide some clues on what is causing the unexpected behavior.

[meldano]

It seems the problem is not the new BSP. I use git and reverted all changes, install the old bsp.

Compiling a new project is possible without failure.

[support]

If the problem only happens with a specific project, but not with a similar project created from scratch, it is likely caused by invalid/incompatible values in some of the original project’s settings.

The best way to find out the setting causing the problem is to compare the projects side-by-side (e.g. using KDiff3 or any other diffing tool) and try merging them step-by-step. E.g. if the diffing tool shows differences in .vcxproj, and .vgdbsettings files, you can try replacing just the .vgdbsettings file vs. just the .vcxproj file, to see which of them is causing the issue.

Once you narrow down a specific file, you can use the diffing tool to review the differences within a specific file, and merge them one half at a time, quickly pinpointing a specific setting.

We advise making multiple backups of both projects throughout the troubleshooting, as it is very easy to inadvertently break the project further by changing a slightly different setting.

If a specific setting is not working as expected (i.e. changing it on a freshly created project causes unexpected behavior), feel free to let us know and we will investigate it further.

We can also gladly do the troubleshooting for you at our consulting rate – it typically takes between 30 minutes and 1 hour to find the root cause of most similar problems. However, as this troubleshooting needs to be done for each project separately and cannot be automated, we have to charge our consulting rate to do that. Feel free to contact our sales for more information.

[Author]

Posts