I am using LPCxpresso for a target of LPC824M201JDH20. It is our board, not a development board. I can get another project to run and emit characters out the USART0 and 2.
But with the main project code the Linker reports:
....../../arm-none-eabi/lib/armv6-m\libcr_c.a(__fillbuf.o): In function `_Csys_read_':
__fillbuf.c:(.text._Csys_read_+0xe): undefined reference to `__sys_readc'
I have no printf or scanf calls, no #include "stdio.h", no stream I/O, and I am not using any debug out except for direct USART0 with ring buffers (no fancy USART to USB). I don't see why the linker should be trying to find this. In addition to __sys_readc it is complaining that these are also undefined references:
__sys_read
__filbuf
__sys_flen
__sys_seek
__sys_write
_Csys_alloc
__sys_write
__sys_appexit
Where do I start looking for the file or setting that is causing LPCxpresso to think that these functions should be used?
Attached is the list of steps when creating this new project.
Original Attachment has been moved to: IDE_NewProj.txt.zip
Use : Quickstart -> Quick Settings -> Set library/header type
For more details see : Switching the selected C library
You might actually want to visit the main FAQ page and do a search for something like "Redlib"
https://community.nxp.com/community/mcuxpresso/lpcxpresso-ide/lpcxpresso-ide-faqs
Note : Most of this information is the the User Guide if you switch to the more recent MCUXpresso IDE
http://www.nxp.com/mcuxpresso/ide
Regards,
LPCXpresso Support
Thanks, that did it. With RedLib:nohost it compiles, links, and the memory
requirements drop to 51% Flash and 20% RAM. But, most importantly, the
'824 reads serial Flash, queries readings, formats a message, sends to the
transmitter module, gets a response back, and notes it all out a serial
debug port. All of the individual elements of the project. Now we can
complete putting it all together and get this demo done.
Thanks all for the support getting through this, and for the information
provided as to what is going on 'under the hood'.
--Norm
LPCX support
replied to the discussion
"Re: Linker cannot find __sys_readc, and shouldn't be looking for it"
To view the discussion, visit:
https://community.nxp.com/message/933009?commentID=933009&et=watches.email.thread#comment-933009
>
No exit() and no abort(). It is just a normal embedded systems approach.
the processor boots and transfers to main(), gets into our code which is
setup adn then a big look. It should never fall our of the bottom of the
loop. If it were to, then it would leave main() and presumably stop in
some branch to itself. So nothing to force leaving main(). In a similar
way, nothing to call on file or stream functions. Thus my surprise when
the linker complained about __sys_readc.
I am not convinced that it is caused by the code. However I cannot rule it
out entirely. But it does seem to be more of a project settings or Eclipse
settings issue.
About the only library calls used are the NXP calls for initialization and
I/O interaction (I/O pins, 3 USARTs, SPI), #include "string.h", strcpy(),
strcat(), strncat(), strlen(), and sscanf().
I've replaced all printf() calls with itoa() and strcat(). Made a lot of
variables volatile (per 457616), and eliminated all floats (for code
size). And certainly no open() or lseek() calls because I'm not opening
files.
There are no #includes for "stdio.h", "math.h", or "board.h". We have our
own board so the pin mapping tool was used, the generated files added into
the system, and blocks initialized as they were in the example projects.
And the initialize/use code works for the USART and SPI in another test
program.
The program is mostly interactions with, and parsing of serial port
command/response, interaction with an SPI Flash, and logic. Very little
math, all of which was converted to integers to save code space.
--Norm
Con Verse
replied to the discussion
"Re: Linker cannot find __sys_readc, and shouldn't be looking for it"
To view the discussion, visit:
https://community.nxp.com/message/932764?commentID=932764&et=watches.email.thread#comment-932764
>
It is sscanf that is causing the problem - I guess for convenience of implementation it uses the same underlying functions as scanf. You probably need to link with the "nohost" library variant
OK, that makes sense; sscanf brings in support from a library for files.
And this is a reasonable default for an eval board with a debugger/USB
interface. That block is not on our board, so we need a different C
library without file support. And it is consistent with removing sscanf()
calls last night and getting through the compile/link without errors.
Thanks for the link that describes the differences between the three
library variants.
Now I am wondering where in Eclipse to set the library to be used, and
what the path (or name) is used for the NoHost library variant.
I see entries for REDLIB under Edit project settings, so I am assuming
that I should be using a NoHost version of REDLIB.
Under C/C++ Build:Settings:MCU Linker:Libraries (or :Shared Libraries) I
can see where a different library might be entered, but I do not see the
default library. How do I indicate that it should change from a Host
library to instead use a NoHost library?
Con Verse
replied to the discussion
"Re: Linker cannot find __sys_readc, and shouldn't be looking for it"
To view the discussion, visit:
https://community.nxp.com/message/932966?commentID=932966&et=watches.email.thread#comment-932966
>