Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019 
<== Date ==> <== Thread ==>

Subject: Re: 2 MAXv problems
From: Dirk Zimoch <dirk.zimoch@psi.ch>
To: Ron Sluiter <sluiter@aps.anl.gov>
Cc: EPICS <tech-talk@aps.anl.gov>
Date: Thu, 11 Mar 2010 17:56:10 +0100
Ron,

To my experience sprintf and sscanf (and also strlen, strcpy and many others) are "ISR save". (Well, they are inherently vulnerable to buffer overflows but that's not limited to interrupts). The basic rule is: don't block. That means in particular don't deal with I/O and don't allocate/free memory. And you just must not use "%f" in the format because you are not allowed to use floating point. Also don't use "long long int" because some compilers use a 64 floating point instruction to copy "long long int" variables.

Dirk

Ron Sluiter wrote:
Hi all,

Since there is continuing discuss on this topic (on and off
tech-talk), I'm posting the complete message Eric sent me
at the start of this thread.

It sites (chapter and verse) the limits on VxWorks (5.5)
facilities from an ISR context. (Is there a comparable
version of RTEMS restrictions?)

It if ain't approved, I'm not going to risk using it.

Ron

Eric Norum wrote:
Re: "I have also conditionally added your fix for sprintf() not callable from the RTEMS interrupt context ..."

I wasn't aware that sprintf() was legal to call from an interrupt context on vxWorks. Or did I misunderstand the change?


I found the following in the vxWorks 5.5 manual. First about sprintf():



/4.5.1 Special Cases: printf( ), sprintf( ), and sscanf( )/


    The routines *printf( )*, *sprintf( )*, and *sscanf( )* are
    generally considered to be part of the standard /stdio/ package.
    However, the VxWorks implementation of these routines, while
    functionally the same, does not use the /stdio/ package. Instead,
    it uses a self-contained, formatted, non-buffered interface to the
    I/O system in the library *fioLib*. Note that these routines
    provide the functionality specified by
    ANSI;* *however, *printf( )* is not buffered.

    Because these routines are implemented in this way, the
    full /stdio/ package, which is optional, can be omitted from a
    VxWorks configuration without sacrificing their availability.
    Applications requiring /printf/-style output that is buffered can
    still accomplish this by calling *fprintf( )* explicitly to /stdout/.




And then about ISRs:



/2.6.4 Special Limitations of ISRs/


    Many VxWorks facilities are available to ISRs, but there are some
    important limitations. These limitations stem from the fact that
    an ISR does not run in a regular task context and has no task
    control block, so all ISRs share a single stack.


Table 2-21: *Routines that Can Be Called by Interrupt Service Routines*

    ------------------------------------------------------------------------
    *Library*
    	
    *Routines*
    ------------------------------------------------------------------------
    *bLib*
    	
    All routines
    *errnoLib*
    	
    *errnoGet( )*, *errnoSet( )*
    *fppArchLib*
    	
    *fppSave( )*, *fppRestore( )*
    *intLib*
    	
    *intContext( )*, *intCount( )*, *intVecSet( )*, *intVecGet( )*
    *intArchLib*
    	
    *intLock( )*, *intUnlock( )*
    *logLib*
    	
    *logMsg( )*
    *lstLib*
    	
    All routines except *lstFree( )*
    *mathALib*
    	
    All routines, if *fppSave( )*/*fppRestore( )* are used
    *msgQLib*
    	
    *msgQSend( )*
    *pipeDrv*
    	
    *write( )*
    *rngLib*
    	
    All routines except *rngCreate( )* and *rngDelete( )*
    *selectLib*
    	
    *selWakeup( )*, *selWakeupAll( )*
    *semLib*
    	
    *semGive( )* except mutual-exclusion semaphores, *semFlush( )*
    *sigLib*
    	
    *kill( )*
    *taskLib*
    	
    *taskSuspend( )*, *taskResume( )*, *taskPrioritySet( )*, *taskPriorityGet( )*, *taskIdVerify( )*, *taskIdDefault( )*, *taskIsReady( )*, *taskIsSuspended( )*, *taskTcb( )*
    *tickLib*
    	
    *tickAnnounce( )*, *tickSet( )*, *tickGet( )*
    *tyLib*
    	
    *tyIRd( )*, *tyITx( )*
    *vxLib*
    	
    *vxTas( )*, *vxMemProbe( )*
    *wdLib*
    	
    *wdStart( )*, *wdCancel( )*
    ------------------------------------------------------------------------



    For this reason, the basic restriction on ISRs is that they must
    not invoke routines that might cause the caller to block. For
    example, they must not try to take a semaphore, because if the
    semaphore is unavailable, the kernel tries to switch the caller to
    the pended state. However, ISRs can give semaphores, releasing any
    tasks waiting on them.

    Because the memory facilities *malloc( )* and *free( ) *take a
    semaphore, they cannot be called by ISRs, and neither can routines
    that make calls to *malloc( )* and *free( )*. For example, ISRs
    cannot call any creation or deletion routines.

    ISRs also must not perform I/O through VxWorks drivers. Although
    there are no inherent restrictions in the I/O system, most device
    drivers require a task context because they might block the caller
    to wait for the device. An important exception is the VxWorks pipe
    driver, which is designed to permit writes by ISRs.

    VxWorks supplies a logging facility, in which a logging task
    prints text messages to the system console. This mechanism was
    specifically designed for ISR use, and is the most common way to
    print messages from ISRs. For more information, see the reference
    entry for *logLib*.

    An ISR also must not call routines that use a floating-point
    coprocessor. In VxWorks, the interrupt driver code created
    by *intConnect( )* does not save and restore floating-point
    registers; thus, ISRs must not include floating-point
    instructions. If an ISR requires floating-point instructions, it
    must explicitly save and restore the registers of the
    floating-point coprocessor using routines in*fppArchLib*.

    All VxWorks utility libraries, such as the linked-list and
    ring-buffer libraries, can be used by ISRs. As discussed earlier
    (/2.2.6 Task Error Status: errno/
    <http://slac.stanford.edu/exp/glast/flight/sw/vxdocs/vxworks/guide/c-basic.html#98918>),
    the global variable *errno* is saved and restored as a part of the
    interrupt enter and exit code generated by
    the *intConnect( )* facility. Thus, *errno* can be referenced and
    modified by ISRs as in any other code. Table 2-21
    <http://slac.stanford.edu/exp/glast/flight/sw/vxdocs/vxworks/guide/c-basic.html#91424> lists
    routines that can be called from ISRs.



No mention of either sprintf() or fioLib there.....


On Mar 8, 2010, at 1:18 PM, Ron Sluiter wrote:


Hello Jens,

The common code for the old device support record
initialization; "motor_init_record_com()" was not always
passing positive encoder ratio values.  This has been a
bug for a long, long time that is now fixed.

I have also conditionally added your fix for sprintf()
not callable from the RTEMS interrupt context to the
MAXv ISR.

Both of these changes will be available, soon, in the
next release.

Thanks for pointing out these problems,
Ron


Jens.Eden@ptb.de <mailto:Jens.Eden@ptb.de> wrote:
Hello Ron,

but the motor record has not issued negative
encoder ratio commands for a long time.
here is an extract of the boot messages with drvMAXvdebug=10, while autosave writes -5.55123456e-06 to the ERES-field.

--
send_mess: sent card 0 message:'
AX  ER-180140,52359 UU-3.440496
--
This command (ER-180140,52359) does not work for
current firmware versions.

Are you using a really old
version of the motor record?
No, this is the motorR6-4-4
EpicsRelease 3.14.11

Jens
_______________________________
Jens Eden
Physikalisch-Technische Bundesanstalt
Albert-Einstein-Straße 15
12489 Berlin

Tel +49 30 6392-5086
Fax +49 30 6392-5082




Von: Ron Sluiter <sluiter@aps.anl.gov <mailto:sluiter@aps.anl.gov>> An: Jens.Eden@ptb.de <mailto:Jens.Eden@ptb.de> Kopie: tech-talk@aps.anl.gov <mailto:tech-talk@aps.anl.gov> Datum: 05.03.2010 21:12 Betreff: Re: 2 MAXv problems



Hello Jens

There has been a recent (R6-4 and above) fix to prevent intermittent MAXv command
errors from occurring when User Units are turned off, but the motor record has not
issued negative encoder ratio commands for a long time. Are you using a really old
version of the motor record?


Ron


Jens.Eden@ptb.de <mailto:Jens.Eden@ptb.de> wrote:
Hi all,

I found, that in recent firmware versions (1.31) of the MAXv cards the command to set
negative encoder resolutions (e.g. "AX ER-2,3") as used by the MAXv
driver
does not work any more.
Instead a command error is returned and the encoder resolution will
remain
unchanged.
I couldn't find this "new feature" documented anywhere.






-- Eric Norum eric@norum.ca <mailto:eric@norum.ca>







Replies:
Re: 2 MAXv problems Eric Norum
References:
2 MAXv problems Jens . Eden
Re: 2 MAXv problems Ron Sluiter
Re: 2 MAXv problems Jens . Eden
Re: 2 MAXv problems Ron Sluiter
Re: 2 MAXv problems Ron Sluiter

Navigate by Date:
Prev: Re: Building EPICS for multiple Linux distributions Dirk Zimoch
Next: Building StreamDevice 2-4 / SynApps / Win32 John Dobbins
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019 
Navigate by Thread:
Prev: Re: 2 MAXv problems Ron Sluiter
Next: Re: 2 MAXv problems Eric Norum
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·