Randy,
Thanks for the quick reply
- N1. I am not sure what you are polling on, the interrupt flag being set or the ready bit in the UART
We poll the ready bit in the UART
- N2. If you poll the ready line and read some data, then you will wait for another polling loop to either check for ready again or note that the full 10 has been received. Is that correct? Is it true that there would always be some number of data-read passes through the loop and then one more pass to note the completion?
Correct, and Correct. The minimum number of passes is two (all data would have to come in in between polls)
- N3. I will have to study the UART User Guide to understand the operation of the FIFO. When you get the data interrupt, you do not do anything until you make another pass through the polling loop, right?
Our communications are in a master/slave relationship. After we start receiving we do not do any more processing dealing with communications until we check again.
- D1. I will have to study the UART User Guide to understand the operation of the FIFO and when it sends a DMA event.
Sounds good
- D2. The DMA will read 1 byte every time it gets an event from the UART to trigger it. If there is a long time between one read and the next (the 300us delay we are talking about), then something has to trigger the DMA UART Rx Channel to go read one more byte each time. I did not notice that being done in the polling loop, so I do not understand how the data gets read, unless the UART will repeatedly send events until it is empty. The EDMA3 should respond to each event very quickly.
If i'm not mistaken (please check my initialization) I have the DMA UART Rx Channel to trigger off of the UART data ready flag. But yes, this is really the source of confusion.
- a. edma_getAccntLength - the name implies you are reading ACNT, but ACNT should always read 1 from the values in your first post. What is this doing?
perhaps edma_getAccntCount would be a better name. This function subtracts the current Bccnt from the original Bccnt. This gives the total number of transfers triggered. It was used for debugging purposes.
- b. You are writing to a reload Param, but you set the linkAddr to 0xFFFF. Do you have other plans for the reload (link) Param? It is not going to be used in this case, with Link = 0xFFFF.
We link to 0xFFFF for debugging reasons, we reload with channel 28 after the data has been recieved and processed. We don't know the length of the messages coming in so we can't count on running through Accnt x Bccnt transfers to restart.
- c. srcCIdx should also be 0, like srcBIdx. It will not show up until you exhaust the BCNT field, which will only happen for a long message. This appears in two places.
Good to know what I messed up shouldn't impact the problem, I will change this.
- d. There are two sets of assignments to load paramSet. In the set after the "Now, write the PaRAM Sets" part, there is a line with an unknown (to me) value of EDMA3CC_OPT_DAM. You do not want to set the DAM or SAM bits to 1. This code may be for the Tx side, but you still do not want to set SAM or DAM.
That is for the Tx side, after reviewing the datasheet a bit closer I will remove these.
I will go and make these minor changes, and get back to you when ever the test station gets open.
Thank you for your help and time,
Sam