Linker cannot find __sys_readc, and shouldn't be looking for it

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Linker cannot find __sys_readc, and shouldn't be looking for it

2,922 Views
normanjones
Contributor II

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

0 Kudos
6 Replies

1,945 Views
lpcxpresso_supp
NXP Employee
NXP Employee

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

0 Kudos

1,945 Views
normanjones
Contributor II

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

>

0 Kudos

1,945 Views
converse
Senior Contributor V

Without seeing your source code, it is difficult to say. But, which C library calls do you call? Do you use exit() or abort()?

0 Kudos

1,945 Views
normanjones
Contributor II

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

>

0 Kudos

1,945 Views
converse
Senior Contributor V

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 

What are none, nohost and semihost libraries? 

0 Kudos

1,945 Views
normanjones
Contributor II

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

>

0 Kudos