Hello,
I’ve been trying to get the write FIFO to work on the McAsp on a OMAP-L137 (from the C6747 core). I have set the WFIFOCTL register (with the WENA bit set last as described in the user guide). Also this is set before the transmitter is taken out of reset.
I then write five times to the XBUF[0] register expecting to have five transmissions. But I only get two. It is as if the writes are not being FIFO’d. Am I writing to the correct register? Or is there some set up I am missing?
Cheers,
John.
How have you configured XFMT[XBUSEL]? If you left that value at its default (0) then it will be expecting writes through the DMA port. See Table 6-45 "McASP Registers Accessed Through DMA Port" in the datasheet for the correct addresses.
i didn't see any mention of the FIFO handling interrupts. I think it may have only been designed to work with EDMA events and not interrupts. I'll double check with the Houston apps team.
---------------------------------------------------------------------------------------------------------
Please click the Verify Answer button on this post if it answers your question.---------------------------------------------------------------------------------------------------------
Hi Brad,
Thanks for your response.
Yes, I have set the XBUSEL bit. In fact, I can make my five transmissions work correctly if I wait on the XSTAT[XDATA] bit between writes to XBUF[0]. If I remove the waits I get only two transmissions out of the port, obviously (!) because subsequent writes to the XBUF[0] register are occurring before the previous transmission has completed and are being ignored.
Using the wait is not efficient use of CPU time and I was hoping I could get the FIFO to queue up my five transmissions without having to resort to using DMA.
However, with the FIFO supposedly enabled, I get the same behaviour, i.e. only two writes out instead of five – making me believe that either the FIFO is not enabled or XUF[0] is not the correct register to write to.
The Houston apps team confirmed that the FIFO was not designed for usage with the CPU. Looking at Figure 1 of the McASP User Guide shows it well. You can see that the DMA events are routed to the Audio FIFO and then out, whereas the CPU interrupts do not go to the FIFO. That means that CPU interrupts are coming directly from the McASP (i.e. there is no knowledge of a FIFO). This makes it impractical to use the FIFO in a CPU-based setup.
So I think your choices are:
Brad
Thanks again for your response.
However, I think you need to tell the Houston apps team to have another think as I have managed to get the FIFO working from CPU writes. The problem was, as I suspected, that I was writing to the wrong register. I think that XBUF[0] is the actual transmission register for serialiser 0 and the input to the FIFO is a different register called XBUF or XRBUF (depending on which bit of the user guide you are reading).
I think that there is a small problem in the document (SPRUFM1) which hinders the understanding of how the FIFOs (and the DMA) write to the McAsp. On page 68 we find table 8 which has a distinct lack of hex addresses in the column labelled ‘Hex Addresses’:
Luckily the OMAP-L137 data sheet (SPRS563c) comes to our rescue here with table 6-47 on page 114:
I’m using McAsp1 so I do my writes to 0x01D06000, not XBUF[0] (which is at 0x01D04200). Also I have to actually reset the XFMT(XBUSEL) bit and it all works as required.
Incidentally, I think I would have hit the same problem if I had tried to use DMA as this would need to write to the same register. I suggest that the table in SPRUFM1 needs updating to include the addresses.
Thanks again for your help.
John,
There's no issue with the DSP core being capable of writing to the FIFO. Writing XFMT[XBUSEL]=0 is the correct configuration for using the address at 0x01D06000. Everyone agrees that the FIFO is physically capable of being written by both EDMA and CPU. The part where I believe there is an issue is that you will get interrupts on a sample by sample basis and not due to the FIFO theshold being reached.
So are you getting interrupts based on FIFO threshold, or are you getting interrupts every sample? I expect that you're getting an interrupt every single sample regardless of FIFO level.
Hi Brad, I'm not sure since I am not using interrupts. All I need to do at this stage is transmit five words out of the port, so there is no need to enable any interrupt. However, at some point in the future I need to configure the McAsp to receive as well, and then it will be useful to use interrupts - the ideal would be to have an interrupt when the receive FIFO reaches a set threshold. Is this the behaviour you expect? Or will I just not get any interrupts at all? I will investigate further and let you know what I find. Thanks, as ever, for your help. Cheers, John.
I'm not sure since I am not using interrupts. All I need to do at this stage is transmit five words out of the port, so there is no need to enable any interrupt.
However, at some point in the future I need to configure the McAsp to receive as well, and then it will be useful to use interrupts - the ideal would be to have an interrupt when the receive FIFO reaches a set threshold. Is this the behaviour you expect? Or will I just not get any interrupts at all? I will investigate further and let you know what I find.
Thanks, as ever, for your help.
Hi John,
Sorry for the slow reply. I was on vacation last week.
This all makes more sense now that I know you're only transmitting 5 words. I would expect everything to work fine for this use case.
The interrupts are not connected to the FIFO. That means you will get interrupts on a sample-by-sample basis and there will be no knowledge of any kind of FIFO theshold. It is not possible to get interrupts when the FIFO threshold is reached. Only EDMA events are generated when the FIFO threshold is reached. You could potentially do something such as creating a dummy EDMA transfer associated with that channel and then have a completion interrupt for that dummy transfer. That seems a bit of a waste though. In other words, if you do that much effort with the EDMA you might as well use the EDMA to actually transfer the data!
Yep that is pretty much the behaviour I see. Looks like I will have to use the DMA after all, for reception at least. Thank you very much for your help.
Found this thread in google, thought I would add a note for others searching for answers.
I have had success using the FIFO for the McASP on the OMAP-L138 as described in this thread, without DMA, using the "LAST" interrupt. This allows me to use the FIFO to grab an entire frame of data from the serializer, one interrupt per frame (instead of a separate interrupt for each slot in the frame).
This is useful if you don't want (or need) to deal with the DMA.
Hi Judson,
Cool, well done for finding that, wish I'd discovered it back in the day. Actually, I moved over to use the L138 too shortly after this thread was originally posted and I switched to using the McBSP peripheral because this is much more suited to my application.