Intermittent failure: H3A stuck/hung

We are having the same problem on the DM365.  It is exactly as described above.  It seems to be related to the timing of when the AEWPCR is written.  Simple debug statements around the code that sets that register change the frequency of this problem. 

Any help would be greatly appreciated.

Thanks Jeremy, good to know we're not alone.

I probed a bit more and found that we often disable the H3A using the enable bit in the PCR while the busy bit is still set. The VPFE front end doc seems to be a bit confused about whether the PCR is shadowed or not (the PCR is not in the list of registers called out as being shadowed, but elsewhere we're told it is shadowed). I changed our code to prevent the H3A being disabled if the busy bit is true and I haven't had a repeat of the fault since. However since it's an intermittent problem that's no guarantee it's fixed. Could you see if this applies / helps in your case?

Could anyone from TI confirm whether it's legal to write the enable bit of the PCR while the busy bit is asserted? What about writes to other bits of the PCR?

Alex

Have you solved this issue? I too have this problem and it's non-deterministic. Checking for busy bit does not help.

This is very frustrating. It always works well after a reboot on the first try, but after you restart the application one or more times, it stops working (stats are the same, they do not change), then it starts working again randomly, then stops again...

Resetting VPSS before on every app startup does not help.

Hi Jan,

We haven't had a repeat of the problem since the busy bit checking so I think it's fixed. I'm sorry that doesn't sound like it's going to be much help to you.

Alex

Just curious, how do you check for the bit? in busy loop?

I changed our enable function to return a busy error if the busy bit was set when you try to enable or disable the h3a. 

CSL_Status CSL_h3aAewbEnable(CSL_H3aHandle hndl, Bool32 enable)
{
  if (hndl == NULL)
    return CSL_EFAIL;

  if (CSL_FEXT(hndl->regs->PCR, H3A_PCR_BUSYAEAWB) == 1)
  {
    return CSL_EBUSY;
  }
  CSL_FINS(hndl->regs->PCR, H3A_PCR_AEW_EN, enable);

  return CSL_SOK;
}

Then I changed the calling code to this: 

 if(h3aMod==DRV_H3A_MOD_AEWB) {
    status = CSL_h3aAewbEnable(&gCSL_h3aHndl, enable);
    if (status < 0) {
      if (errno == -CSL_EBUSY) {
		// H3A busy bit asserted, we need to wait for it to clear
		while (status < 0 && errno == -CSL_EBUSY && retries > 0) {
			retries--;
			usleep(1000);
			status = CSL_h3aAewbEnable(&gCSL_h3aHndl, enable);
		}
	  }
	}
  }

Just to be really thorough I put busy bit checks on all our h3a register writing functions as well, but I believe it's the code above which fixed the problem.

Alex

Hi,

what is your H3A statistics data size like width and height ?

I suspect my problem could be the method I am reading and writing to memory . How do you access the raw memory? By opening /dev/mem ?