AnsweredAssumed Answered

MPC574xG STM behavior

Question asked by Martin Froschhammer on Sep 15, 2017
Latest reply on Dec 11, 2017 by David Haworth


we noticed a strange behavior when using the STM Unit of an MPC574xG (1N81M) that we cannot explain. If we write a compare value a short time before the STM counter reaches the value, it seems that no interrupt is generated.


We have the following sequence. The intention is to set the next trigger point either in the future or immediately if counter already passed the point in time:


 /* Set the compare value and trigger a the STM interrupt if compare value is already in the past.
   * Hint:
   * The timer range is split into three parts in order to differenciate between future, now and past.
   * now    = current tick value of counter
   * past   = half timer cycle behind now (range: now-0x80000000 ... now-1)
   * future = half timer cycle after now (range: now+1 ... now+0x7FFFFFFF)
  void SetCompareValue(uint32 CompareValue)
    uint32 now;
    /* Write compare value to hardware */
    *(volatile uint32*)(0xFC068018) = CompareValue;  /* Write STM_CMP */
    /* Get the current counter value */
    now = *(volatile uint32*)(0xFC068004);                   /* Read STM_CNT */
    /* Trigger the timer interrupt if the compare value is already in the past or now. */
    if(((CompareValue - now) <= 0x80000000) || (CompareValue == now))


In the case the compare value is set a short time before the counter reaches the value it seems that no interrupt is generated. But the condition below that checks that the compare valued was set to a value in the past also does not match. So also no manual interrupt triggering is done.


When reading back the STM_CMP register before getting the current counter value STM_CNT removes the effect, but we are not sure if we eliminate the root cause by doing that or if it simply change the runtime behavior that way that it not occurs in this situation.


Replacing the read back by a mbar synchronization instruction is not successful.


So my questions is, can this behavior be explained somehow? And if yes, is the read back of the compare value a general solution?

I also noticed an issue (e10200) in the errata of the Chipmask 0N78S where there might be a connection. So is the 1N81M affected as well?


Best Regards