Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem


Loading

memcpy in queue.c

Posted by John W. on June 5, 2006
Richard,

I was wondering what the issues can be of using a memcpy from the target's CLIB that may not be reentrant - or other string functions.

queue.c includes both stdlib and string.h files.

Thanks,
John W.

RE: memcpy in queue.c

Posted by Richard on June 5, 2006
These functions definitely need to be reentrant and although the scheduler code should guard against pseudo simultaneously calls it cannot guard against the application code making similar calls.

I would be amazed if this function was ever not reentrant, although many of the SDCC libraries are not (hence I provide a download of reentrant versions).

The design decision was taken to use the library function as it was considered more likely to be the source of errors if an equivalent function were defined in the portable layer (as different memory alignment requirements could cause problems).

Do you think you may have found an issue?

Regards.

RE: memcpy in queue.c

Posted by John W. on June 5, 2006
Richard,

I'm still investigating this. If I have found an issue - it is only in my MSP430 IAR port.

I've discussed this with IAR and they have told me the functions are reentrant - but I need to do further testing to determine if I've hit some kind
of corner case.

Thanks,
John W.

RE: memcpy in queue.c

Posted by Richard on June 5, 2006
I think you will find the memcpy source in:
IAR Systems\Embedded Workbench 4.0\430\src\lib\clib

looks reentrant.

Regards.

RE: memcpy in queue.c

Posted by John W. on June 5, 2006
Is memcpy the only function to worry about?

Thanks,
John

RE: memcpy in queue.c

Posted by Richard on June 6, 2006
I think strncpy() is used to copy the task name into the TCB - so only when a task is created. Other than that the library functions are used when configUSE_TRACE_FACILITY is defined and you are creating a table of the task status.

Regards.

RE: memcpy in queue.c

Posted by John W. on June 6, 2006
Richard,

I have noticed this - and this is in my app - not the core FreeRTOS code. If I do something like this - back to back:

memset
memcpy
strtoul

I get results in the debugger that seemingly aren't 'real'. If I run 'realtime' - all seems to be well - but if I set breakpoints and try to examine - I get conflicting results. An example -
I initialize a 'packet'. Part of the 'packet' get's memcpy(ied) like above - but when I stop the debugger and look at the packet contents - it shows the initialized values - even though this is impossible. Kindof strange - I noticed it's hard to debug if you have too many back-to-back lib functions stacked up for some reason...

Thanks,
John

RE: memcpy in queue.c

Posted by Richard on June 6, 2006
I can't see why calling library functions would be any different to calling your own defined functions, but here are some random thoughts:

+ Some library functions can use a lot of stack. memset and memcpy should use hardly any, but strtoul has potential to use a bit.

+strtoul seems to be reentrant having had a quick scan of the code.

+ Some compilers will inline some smaller library functions as a matter of coarse. Could this be messing up your debug attempts?

Regards.

RE: memcpy in queue.c

Posted by John W. on June 6, 2006
Richard,

I don't think I'm having a problem with inlining - but I'll check that. I suppose that could explain the issue with trying to debug with back to back lib calls.

Thanks,
John W.


[ Back to the top ]    [ About FreeRTOS ]    [ Privacy ]    [ Sitemap ]    [ ]


Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

NXP tweet showing LPC5500 (ARMv8-M Cortex-M33) running FreeRTOS.

Version 10.1.1 of the FreeRTOS kernel is available for immediate download. MIT licensed.

View a recording of the "OTA Update Security and Reliability" webinar, presented by TI and AWS.


Careers

FreeRTOS and other embedded software careers at AWS.



FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Espressif ESP32

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Renesas

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS

Xilinx Microblaze and Zynq partner