Are you using the CYSPP function? Did you enable the flow control of the UART? What's the length of your packet?
Currently I'm not using the CYSPP function.
Right now using the host api, I print out the status of the received packet from the UART. So when I connect via BLE I expect to see a connection event, and when I disconnect I expect to see a disconnect event. For the most part this works consistently, but sometimes I will notice what looks be a new packet gets sent, but doesn't get complete.
For example after receiving successful connection event, I will get a byte 0x0C. And that's it... Because of this my parser ends up in a waiting state (btw, is there no timeout implemented for RX on the host side?).
I'm curious if perhaps it is my UART that is missing data. Or is this some but that sometimes occurs?
For UART I am just using the factory default, 115200bps, 8bit, no flow control.
Could you use a USB-UART tool to connect the module with your computer and check if the packet is complete on the serial port tool in your computer.
Please refer to chapter 6.1 in the user guide v1.1.1 to check the UART issue between your host and the module.
Unfortunately I cannot connect my module to a computer like that. Is the implication though that I may have a faulty module? I can definitely try swapping the module and testing that out.
Otherwise, does the host API contain timeout code if a received packet never finishes? I know the module has a timeout condition when in binary mode, but how about the host api? Or is this something I might need to implement?
The two C/C++ example projects supplied in the host library archive (one for PSoC4, one for Arduino) both implement simple timeouts for incoming responses in the demo use of the EZS_SEND_AND_WAIT() macro, but other parts of the code use the non-blocking EZS_CHECK_FOR_PACKET() macro instead. The underlying internal library code, particularly the EZSerial_Parse() function, does not implement any mid-packet timeout for incoming data. The parse function does return unique results for each byte so that the application could implement its own timeout if you wanted to, e.g.:
- Start timer when the return code is EZS_INPUT_RESULT_IN_PROGRESS
- Stop timer when the return code changes (_PACKET_COMPLETE, _UNHANDLED_PACKET, or _INVALID_CHECKSUM are most likely)
- If timer expires before (2), then treat as incomplete packet timeout
However, I doubt this is happening. There are no known cases that would cause a module to stop sending a packet mid-stream, with two exceptions:
- Power failure or complete reset (should be very apparent in any case)
- Flow control enabled and host-side RTS pin de-asserted (should also be very apparent, and you're not using flow control)
I would also be surprised if the module was faulty; if this was the case, you'd probably have many other worse problems.
Since you've said you can't connect the module to a computer, is there any way that you can get a logic analyzer or UART sniffer of some kind on the UART lines, even just the module's TXD line where the responses/events should be coming from? This is usually the most direct way to detect the source of the failure. If the data shows up on the analyzer and not the host, then it's the host's fault; but if it doesn't show up on the analyzer or the host, then it could be the module's fault.
The problem ended up that my micro was missing incoming data from the UART!