MM912J637 - Current and voltage measurement synch and interrupts

[igw]

Hi all,

The MM912J637 datasheet states that the current and voltage measurements can be synchronized. The data sheet says this is done by simultaneously enabling the measurements in the ACQ_CTL register (a single write).

I have some simple code that does the following:

  ACQ_CTL = 0xFF00; // All measurements off

  ACQ_SRH = 0xFF;

  ACQ_CTL = 0xFF17; // Enable C, V and internal T measurements and the CVMI interrupt

There are several issues I am seeing:

1) I am getting CVMI interrupts (D2D interrupt with INT_VECT=0x0C) with the lower three bits of ACQ_SRH indicating i) just a current measurement available, ii) just a voltage measurement available and iii) (rarely) both I and V measurement available. So much of the time I see two interrupts where I would expect to see just one.

Why is this?

I did wonder if it was due to subtle race conditions such that skew between the two measurements is enough for an interrupt to be generated and handled by the first ready measurement followed very soon after by the other channel which becomes ready very soon after.  However, this does not seem to be the case.  If I blip a GPIO pin during interrupt handling the timing between the current-ready interrupt and the voltage-ready interrupt varies wildly between one micro-controller reset and another.  This is surprising.  It suggest no synch at all between C and V measurements.

What is the full process for ensuring synch between C and V measurements?  Do they need to be disabled for some period of time first?

2) Even if I enable just the current measurement (and the CVMI interrupt) I see a second interrupt very close to the first.  It appears as though every current measurement generates two interrupts. The second interrupt occurs from about 2us to 10us after the first finishes.  Note that this second (very close by) interrupt is *not* the same issue I am talking about in point 1) - there are two seemingly different issues.

CPU is running at 64 MHz and bus clock at 32MHz.

Has anyone got any thoughts about what may be happening?

Thanks,

Ian

[iggi]

Please find bellow some hints regarding the question 1)

The synchronization issue is coming from the following:

The thing is that Analog Die register accesses are done with D2D frequency (up to 32 MHz), but the data is just copied in the register and the different settings becomes active only after the next rising edge of the acquisition clock (512 kHz). Accordingly when 2 accesses to the same register are done within a short period, you never know what happens, because when the rising edge comes, the setting which is currently in the register becomes active.

The safest way to avoid the problem is to wait for minimum 2us (1 cycle of the acquisition clock) between subsequent accesses to the same register.

For instance, this function restarts the measurement in case it is not in sync and does a resynchronization (asm code is handling a wait of ~3.5us):

static void ADC_Sync(void) {

    //volatile unsigned char loop = 0;

  /*Disable the voltage and current measurement*/

B_ACQ_CTL = 0x1000;        //disable interrupt

    B_ACQ_CTL = 0x0200;        //ACQ_CTL_CLEAR_VMEN;

  B_ACQ_CTL = 0x0100;           //ACQ_CTL_CLEAR_CMEN;

    /*Removing ongoing requests*/

  B_ACQ_SR = 0x0300;     //ACQ_SR.Word = ACQ_SR_CLEAR_VM | ACQ_SR_CLEAR_CM;

  //while(loop<10)loop++;

  __asm {

  LD D0,#0

loop:      

  INC.b D0

  CMP D0,#100

  BLE loop

  }

   /*Enable the voltage and current measurement*/

  B_ACQ_CTL = 0x1313;    //ACQ_CTL_SET_VMEN | ACQ_CTL_SET_CMEN;

}

[igw]

Hi Govorcin,

Thanks for the information.  Did I miss this in the datasheet?  I can't see it stated anywhere?

I would have thought that accessing the blocking D2D window would deal with all this.  I assumed that accessing the blocking window would ensure that transactions are completed while the processor is held. This seems to be what section 4.25.4.2 of the very fresh rev 4.0 of the datasheet is saying.  Is this not the case?

The sample application that comes with the '637 eval system does not seem to insert manual delays like this.

Also, in your example you refer to B_ACQ_CTL three times in  quick succession. Why don't you need a delay between these accesses?

Thanks for your further explanation,

Ian

[igw]

Sorry my point 2 was a bug in my code.  There are no interrupts following immediately after the current measurement interrupt.  Point 1, dealing with synch between C and V measurement sill exists and seems to be real though.

sorry for any confusion,

Ian