- This topic has 8 replies, 2 voices, and was last updated 2 years, 9 months ago by
.
-
Posts
-
I’ve searched for an answer on this for a while but I’m still not having success. I ran into this first trying to call malloc, and I didn’t really need malloc that bad so I moved on. But now I’m running into it calling snprintf().
cmake project for ATSAM, using ninja, arm toolchain gcc 10.3.1, gdb 10.2.90. I’m using the default library, not newlib-nano (at least it says default).
I’ve also seen some support comments saying to manually specify –specs=nosys.specs with LDFLAGS but as this is a sysprogs toolchain shouldn’t that already be in place?
Is that this line from the toolchain.cmake: set(_ldflags ${_ldflags} “${BSP_CONFIGURATION_com.sysprogs.toolchainoptions.arm.libctype}” “${BSP_CONFIGURATION_com.sysprogs.toolchainoptions.arm.syscallspecs}”)
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:- The steps should begin with launching Visual Studio. They should include every step necessary to create the project from scratch and reproduce the issue.
- 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.
- 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.
Launch visual studio, click “continue without code”.
File -> New -> VisualGDB Project
Embedded Project Wizard. Click Add
Embedded application, Advanced CMKake, C99
NEXT
Select ARM in C:\SysGCC\arm-eabi
ATSAME51J18A
Execute from FLASH, library default, Implementations for _sbrk(), etc “minimal (no semihosting)”
NEXT
Empty project
NEXT
OpenOCD, CMIS-DAP SWD programmer, target/atsame5x.cfg, SWD, Program FLASH memory always, reset before programming.
FINISH
Add new C file to project named main.c with main() function.
Project builds successfully.
Include <string.h>, add snprintf() function, error undefined reference to “end”. “could not open project\build\VisualGDB\Debug\sbrk.c, that file path might have been parsed incorrectly”.
I’m still in my evaluation period and this is my first project with visualgdb. I don’t think I selected anything that would cause this error but please do let me know.
Thanks for the detailed repro steps. It looks like you are targeting a device from an Atmel START SDK that you have previously imported into VisualGDB. This issue could be a bug of this specific SDK, or a glitch in our importing logic.
Please try deleting the imported SDK (its location is shown at the bottom of the Device Selection page in the wizard) and importing it again. If the problem persists, please upload original SDK archive in a file sharing service and post a link here, so that we could recheck if our importing logic is handling it correctly.
I know you said to upload the original, but I’m not sure what all was in it. I just generated a new atmel start sdk from start.atmel.com and created a new visualgdb project with the same steps I did above and I got the same results.
I noticed the warning “manually-specified variables were not used by the project: LOCALAPPDATA”. I suspect that could be relevant since that is the location of the Atmel start file?
Shared files location: C:\Users\jason\AppData\Local\VisualGDB\EmbeddedBSPs\arm-eabi\com.sysprogs.atstart.ATSAME51J18A
Here is the .atzip from the start configurator: https://www.dropbox.com/s/iwasymqxcnljno8/My%20Project4.atzip?dl=0
I know there were some settings in the advanced section about path mapping, none of which I changed. But in the error output it shows a path using both a forward and back slash; I assumed this was ok. Screenshot attached.
Thanks, we have reproduced the issue. It is triggered by selecting “Empty project” on the Sample Selection page of the wizard. This option assumes that you are familiar with the underlying SDK and can add all the necessary files manually.
Please try selecting “Default project” instead – it will import a sample project from the SDK itself, that should include all the necessary files.
That said, with this specified SDK, you will need to manually reference the AtmelStart framework via VisualGDB Project Properties -> Embedded Frameworks. We will address this in the next VisualGDB version; until then, please reference the framework manually after creating a project.
Ok I see.
Even with a default project it doesn’t pull in the ASF files; I still had to follow your step of including them from the project properties.
I went back and forth on using AFS because I find it cumbersome to navigate and often full of bugs, especially relating to setting the clocks. I thought that by importing the atmel start sdk the various makefile settings would be included such that I could create my project with whatever was needed for the project. I didn’t understand sbrk or that it wasn’t a hardware mapping but was a “utility”.
It seems sufficient to pull in utils_syscalls.c from the asf files.
I have it working now, thanks!
Good to know it works. In general, the “empty project” option simply strips all sources from original project template. It cannot automatically determine which of these sources would be needed in each specific scenario, so it may indeed involve some trial-and-error to figure that out. Having a working project based on the full template as a comparison could be a good reference point.
- You must be logged in to reply to this topic.