Community news, upcoming events and general discussions
Threads: 31 Posts: 81
Get technical support from the community
Threads: 1048 Posts: 5780
Threads: 15 Posts: 54
Tell us how to make XDK better!
Threads: 35 Posts: 117
Share and discuss community member projects
Threads: 49 Posts: 237
this is my first post in this community and I hope you can help me.
I´m working on a little configuration programm for my diploma thesis but when i try to falsh the project on the XDK it won´t work. Instead the known "Flashing selected project aborted due to compilation problem" window appears. Everytime it occurred befor there was an mistake in the code but this time no such mistake is reported.
Only the error codes as seen in the attached screenshots are reported.
What´s my mistake at this point?
Thank you for your held in advance.
Hello Maximilian, First I'd like to welcome you to the XDK community. In build log (i.e. the first image) the line
c:/xdk_workebnch/armgcc ... /libc.a(lib_a-openr.o): In function '_open_r': openr.c(.text.open_r0x10): undefined reference to '_open'
is printed, right before the application's build process aborts. This points to a problem with the MCU's C libraries used in the XDK-Workbench. The issue is, since the libraries are precompiled into archive files, I can not see where this error comes from. Do you have any function calls that come from some standard library? By standard library I mean everything that is not taken from the project itself, but instead libraries such as stdio. It would be worth a try to comment out any such calls and try to compile the project again. I might be completely in the wrong here, but on the other hand, this is the only clue that I got from your description and images so far. If my advice does not help, it would be quite helpful if you could send me your project. If that is an option for you, please post your e-mail address here, and I will contact you directly. Please tell me if this was helpful and do not hesitate to ask further questions. Kind regards, Franjo
first of all thank you for your answer.
As you have assumed I have function calls from standard libraries in my project such as "fopen" , "strcpy" or "strcmp". I comment them out as you said and i could flash the project on the XDK.
Can you tell me whats the problem with function calls from standard libraries? Aren´t they allowed in the projects for XDK?
My problem is, that i learnd programming and particular "C" in the last months with books by my self for my diploma thesis and I´m not that good at it. Because of this it is difficult for me to understand the professional function calls which are deposited in the XDK libraries completly. For this reason I use them not that much and try to work with standard funtion calls.
Can you tell me if this is possible or not?
Hello Maximilian, seeing that my assumption was correct, I can tell you exactly why the problem occurs. The issue lies with fopen(). It's not that standard libraries are not allowed, but instead it's just fopen() not working, because the XDK does not have a filesystem to begin with. Trying to open a file when there are none is plain impossible, but unfortunately, this is not documented well in the library. In general, using standard libraries is recommended, but beware of the fact that some of the file I/O related ones are not possible to use. I assume that you are trying to store data on the XDK. To do that, you should use an SD card. The SD card should be formatted to a FAT32 file system. You can then use the FAT file system module available on the XDK, to access the SD card and write and read data. This process is of course a little bit more complicated than with standard libraries, You can find an example on how to access, write and read files on the SD card in the XDK-Workbench's Welcome-Screen. Use the SDCardExample for that. Alternatively, you can take a look at the Data Logger demo, which is available here. The Data Logger also uses an SD card and writes sensor data to it. Please tell me if this was helpful, and do not hesitate to ask further questions. Kind regards, Franjo