UART freeze RP2040 ?!

[HappyStoat]

Hallo Earle,
I have a flight controller based on the RP2040 that speaks to the Raspberry PI Zero 2 W via UART (Serial1).
The distance between them is less than one centimeter and the amount of data is so small that even a 9600 baud rate would be enough (its just some telemetry data). I've been flying with this config for a long time now without any problems!

However, since I have connected a modem (SIM7600) to the zero, the R2040 often gets stuck. This is a pretty big problem and I'm lucky that I always do a lot of testing on the ground. The Zero and the modem continue to run without problems, including the video stream.

With a lot of effort I managed to narrow down the cause and can cause the error at any time. The quickest way to do this is to hold my hand in front of the Zero camera and then quickly pull it away. Then the RP2040 program often simply stops. After a reset it works again. There are other weird ways to trigger the freeze.

I suspect that the Zero simply needs more computing power elsewhere with the connected modem, which is why it can no longer maintain the 115200 baud rate. But the error also occurs with a lower baud rates.
I've read that if I use the internal PL011 controller for the Uart on the Zero, the baud rate should stay the same, but I haven't tested it yet.

You could say that the fault is not with the RP2040, but ultimately it shouldn't just stop!
I would really appreciate it if you or someone else could help me to solve this error reliably.
My hardware setup should stay as it is.

To be on the safe side, I set up a second setup and the same error occurs here.

[HappyStoat]

If someone thinks that the zero might send so quickly that the RP2040 can no longer get out of the read (which is a reasonable assumption):

1. I limit the TX data on the Zero side so that data only goes out every 10ms

2. Also for safety reasons, the RP2040 does not have a while(serial->available()) but an if (serial->available())

3. Even if I do a while (which could prevent the 32 byte buffer from overflowing) the same error occurs

This error is definitely in the top 3 of the most annoying errors I've ever had^^

[earlephilhower]

Converted to a discussion because without special hardware and your code, condensed to an MCVE, there's not much we can do here.

FWIW, the UART should happily overflow and throw away characters without crashing. You can make a simple sketch to verify this, just start the UART and delay(5000) while your transmitter sends a series of incrementing #s. After the delay you can read what's in the serial buffer and verify a) the core isn't frozen and b) it did overflow. If it does not, we have a bug and a sketch to cause it to fail which is all we need to fix it. :)

If you overflow and drop chars, does your code gracefully handle this? Or would it always be out of sync and, say, interpret a data byte as a command byte?

I also remember doing up to 1MHZ loopback testing (don't quote me on this, but way above 115.2k) when I added the lockless SW FIFO used here.

I would suggest hooking up a picoprobe and running GDB to find out exactly what the core is/was doing. You can get stack traces of both cores this way and see what's up even w/o having to share or minimize your code.

[HappyStoat]

I don't know if the Sim7600 can still be called a modem, at least that's what I call them. They receive LTE, UMTS and GSM. But only LTE is interesting to me.

I'll come back to the freeze next week when my SIM cards arrive. Yes, maybe I should really connect the DebugPins so I can connect a PicoProbe.

Thanks for addressing the upload issue:
If I start the RP2040 and hold down the boot button (then it appears as a USB stick), the upload always works. Only when I upload the code normally it does often get stuck in the upload because it can't find the RP2040. Could this have something to do with the fact that I have relatively large capacitors? My guess was that this is why resetting the Com port sometimes fails. I had already planned smaller caps for my next PCBs. Could that be the error?

Here is a picture of my settings and the error:

[earlephilhower]

That says that the Pico didn't reset into ROM bootloader mode after the 1200bps twiddle. If your Pico has crashed (or has IRQs disabled, etc.), it's not going to be able to do that since the USB is run on the core as part of the app. Not generally a HW error (especially since ROM upload works).

Again, I would suggest getting a SWD hooked up and seeing what's going on when one of these failure modes occurs. Could just be a bug somewhere and not anything to do with HW or the modems.

[HappyStoat]

I often had the feeling that when the RP2040 was particularly busy, the upload error occurred more often. But I have never tested this with a simple Blink example. That would also explain why the serial monitor often just stops, but the program continues to run. I'll try it.

Just to clarify, the upload error is independent of the freeze. This comes even if everything is okay. But if it depends on the load, you should actually be able to fix it in the software. Is this perhaps only known to a few people because they simply haven't exhausted the performance yet? I have often read about people having problems with this. But in many cases, of course, you think it's somehow your own fault or an arduino bug, which is why you don't immediately make an RP2040 issue out of it.
Could I somehow increase the reset time or something similar? What do you mean with the 1200bps twiddle?

In any case, I just ordered an official Pico board to compare. But I could well imagine that it would be the same here.

To get an idea of how much I use the RP2040 I have a Hz counter that shows me how often my intervals are actually being called:

48/50 (Altitude and Position Hold Controller)
480 / 500 (Rate Controller)
1480/ 1600 (Raw IMU readings)

These are approximate values from my memory. So the RP2040 is already well utilized and does not reach the requested rate. But that may also be due to the software float calculations. Every sine and cosine calculation costs power. I think my code is already very optimized. But of course more is always possible ;)

Unfortunately, I didn't connect the SWD pin to the current PCB and I don't have a pico probe to hand either, sorry...!

[HappyStoat]

Happy New Year :)

[HappyStoat]

As far as the freeze is concerned, I have now set the Raspberry PI Zero to the PL011 Uart controller and have had no problems with it since then.

As for the upload issue,
I was able to narrow down the problem that the upload sometimes hangs. First I tested it with a simple Blink program. This has always worked. Then I used my flight controller code, but turned off the SPI communication to the IMU (1600/s), that also seemed to work very well.
Maybe it has something to do with the load. But of course it could also be a mistake on my part. Due to lack of time (I have a new job) I'll leave it like this for now. I'll definitely do more detailed tests in the future, but for now I can live with it.