I'm using the 32-bit slave fifo sync interface and using the slfifosync example code.
When I do an IN transfer, the following OUT transfer has an extra word of zeros prepended to it. Any ideas? Is this expected?
I don't see the OUT direction GPIF flags asserted after the IN transfer. Even so, when I try an OUT transaction, I get this extra word. Any subsequent OUT transfer does not have the extra word. If I perform another IN transfer, then the very next OUT transfer again has the extra word.
On the OUT direction I'm using the partial flag to indicate when I can do a high speed burst. This works fine, except that at power up this flag is incorrectly asserted. After any transfer, the flag is correct. To overcome this, I only do a high speed burst if both partial flag and the ready flag indicate that data is available. I have both flags set to "initial value = low", "asserted polarity = low". BTW, the ready flag does not have this behavior, only the partial flag. Also the IN direction flags work as expected. Anyway, is this incorrect initial polarity expected?
1) I suppose you are referring to AN65974 example firmware. If not, please use this. What is your test setup? Do you use the same as we have shown in the application note? Have you changed anything in the state machine or the firmware?
>> Can you make sure that the timings of the control signal at the GPIF interface is alright? First we need to check what the GPIF is sampling. If the timings are not proper at the start, there can be one clock extra (low/high) depening on the interface. I suggest you to try this using a manual DMA channel. In the DMA callback, you can print the initial couple of data bytes and see if you get extra zeros here as well. I think you will get extra zeros here, if so, you need to consider the timings at the GPIF interface here.
2) Can you probe the flags signals at different instances to show what you observe?
3) "except that at power up this flag is incorrectly asserted" please show the oscilloscope signals before and after you request for a transfer by the host.
Thank you for your response- I've to work on something else so have not looked at this until recently.
I found the issue with the extra word of zeros: I was not providing the address soon enough. I know this is clearly shown in the AN65974 read timing diagram, but it's still surprising to me that address needs to be provided earlier than the read strobe (instead of along with it).
I've been editing the GPIF-II state machine, so it's not exactly as it is in AN65974 (I eliminated the chip select signal).