uDMA QSPI doc updates #352
Conversation
There was a problem hiding this comment.
Hi @cst-aditya, this is excellent. I have made a few review comments that should be addressed before we merge this in, please have look.
|
|
||
| **Read command from L2 memory** | ||
|
|
||
| - Configure the TX channel using the CMD_CFG CSR. Refer to the CSR details for detailed information. |
There was a problem hiding this comment.
Maybe this should be, "Configure the RX channel..."
There was a problem hiding this comment.
Hi Mike, Thank you for feedback. I cross-checked again; it should be Tx only. Actually, Tx channel is used to read command data from L2 memory in both Rx and Tx operations.
| Clock Enable, Reset & Configure uDMA QSPI | ||
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | ||
| - Configure uDMA Core's PERIPH_CLK_ENABLE to enable uDMA QSPI's peripheral clock. A peripheral clock is used to calculate the baud rate in uDMA QSPI. | ||
| - Configure uDMA Core's PERIPH_RESET CSR to issue a reset signal to uDMA QSPI. It acts as a soft reset for uDMA QSPI. |
There was a problem hiding this comment.
Does a "soft reset" do anything different that a "hard reset"?
There was a problem hiding this comment.
No, it does not do anything different. In fact, uDMA QSPI has only one reset pin , which can be asserted in below scenarios:
a) System system
b) Setting the corresponding bit in the uDMA Core's PERIPH_RESET CSR.
I have updated the document to have the below information:
- Configure uDMA Core's PERIPH_RESET CSR to issue a reset signal to uDMA QSPI. The uDMA QSPI can be reset via:
- System system
- Setting corresponding bit in the uDMA Core's PERIPH_RESET CSR
| uDMA QSPI Block Diagram | ||
|
|
||
| In the block diagram above, the DATA lines at the boundary of the uDMA QSPI are 32 bits wide, whereas other DATA lines are only 8 bits wide. The DATASIZE pin is 2 bits wide and can be configured using datasize bitfield of the CFG csr. | ||
| When transmitting data to uDMA Core, the unused bits are filled with 0x0 to form 32-bit |
There was a problem hiding this comment.
Does this imply that the firmware should load the L2 buffer with zero-filled messages? That is, if a four-byte message to be transmitted is 0x11, 0x22, 0x33, 0x44, the L2 buffer should be 0x00000011, 0x00000022, 0x00000033, 0x00000044. Is that right?
There was a problem hiding this comment.
If a four-byte message is to be transmitted (read from L2 memory and transmitted to the external device), i.e., firmware should fill the four bytes as 0x11, 0x22, 0x33, and 0x44, not 0x00000011, 0x00000022, 0x00000033, and 0x00000044. The uDMA core will read the data from L2 memory based on Tx channel configuration. The Tx channel reads the data from L2 memory and shares it with the uDMA peripheral via the uDMA core.
I have updated wording as below; Let me know if more information is needed.
In the block diagram above, the DATA lines are 32 bits wide. The DATASIZE pin is 2 bits wide and can be configured using datasize bitfield of the CFG csr.
When transmitting data to uDMA Core, the unused bits are filled with 0x0 to form 32-bit i.e. if the data received from the external device is less that 32 bit the unused bits will be filled with zero.
The uDMA core interprets data in multiples defined by the datasize bitfield of the CFG CSR.
|
|
||
| The diagram below shows the interfaces of DC FIFO: | ||
|
|
||
| .. figure:: uDMA_UART_Dual_clock_fifo.png |
There was a problem hiding this comment.
This file is not part of this pull request.
There was a problem hiding this comment.
Fixed in the latest version.
| uDMA QSPI has a Tx and Command FIFO to store the received Tx and command data from the uDMA core. It forwards the data read from L2 memory to the Tx DC FIFO. uDMA QSPI on the Tx path reads the data from Tx DC FIFO and transmits it to the external device. | ||
| It is a 2-depth FIFO and can store 32-bit wide data. The diagram below shows the interfaces of Tx FIFO: | ||
|
|
||
| .. figure:: uDMA_Uart_TX_FIFO.png |
There was a problem hiding this comment.
This file is not part of this pull request.
There was a problem hiding this comment.
Fixed in the latest version.
|
|
||
| - SPI_CMD_WAIT | ||
|
|
||
| uDMA QSPI supports the concept of itroducing delay during transaction. There are two way to introduce delay: - |
There was a problem hiding this comment.
Typo: itroducing should be introducing.
There was a problem hiding this comment.
Fixed in the latest version.
2 participants
No description provided.