fetch bit in C6711 HPI

Mariana,

Mariana said:

1) Is the fetch bit supported in any version of the 6711?

I would trust the user guide on this.  I think what may have happened is that because of the errata you mentioned, the FETCH bit was hidden in the final release of the device.  I will try to confirm.

Mariana said:

2) What would the effect of using this bit be?

More than likely what is described in the C6711 errata for silicon revision 1.3.

Mariana said:

3) There are 28 used (reserved) bits in the HPI control registers, does writing to any of those bits have an effect on the operation of the chip.

Bit 20 is probably the hidden FETCH bits, so yes.  Customer should write 0s to reserved bits.

Mariana said:

4)  The HRDY bit is read to see if the interface is busy and if not, transfers can occur. Since it takes time to read and check the bit and then start the transfer,  we are wondering if the interface can then become not ready again in that time interval. Is there time spec'ed for how long you can wait between reading the HRDY bit and using the interface?

HPI starts transfers at the request of the Host.  If the Host is busy checking the HRDY bit, then the HPI cannot start transfers.  So Host should be okay to proceed once HRDY shows "ready".

Confirmed that the HPI user guide is correct, FETCH and HRDY are hidden from the Host (and therefore not supported) on C671x devices.

I am the customer that reported the issue.  We have a Power PC AMCC405GP that is connected to a 6711 using the HPI.  We have been building this board for several years and have over 1000 in the field.  We have recently had 5-10 boards that after several days of running encounter a machine check exception.  The machine check exception is caused by an external bus controller error when accessing the DSP.  We are using the HRDY line from the DSP to control PPC access and beleive that a timeout on this signal is causing the machine check. 

We have th etimeout on this signal set very long (>1 uS) and if we set it very short, we get a similar exception. The DSP is in run mode, executing code.  I don't know whether the signal is leaving th eDSP and not getting to the PPC or not being generated by the DSP.

My question is "What can cause the HRDY to not be generated within a reasonable time?"  Is it possible that code running in the DSP can prevent or delay the HRDY or must if be a hardware problem.  If it has to be hardware, can external hardware cause it?  The only real hardware we have hanging off the DSP is SRAM.

Thanks in advance.

Bill

In the 6711 the HPI ultimately gets serviced by the EDMA.  Other EDMA traffic in the system can affect the speed at which HRDY becomes ready.  If you use EDMA to do accesses to your SRAM and the SRAM interface is slow then that access time might slow down the time in which the HRDY signal becomes ready.

One other thing to watch out for is errant software making an access to the address range 0x4000_0000 - 0x4FFF_FFFF.  That is a "reserved" address range but actually gets used as part of the EDMA request for the HPI (and PCI).  Any accesses to this address space (reads or writes) will cause the HPI/PCI to permanently hang.

In your failing system I think it's important for you to determine whether HRDY is slow/delayed or in a totally hanged state.  If it's the latter you can setup a data watchpoint to catch the offending software.

Thanks,  I'll look into the accesses to 0x4x and EDMA.

I think the HRDY line is just delayed.  We ran it overnight and the board crashed.  I also triggered a scope on a long HRDY pulse. From normal operation where it's low for about 150-400 ns it was low for 40 us.  I don't know if the crash and the long HRDY are from the same event but circumstantial evidence says they are.

I've got to revise my previous answer.   First, my polarities are backwards because I am going through an inverter before seeing it on my scope.  The HRDY line is going high for 150-450 ns normally. 

When it fails, the HRDY bit goes high, probably indefinitely, and after 40.9 us my CPU gives up, crashes, and then the HCS line goes inactive, gating off the HRDY line at that time. So to answer your question, the HRDY is probably stuck, not delayed.

I do have two devices hanging off the EMIF interface but I do not have bus arbitration or ERDY signals employed.  This means to me that the external devices might be screwiing up the data but cannot hang up the interface. 

I have no emulator interface to the DSP in this system so I can't put a watchpoint as you suggest.  I can set up a test to see if the DSP code is running normally.

One of the main causes of these issues is utilizing a variable that has not been initialized.  One thing that you should be careful about is definitions like this:

int my_global;

One behavior of our compiler is that it does not initialize the above declaration to zero.  It just leaves it completely uninitialized.  That can cause major issues if you access that variable and expect a value!

You might try a couple things:

1. Turn on the compiler option "issue non-serious warnings".  Rebuild all of your code and look carefully at all the warnings.  In particular I would watch out for any warnings/remarks related to accessing a variable before it has been assigned a value.
2. This one's more difficult.  How are you bootloading the device?  Are you able to zero out all of your memory prior to loading code?