RC7620 - Hardware flow control

IoT Modules RC76
1

Hi,
recently we switched from HL7692 to RC7620.
The module is updated with the last firmware version SWI9X07H_00.09.10.00
We are using the module connected with a PIC32 mcu (PIC32MX440F512H), via UART. We have hardware flow control enable (AT+IFC=2,2) on both side.
The module works fine until some AT command with large response is executed, on this responses we lost some characters. (+KCELL for example or +CMGR=0). The MCU register that indicates a buffer overrun on UART is asserted (U2STAbits.OERR == 1).

We also tried to change the baud rate from 115200 to 1M baud/s but nothing changed.

Is there some know problem on RC7620 regarding the flow controls on UART?

2

Do you see the flow control pin asserted in oscilloscope during overrun case?
Do you see this problem on tera term in windows?

3

Hi @jyijyi,
unfortunately I cannot set up a test environment right now.
I can, instead, enable the DM port and dump the log. Please let me know if this could be useful,. I never use DM port before, maybe I’ll need some hint.

Continuing my test I discovered the hw flow controls don’t work as expected until I sent AT+KTCPSND. Seems very strange but is reproducible. After AT+KTCPSND the behaiviour of RTS and CTS change drastically.
(I dumped the value of RTS and CTS pins on console during some key moments). Sincerely I cannot find any logical correlation between KTCPSND and hw flow controls, but that’s it.

4

I don’t quite see such problem for tera term in Windows with UART communication:


at+ifc=2,2
OK
at!gstatus?
!GSTATUS:
Current Time:  366              Temperature: 23
Modem Mitigate Level: 0         ModemProc Mitigate Level: 0
Reset Counter: 1                Mode:        ONLINE
System mode:   LTE              PS state:    Attached
IMS reg state: REGISTERED       IMS mode:    Normal
IMS Srv State: FULL SMS,FULL VoIP
LTE band:      B3               LTE bw:      10 MHz
LTE Rx chan:   1250             LTE Tx chan: 19250
LTE CA state:  INACTIVE
EMM state:     Registered       Normal Service
RRC state:     RRC Idle

PCC RxM RSSI:  -60              RSRP (dBm):  -89
PCC RxD RSSI:  -93              RSRP (dBm):  -125
Tx Power:      --               TAC:         2775 (10101)
RSRQ (dB):     -11              Cell ID:     016E8A2B (24021547)
SINR (dB):      5.8

OK
at+cmgr=0
+CMGR: 1,,155
07915892100064F2240BD0B119CEDA9C02000842105251044323884F6067090031500B65B053E38A0A3002670065B04E00500B53E38A0A4F8681EA0033003700300037003200390039003030028ACB81F496FB002200310033003800226536807D300259828EAB86556D775916FF0C8ACB81F496FB0022002A003100330031002A003100330038002300226536807D00289700652F4ED86F2B904A8CBB752800293002

OK
at+kcell=0

+KCELL: 0
+KCELL: 0
+KCELL: 3,5,54f460,016e8a2b,437,10101,50,8,-1,6,1250,437,50,9,6,1250,237,44,6

OK
ati3
Manufacturer: Sierra Wireless, Incorporated
Model: RC7620-1
Revision: SWI9X07H_00.09.10.00 85890e jenkins 2023/09/25 03:16:56
IMEI: 353635110212345
IMEI SV: 29
FSN: 7T118701512345
+GCAP: +CGSM

OK
5

Ok, thank you … that’s strange, I can reproduce the problem on different modules, even on previous version (release 9).
Do you think it is possible that tera term and windows are fast enough to consume rx buffer “in realtime” without a real need of “flow controls” that suspend the transmission for a while?

6

i think you need to get an answer by using oscilloscope to see whether actually there is hardware flow control pin triggered by your MCU.