SerialPassThrough don't send anything on RP2040

[ManuDLT]

I'm using the RP2040 as an USB interface to connect the PC with another CI (CC1352 of TI) with a simple SerialPassThrough code

unsigned long baud = 115200

void setup() {
  //Begin Serial ports
  Serial.begin(baud);
  Serial1.begin(baud);
}

void loop() {
  //SerialPassthrough
  if (Serial.available()) {      // If anything comes in Serial (USB),
    Serial1.write(Serial.read());   // read it and send it out Serial1 (pins 0 & 1)
  }

  if (Serial1.available()) {     // If anything comes in Serial1 (pins 0 & 1)
    Serial.write(Serial1.read());   // read it and send it out Serial (USB)
  }
}

The issue:
When I send a simple string from the Arduino Serial Monitor (Or any other serial software) I can see it in the Serial 1 correctly, but when I try loading a .hex file for programming the other chip, nothing happens.
Both tests were seen in an osciloscope, and theres no output at the second test.

I have another board where I use a SAMD21 at the same application (even with the same TI chip), and there I don't have any problem to do this. So I tried making a bridge:
USB <-> SAMD21_Serial <-> SAMD21_Serial1 <-> RP2040_Serial1 <-> RP2040_Serial2 <-> CC1352
And it works corectly.
Then I switch the SAMD and the RP like this:
USB <-> RP2040_Serial <-> RP2040_Serial1 <-> SAMD21_Serial1 <-> SAMD21_Serial2 <-> CC1352
And it doesn't works.

Looks like the problem is not at the SERCOM (Serial1 & Serial2) ports but is in the USB (Serial) buffers or in the trasition of the data between the Serial and Serial1.

[facchinm]

Hi @ManuDLT ,
do you use any special utility to load the .hex file ?
One of the issues with mbed boards SerialUSB object is that setting dtr or rts might trigger the disconnection of the board from the USB point of view https://github.com/arduino/ArduinoCore-mbed/blob/master/cores/arduino/USB/USBCDC.cpp#L231-L236

While this follows the standard, on other boards (like SAMD) we are more relaxed and just set the internal state for dtr() and rts() APIs.

Could you try removing the linked lines from your core, retest the application and report the results? Thanks!

[ManuDLT]

Hi @ManuDLT , do you use any special utility to load the .hex file ?

I have two options, one is the SmartRF Flash Programmer 2 that Texas Instruments provide.
Or the python script from https://github.com/JelmerT/cc2538-bsl

Could you try removing the linked lines from your core, retest the application and report the results? Thanks!

I tried removing all those linked lines but it doesn't work.
Then I just removed L235 like this

if (setup->wValue & CLS_DTR) {
                    _change_terminal_connected(true);
                } else {
                   // _change_terminal_connected(false);
                }

And it works fairly well, but stays idle until I open the Arduino Serial Monitor. After that I changed the same line, to an always true state:

if (setup->wValue & CLS_DTR) {
                    _change_terminal_connected(true);
                } else {
                    _change_terminal_connected(true);
                }

And it works, but this produces another bug: I can't reprogram with the Arduino IDE and it seems to happen because the IDE can't reboot the board. So i had to reboot on boot mode and change the .uf2 for a program without those changes.

How could I fix it?

P.S. The change works good with the Python script, but with the Texas Instruments software just works once, after that the software can't upload the .hex again until I unplug and plug the board back into the PC. (This is a minor issue)

[facchinm]

There's no actual way to fix it, that's the reason why that patch is not applied by default 🙃

Anyway, to make your life easier when you want to reflash the sketch, you can switch to boot mode by double pressing the reset button and then starting the upload from the IDE.
Even if no port is selected the tools will recognize the rp2040 in boot mode and program it just fine.

I'm closing the issue as "solved" since there's not clear path on our side to fix this, but it could be interesting to document the behaviour nevertheless @sebromero

[facchinm]

One last thing: you could try keeping the standard unpatched core but slightly changing https://github.com/JelmerT/cc2538-bsl/blob/master/cc2538-bsl.py#L220 (which uses dtr and rts signals to trigger the reset pin on CC1352) or commenting https://github.com/JelmerT/cc2538-bsl/blob/master/cc2538-bsl.py#L1223 and everything should work seamlessly

[ManuDLT]

One last thing: you could try keeping the standard unpatched core but slightly changing https://github.com/JelmerT/cc2538-bsl/blob/master/cc2538-bsl.py#L220 (which uses dtr and rts signals to trigger the reset pin on CC1352) or commenting https://github.com/JelmerT/cc2538-bsl/blob/master/cc2538-bsl.py#L1223 and everything should work seamlessly

This actually worked, but not completly. Because after I programmed the CC1352, I need to use the "SmartRF Packet Sniffer", but it does not recognize the chip (Same issue but with another software). So I guess I will work with the patched core and forcing the boot mode.

Thanks!