Hi,
Our setup has a external MCU that is connected to DA14580 over UART. DA14580 and the MCU communicate with each other using a protocol we have designed.
DA14580 is waiting on uart read for 5 byte header. The MCU sends the header (5 bytes) which has the data_length. DA14580 then does the uart_read with data_length bytes to be received.
Observation:
Assume, MCU has to send 5 byte header and 32 byte data.
The internal buffer used by the UART HW seems to be of 16 bytes. Because what we see is that the DA14580 receives the header properly and then tries to read 32 bytes in a go then if some part of data is already present in the UART HW buffer of DA14580 then the read callback is never called ie. the 32 bytes are never read completely.
Whereas if the uart read of 32 bytes is called before the actual data is received from the MCU the entire read is successful and the read callback gets executed correctly.
我们也试着阅读从DA14580 af一对一的字节ter the header is read. In this case, what happens is, (16 - 5) ie 11 bytes are read correctly one by one. Although, the other bytes are never received by DA14580 although they are already sent by the MCU.
Seems to be an issue with DA14580 UART. Could you please check and revert.
没有te: We also enabled HW level flow control and are still seeing this issue. Can you please confirm if HW flow control is working fine and is turned on using the API uart_flow_on()
- Hrishikesh
Hello Hrishikesh,
I am currently investigating this issue and will provide an update to resolve this.
Best,
LC
Hello Hrishikesh,
The hardware FIFO is of 16 bytes and as per the standard providing interrupts at 1, 4, 8 and 14 bytes. What is the current interrupt level are you using? If you are having a trouble with the current interrup level, then you can do the following options
Disable to FIFO and read the data normally from the receiver buffer. This can be achieved by monitoring the Rx Data Avaliable interrupt and Rx Timeout interrupt. This way you will be in control of how much data you are receving. Based on the lenght field in your header, you can read incrementing to that many bytes.
The other option would be to configure your RTL interrupt to trigger for every byte received in the FIFO that includes receiving the header (works best at lower speeds (upto say 115200). This way you will read the data much according to your needs.
Please provide some more insight into your application implementation like the current baudrate, what is your RTL interrupt etc and how you reading the first header and then next data, that will be much helpfull in finding out the actual problem. Please let me know if you have any more concerns
Best,
LC
The uart related issue is solved. The problem was that the uart flow control was not getting enabled.
We were using uart_flow_on() API after the call to uart_init()
This should be documented in the SDK header file for uart_flow_on() : This API needs to be called before uart_init() to take effect.
Hello dhrishi,
The order of theuart_flow_on()anduart_init()should not matter for the Hardware flow control to be enabled. There should be some other reason this might be happening.
Please confirm if the issue you were facing is completely resolved.
Best,
LC
Yes. The issue we were facing is completely resolved. Although, when I interchange the sequence of uart_flow_on() and uart_init() I could see that the flow control does not come into effect.
Anyway, I will give it a try once again and update in case of any new observations/findings.
Thanks,
Hrishikesh
Hello Hrishikesh,
Good to hear that it is resolved. I will review it if it isn't specified and make sure it is updated in relevant places.
Best,
LC
Hi LC,
I am having similar issue with UART read from an external MCU as well.
After reading this post, I tried per the suggestion by calling uart_flow_on() after uart_init(). That didn't help me.
What I have is a UART2 setup to communicate with an external MCU at 57.6Kbps. Sending data from DA to external MCU is fine. it was able to receive everything the DA sends. However, when receiving UART data from the external MCU back into the DA has frame error for every transaction. I have attached the Saleae capture for you to look at.
In the capture, DataToQPI is data sent from DA to external MCU while DataFromQPI is data sent from external MCU to DA.
Thank you,
--Khai
Hi LC,
I figured out my problem. I had to configure the RX pin as PULL_UP below:
GPIO_ConfigurePin( GPIO_UART2_RX_PORT, GPIO_UART2_RX_PIN, INPUT_PULLUP, PID_UART2_RX, false );
Thanks,
--Khai
Hi LC,
没有w that that RX PULL_UP line is out of the way, I have a follow on issue with reading the data on the RX line into DA buffer. Below is my code in reading the RX data out of UARt2:
bool readFromCIIf(BYTE* data, int data_len) {
bool r = true;
short idx = 0;
int nbytes = 0, bytes_left = data_len;
while(idx < data_len) {
// wait 1ms for FPGA to load a byte in the CI UART data register
qpiSpinCounter(TICK_1MSEC);
// find out how many bytes to send to ASIC's CI output buffer
// Khai: try using CI_OUTPUT_BUFFER_SZ instead of RX_CALLBACK_SIZE
if (bytes_left > CI_OUTPUT_BUFFER_SZ)
nbytes = CI_OUTPUT_BUFFER_SZ;
else
nbytes = bytes_left;
// remove the bytes that will be retrieved from total remaining
bytes_left -= nbytes;
// read the bytes from ASIC
uart2_read(data+idx, nbytes, NULL);
idx += nbytes;
}
return r;
}
I have played with both CI_OUTPUT_BUFFER_SZ = 256 bytes while RX_CALLBACK_SIZE = 8 bytes. The caller to this function requests to read 140 bytes. I have looked in the RX line with Saleae and all 140 bytes were were on the wire in the attached logicdata file. However, when the above function walked through the loop to read, the bytes read into the buffer wasn't the same as what's on the wire.
When I used RX_CALLBACK_SIZE, the first 16 bytes looked good. After that, the bytes in memory are missing and being skipped to the next several bytes. Then, the rest are then all 0s at time point. When using CI_OUTPUT_BUFFER_SZ, I would only get maybe the first 16 bytes and the rest are 0s.
Somehow specifying the read buffer size for each read seems to matter. What does this have to be to read the data correctly?
Thanks,
--Khai
Hello Khai,
I am unable to reproduce that issue on my end. So I am not exactly sure what is going wrong in this case. However, I would make a couple of suggestions.
1. Please check if you GPIO are assigned accordingly and the connections are right. I think they are alligned properly since you can see the data on the Logic Analyzer.
2. I am attaching a sample driver that was modified from the actual driver to address RX FIFO adjustment. Try using this driver in place of the current one and check if that solves the issue. Note that this is not a official release driver and only for testing purposes.
Best,
LC
Hi LC,
In the new modified_uart2.c file in function uart2_init(uint16_t baudr, uint8_t dlf_value, uint8_t mode), what is the setting for the second parameter dlf_value? This parameter wasn't required in my uart2.c file.
Shouldn't you then have to also send me the uart2.h file too?
Thanks,
--Khai
Hello Khai,
Please use the attached header file here. There are few updates in the uart driver in the latest release.
Best,
LC