RAK3172 + RUI ver.4.0.5, api.system.sleep.all() not working

Did you upgrade these “old” modules to RUI3 V4.0.5 as well?

Had my setup running over night and still cannot reproduce it.

Yes, we also upgrade these “old” modules as well, we are investigating if it is our UART to USB dongles, it is good that since you cannot reproduce the issue, we are getting new dongles and hopefully that is the culprit. We are receiving the new dongles tomorrow and will test. Hopefully it is the dongles, this way we can send all our our modules we purchased last year and this year to the fab house to be use.

good news, looks like you are right, our UART to USB dongles might have causes the no response issue. We are running test with the new UART to USB dongles we just received, so far no timeout. This is great, we can produce some prototype pcb and test.

Thanks,
James

Hi James,

Good news indeed.
May I ask the difference between the two dongles? What USB/UART chips are used on them.

As reference, my setup is using a CH340 chip.

Ah, I believe CH340G is the same design as the FTDI FT232R, but Chinese version
So interestingly, the chips that we can constantly reproduce the issue are:

  1. Silabs CP2102N, we use the 20 pins version
  2. FTDI FT245RQ

The new one we recently obtain that is working so far is the FTDI FT232RL. This is interesting because FTDI cost more vs Silabs, we are going to PCB them both and see.

We choose the CH430 because it is available in a small package. On our WisBlock Core modules we do not have much PCB space.

Yes, we chose Silabs chip because of its size as well, is it possible if you can find out the RX line on the 3172 module prefer Push-Pull or Open Drain from the TXT side (the USB to UART chip), because we know that these pins can be configured and they are usually configure different from chip to chip and manufacturer to manufacturer, for example for our Silabs CP2102, we can configure it as shown below and program it to the chip.

Checking with our engineering staff.

in the (english version) of the CH340E I found only

Data transfer pins contain: TXD and RXD pin. RXD keeps high when UART reception is idle.
For CH340G/C/T/R chip, If R232 pin is driven high, assistant RS232 function will be enabled, an
internal inverter will automatically insert to the RXD pin , and the pin becomes low by default. When
UART transmission is idle, the TXD pin of CH340G/C/B/T keeps high, while CH340R keeps low.

Which suggests there is just an internal pull-up on the RXD, but it doesn’t say anything whether it is push-pull or open-drain.

@hunghp

TX of CH340E( which connect RX of MCU ) is Push-Pull
RX of CH340E( which connect TX of MCU ) is input with 60K built in pull up resisistor.

Thank you, we have made the changes to the CP2102 chip and started the testing, so far our new dongle is doing great no issue.

Again thank you for the information, we like to stay with the CP2102 chip, cost less than the FTDI. :slight_smile:

Hello James

We are using the CP2102 USB-Serial Bridge in our designs at 115200 baud

When connecting to a PC serial terminal with a USB connection we do get random character on some transmits.

If we monitor the data at the serial TTL input to the CP2102 USB-Serial Bridge there is never any random characters

You mentioned that you made changes to the CP2102

Could you please share the changes you made

Thank You

Paul Humphreys

@dingoxx, will do, we do see random character as well, however, super rare, and for our application it is not a concern. I will check with our engineering team and update you on this after the weekend.

James

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.