Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Real time embedded FreeRTOS mailing list 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT Training




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 ]    [ Sitemap ]    [ ]




Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.

Latest News:

FreeRTOS V9.0.0 is now available for download.


Free TCP/IP and file system demos for the RTOS


Sponsored Links

⇓ Now With No Code Size Limit! ⇓
⇑ Free Download Without Registering ⇑


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Renesas Electronics Gold Alliance RTOS Partner.jpg

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Atmel RTOS partner supporting ARM Cortex-M3 and AVR32 microcontrollers

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

Xilinx Microblaze and Zynq partner

Silicon Labs low power RTOS partner

Altera RTOS partner for Nios II and Cortex-A9 SoC

Freescale Alliance RTOS Member supporting ARM and ColdFire microcontrollers

Infineon ARM Cortex-M microcontrollers

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

Cypress RTOS partner supporting ARM Cortex-M3

Fujitsu RTOS partner supporting ARM Cortex-M3 and FM3

Microsemi (previously Actel) RTOS partner supporting ARM Cortex-M3

Atollic Partner

IAR Partner

Keil ARM Partner

Embedded Artists