Hardware flow control problems with HL7802: CTS pulses during transmission

I am testing the HL7802 modem with firmware HL7802.4.6.8 (HL78xx. in the HL78 Development KIT Rev 4. I am trying to get the sense of how Hardware Flow Control using the CTS and RTS signals work. I cannot get it working with UART hardware flow control in our hardware so I thought to test it in the KIT first.
I hooked up a logic analyzer on the breakout header and got the following results.

This is how the CTS signal operates all the time. What I wanted to do is check if CTS is low before reading response from the modem, because that is supposed to be stable. With the CTS pulsing this way, I have no confidence that it is operating properly especially in data mode. I get TCP data upload failures that go away when I disable hardware flow control for this modem in our product. The problem is, I have common firmware that supports various modems in the HL, SL and now RC series. I need to release a unified firmware and this requires unified flow control support for all modems.
Is this behavior of the CTS signal by design? Can anyone confirm the expected behavior?

Do you also enable hardware flow control on your MCU?
It should not be a problem, the transfer should stop automatically if you enable hardware flow control on your MCU

BTW, what is the setting for AT&k?

how about using the latest FW?

As I stated in the problem description, we use hardware flow control for all modems we support on the MCU. With the HL7802, it does not work when we have hardware flow control enabled, we have to disable it in the MCU then it works.
In the solution, I have two GPIOs configured for HW flow control in the MCU. CTS as an input which I check that it is low before I send commands or data to the modem and the RTS pin that I set low to receive response from the modem (I actually set it low all the time)

I am trying to test using your HL78 Development KIT. I have a script in the computer that connects to the UART1 COM port to control the modem. I can read CTS and control RTS just fine.
Below is the command I am using to enable flow control in the modem

> AT&K0


> AT&K1


> AT&K3

The Datasheet (Rev 16) says AT&K where n=0 is flow control disabled in modem and n=1 is flow control enabled in modem, but AT&K=1 returns error. AT&K=3 works to enable flow control like in HL76xx series.

Having enabled flow control, the CTS signal shows the very brief pulses during both data and command sending to modem as indicated in the timing diagram I shared in my earlier message. It is almost like the modem has a 2 byte cache and every two bytes or so it momentarily takes CTS high only to take it low again so soon. In our solution, we are using interrupt method in the UART and we disable transmit interrupts, which halt sending, when CTS is high. But CTS is controlled by the modem in such a jerky way that I do not see the benefit of it since it will cause too many interrupts in our system. None of the other modems behave this way.

Can you confirm if this is a feature or a bug?

I have tried the latest firmware HL7802. with the same results.

Bottom line is, when I use HL7802 modem especially connecting to 2G networks, sending data fails midway transmission in data mode. I really need you to confirm what is the best approach to dealing with this UART flow control, there is not a whole lot of details on this particular part.

Do you mean you still see this in dev kit

Yes, I do, and I am trying to understand if it is the way this modem is supposed to behave. Am I supposed to use polling method and check CTS before every single byte is transmitted?

Do you see such issue in dev kit with HL7802?

Yes, here are some captures:



In the response, CTS stays low, but during command or data sending to modem this is how the CTS signal behaves

Do you see such issue in dev kit with HL7802?

I simulated sending a big file to the modem all at once to reproduce our situation in the product and for sure here is the capture of the situation

And here is a close up

You can see the CTS signal keeps jumping up and down and finally when the modem buffer is full it issues an always high signal. CTS should have stayed permanently low until this point without the pulses, then it would work. It is tough interpreting this pulses on the CTS output from the modem. sure we can filter them out, but what is the point of the modem sending the pulses on a flow control line?