Experimental Physics and
Industrial Control System

Tonia Batten <[email protected]> · Fri, 9 May 2014 13:13:34 -0600

Good Morning,

Thank you for all of your responses/suggestions.  I want to provide feedback on a fix currently in place for this problem.  

I was incorrect about the variation in the values being a result of a conversion, the value was being altered when it being assigned to pmsg->dvalue.  When we added a statement to print values right after the assignment Mark discovered that a value of zero was being printed before the queueRequest.  

Mark then suggested that the problem may be associated with memory allocation and recommended that following changes in devMotorAsyn.  This has resolved the problem.

devAsynMotor::build_trans
    /*pmsg = pasynManager->memMalloc(sizeof *pmsg);*/
pmsg = (motorAsynMessage *)malloc(sizeof *pmsg);

devAsynMotor::asynCallback
    /*pasynManager->memFree(pmsg, sizeof(*pmsg));*/
free(pmsg);

Note: I was not able to compile a new version that Mark provided with the__sync_synchronize call before the queue request because the cross compiler we are using for the Moxa DA-662 equipment is old. (__sync_synchronize was added in gcc 4.4.0).  The tool chain we are using is using gcc 3.4.3.  Unfortunately I have not been able to find a newer tool chain for this equipment.

All testing was done with the following:
Epics.R3.14.12.4
asyn 4-22
motor 6-8
seq 2-1-13

The intent is to collect additional information so that the memory allocation issue on the armv5teb architecture can be addressed.

Thank you again for everyone's input!!  It is greatly appreciated!!

Regards, Tonia

-----Original Message-----
From: Torsten Bögershausen [mailto:[email protected]] 
Sent: May-08-14 12:14 AM
To: Johnson, Andrew N.; Rivers, Mark L.
Cc: [email protected]; Tonia Batten
Subject: Re: Newport XPS-Q8 and Motor Record - armv5teb architecture

On 5/7/14 11:32 PM, Johnson, Andrew N. wrote:
> Hi Mark,
>
> You could try adding a call to the gcc built-in routine __sync_synchronize(); after the last write to the asynUser structure. This implements a full memory barrier, which is equivalent to the two memory barriers inside the mutex operations. If this fixes it for ARM there is probably a better solution, but this will at least identify if this is the cause of the problem.

This would be needed on a multi-core system.

What system is in use ?
single core or multi core?

I just got the motor simulator working on the Raspberry PI, (after some days of debugging) The trick was to use this block in motorApp/MotorSrc/motor.h:

==============
/* Define, from top to bottom, how bit fields are packed. */
/* This works for gnu, SunPro, MS Visual C. */ #include <epicsEndian.h> #if (EPICS_BYTE_ORDER == EPICS_ENDIAN_LITTLE)
     #define LSB_First (TRUE)
     #warning LSB_First
#endif

#if (EPICS_BYTE_ORDER == EPICS_ENDIAN_BIG)
     #define MSB_First (TRUE)
     #warning MSB_First
#endif

===============

What do you get when you compile with this change ? MSB_First or LSB_First ?

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System