RP2040 suport. problem with start on Pi Pico

[svs072477]

Hi, I build firmware for rp2040 with make raspberrypi_pico_default - it's OK. I convert .elf file to .uf2 with elf2uf2 tool. Then, I take pi pico board, connect to this board module G-91 with MPU9250 and BMP280, and upload firmware. After that, the LED on the board lit up. But the board has ceased to be defined as a usb device. And not connect to QGC. What could be the problem? What am I doing wrong?

[say-paul]

Similar issue faced by me , after loading the firmware the LED lights up, but nothing shows up in QGC.

[dagar]

I didn't realize people were actually using this board yet. I'll order some of this hardware to try and help maintain it. Any suggestions?

FYI @vxj9800

[dagar]

@svs072477 @say-paul are either of you able to get a serial console working?

[vxj9800]

I also did not expect that someone would use this apart from me. In any case, I never checked the board with QGC. I always used the nuttx serial console. Give me today's time. I'll set up my things and check if the board is still functional.

[svs072477]

I also did not expect that someone would use this apart from me. In any case, I never checked the board with QGC. I always used the nuttx serial console. Give me today's time. I'll set up my things and check if the board is still functional.

Thank you, are you connecting the console to some of the UART port? In my case, the board after the flashing firmware is not detect as a USB device. It is not in the output list of the lsusb command

[vxj9800]

@svs072477 Yes, I used to connect to PICO using minicom. Check if a ttyS* or ttyACM* device shows up in /dev/. If it does, then everything should work fine. You can then use putty or minicom to connect to the serial port.

[svs072477]

@svs072477 Yes, I used to connect to PICO using minicom. Check if a ttyS* or ttyACM* device shows up in /dev/. If it does, then everything should work fine. You can then use putty or minicom to connect to the serial port.

Use UART0 or UART1 for connect?

[vxj9800]

You don't have to connect any UART. This is done through USB serial communication. So, just copy the uf2 file to pico. Let it reboot. Then you should see a ttyS* or ttyACM* device shows up in /dev/ if PX4 is running fine. Then you can connect to it using putty or minicom.

[say-paul]

@svs072477 @say-paul are either of you able to get a serial console working?

@vxj9800 I checked from both mac and windows, no where it shows up in /dev/ and COM port respectively. FYI I am current checking only with PICO not connected with any sensors yet, think that shouldn't be concern to get the Serial port working.

[vxj9800]

Yes, it should be fine without any sensors attached. I did try running the uf2 file directly but it didn't boot properly on my pico either. There is some issue for sure. I'm currently setting up debugging using another pico to see exactly where the problem is.

[svs072477]

You don't have to connect any UART. This is done through USB serial communication. So, just copy the uf2 file to pico. Let it reboot. Then you should see a ttyS* or ttyACM* device shows up in /dev/ if PX4 is running fine. Then you can connect to it using putty or minicom.

I have already done this, on a linux computer, but no device ttyS* or ttyACM* after the flashing firmware.

[vxj9800]

@svs072477 @say-paul Some update on the issue. The code is going into hardfault from cromfs_find_node function in fs_cromfs.c. I am not sure what is causing this yet. May be @davids5 can help. But, a temporary fix is to go to the defconfig file and make CONFIG_FS_CROMFS=n. This will avoid the cromfs hardfault. You should at least be able to access the Nuttx shell through usb serial communication as I described earlier.

[svs072477]

@svs072477 @say-paul Some update on the issue. The code is going into hardfault from cromfs_find_node function in fs_cromfs.c. I am not sure what is causing this yet. May be @davids5 can help. But, a temporary fix is to go to the defconfig file and make CONFIG_FS_CROMFS=n. This will avoid the cromfs hardfault. You should at least be able to access the Nuttx shell through usb serial communication as I described earlier.

I did make CONFIG_FS_CROMFS=n, PX4 PespberryPi Pico at /dev/ttyACM0 device appeared, but not connect in putty. could not open port '/dev/ttyACM0': [Errno 5] could not open port /dev/ttyACM0: [Errno 5] Input/output error: '/ dev/ttyACM0'

[vxj9800]

I did make CONFIG_FS_CROMFS=n, PX4 PespberryPi Pico at /dev/ttyACM0 device appeared, but not connect in putty. could not open port '/dev/ttyACM0': [Errno 5] could not open port /dev/ttyACM0: [Errno 5] Input/output error: '/ dev/ttyACM0'

@svs072477 Try opening putty with 'sudo' in linux or 'Admin Privileges' in windows. If it still doesn't work, then hit me up on slack. I'll have to see exactly where things are going wrong in your case.

[svs072477]

I did make CONFIG_FS_CROMFS=n, PX4 PespberryPi Pico at /dev/ttyACM0 device appeared, but not connect in putty. could not open port '/dev/ttyACM0': [Errno 5] could not open port /dev/ttyACM0: [Errno 5] Input/output error: '/ dev/ttyACM0'

@svs072477 Try opening putty with 'sudo' in linux or 'Admin Privileges' in windows. If it still doesn't work, then hit me up on slack. I'll have to see exactly where things are going wrong in your case.

I tried it on a computer with windows and mac os, on them I was able to connect to the nuttx console. Problem with connecting only in linux. Another interesting point is that when pi pico is connected, the RTK streaming icon appears in QGC

[vxj9800]

@svs072477 Thanks for letting me know about the QGC part. It's quite weird that it would show the RTK icon in QGC. I had never tested pico with QGC since my primary goal was to develop PX4 base layer and to get the PX4 to run on the pico. I am developing a fight controller board using RP2040 so I better start looking at QGC as well at some point. In any case, if the issue with linux is the permissions for ttyACM* devices, then something along the lines of https://askubuntu.com/questions/58119/changing-permissions-on-serial-port should solve it.

[svs072477]

@vxj9800 I conducted some experiments by connecting the module, GY-91 with MPU9250 and BMP280. Results:

1. PS4 modules do not start automatically. I manually launched the MPU9250 in the nuttx console (started), bmp280 (did not start), EKF2 (started), MAVLink (started).
2. Then, connected via mavproxy. There is a connecting, a heartbeat is transmitted, a list of parameters is read.
3. It still does not connect to the QGC. In the QGC console there is such a line - e at 0 serial number no known GPS device was found, specify the com port via the qt serial port

[nrodichenko]

I am thinking of creating an RP2040-based flight controller for development purposes

@dagar @vxj9800 would you be available to collaborate on that from the firmware side?

[dagar]

I am thinking of creating an RP2040-based flight controller for development purposes

@dagar @vxj9800 would you be available to collaborate on that from the firmware side?

I'd be happy to talk it through, my first concern is the lack of FPU.

[vxj9800]

I am thinking of creating an RP2040-based flight controller for development purposes

@dagar @vxj9800 would you be available to collaborate on that from the firmware side?

@nrodichenko I work on this during my free time so I may not be able to help you with issues immediately. But, yes, I'm happy to help. You can take a look at my minimalistic version of a flight controller that uses RP2040 here.

@dagar I also had concerns regarding the lack of FPU when I started working on it. So far I haven't seen any major performance issues though. Also, RP2040 has a fast floating point library in it's bootrom, take a look at Section 2.8.3.2 of the datasheet. However, I'm not sure if the Nuttx uses it or not.

[nrodichenko]

Thanks for the update! I've looked at your schematic, and came up with some questions. If you could help me out with those, I would better understand the space and come up with some designs.

• Do you use SBUS, is it supported?
• Is it possible to do more than 4 PWM out channels? (probably instead of buzzer, leds, cts/rts, arm pb)
• Is dshot supported on outputs?
• Why do you use external flash? Is 2MB built-in not enough?
• Can the second spi be used to connect more imus/sensors?
• Are there any limitations on SPI IMUs we can use?

[dagar]

We have a crude microbenchmark in place under systemcmds/microbench. I would try this on an rp2040 to see how it compares. Here's the output from a random stm32f4 board.

nsh> microbench all

[coderkalyan]

My team is also working on an inexpensive RP2040 based FC here: https://gitlab.com/amadoruavs/microdrone/microfcv3 and https://github.com/amadoruavs/microfc-fmu-v3.1. Note that the first board has multiple errors and missing features but was just used a proof of concept/practice run.

For the v3.1 board, I'm planning to use 2 RP2040s, one as an IO processor (after porting px4iofirmware). This gives me extra IO to do SBUS and more PWM.

I'm somewhat worried about not having FPU but I think it should be manageable. The feature set will be lower than an FMUv5 - single IMU suite, so no multi-ekf, etc. But I'll have to see how it goes.

[orkunasa]

I think rp2040 gives us a good chance to implement multiprocessing technology to PX4. rp2040 has two cores and some tasks like camera control can run on the second one. I guess that the implementation might not be easy, however this feature can help to keep needed processing power under control and also it’ll increase the redundancy of the system. Pixhawk's new versions (+v5X) will use ST32H7 - 480 MHz controllers. Some of the STM32H7 processors have multi core and multiprocessing can be very useful for upcoming Pixhawk versions. Also it might help to solve the lack of FPU problem.

[coderkalyan]

Yes, running dual core would help a lot. I'm not sure how much work is involved to do this though.

I just ran microbench on an RP2040 (Raspberry Pi Pico, 125MHz). Significantly slower than an F4 but I'm not sure if its "good enough" or not.

[coderkalyan]

Additionally, the RP2040 ROM has built in floating point routines that are supposed to outperform standard GCC. I wonder if they could be used (or are being used already) in NuttX:

[vxj9800]

As per my knowledge, Nuttx already supports multicore processing on RP2040. However, I have not tested it along with PX4. But, if everything is in working condition then it should be as simple as adding two lines to the Nuttx config file. Take a look at it here.

[vxj9800]

Thanks for the update! I've looked at your schematic, and came up with some questions. If you could help me out with those, I would better understand the space and come up with some designs.

• Do you use SBUS, is it supported?
• Is it possible to do more than 4 PWM out channels? (probably instead of buzzer, leds, cts/rts, arm pb)
• Is dshot supported on outputs?
• Why do you use external flash? Is 2MB built-in not enough?
• Can the second spi be used to connect more imus/sensors?
• Are there any limitations on SPI IMUs we can use?

@nrodichenko

• Do you use SBUS, is it supported?
  • As per my knowledge, SBUS uses UART port. In my design, both of the UARTS are utilized, one for GPS and the other for telemetry. So, if you go with @coderkalyan's design then there is a possibility to add SBUS as well. It can be done through software UART, but that will affect the computational performance.
• Is it possible to do more than 4 PWM out channels? (probably instead of buzzer, leds, cts/rts, arm pb)
  • Yes, this should be very straight forward. RP2040 has 16 independent PWM outputs. So, if you let go of some of the pin functions then you can add more PWM outputs.
• Is dshot supported on outputs?
  • Not yet. It is programmatically much more challenging as compared to oneShot. But, firmware support can be developed in the future.
• Why do you use external flash? Is 2MB built-in not enough?
  • Correction, RP2040 doesn't have an onboard flash. It only supports external QSPI flash up to 16MB.
• Can the second spi be used to connect more imus/sensors?
  • Yes, more sensors can definitely be connected to the second SPI. However, adding more devices on single SPI port means increased latency for the each device. So, this is more of a design choice.
• Are there any limitations on SPI IMUs we can use?
  • If you don't want to deal with developing firmware for an IMU then here is the list of supported IMUs by PX4. Otherwise, there should not be any limitation.

[coderkalyan]

As per my knowledge, SBUS uses UART port.

Yes. SBUS uses an inverted UART data line.

In my design, both of the UARTS are utilized, one for GPS and the other for telemetry. So, if you go with @coderkalyan's design then there is a possibility to add SBUS as well. It can be done through software UART, but that will affect the computational performance.

I've been thinking about this some more. Here's the list of things that would ideally use a UART:

• GPS
• Telemetry
• IO processor communication
• SBUS
• Debug

We have 2 hardware UARTs, and a USB controller. USB is currently being used as a debug shell, but it doesn't really need to be. I don't particularly like this idea but if necessary, the USB can be repurposed as a telemetry line with a USB-UART converter module on the other end. If implemented correctly, the RP2040 PIO module can act as a third UART with no/minimal CPU overhead compared to a native UART. Currently I'm thinking GPS and telemetry on UART 0 and 1, IO processor on PIO, and Debug on USB, but this might be swapped around. Then SBUS would be implemented on the IO processor.

Another key thing to note is that sbus only requires a UART RX line, not TX. If software allows, the TX line could be used for something else. If planned out correctly, this might help.

Additional reason to use PIO for the io processor is that I care less about it, I have 4 fmu PWM outputs that will be the primary use. IO will just be a bonus for sbus, ppm, and more PWM. And anything else the io processor has firmware to do.

@vxj9800 do you have any other thoughts?

Not yet. It is programmatically much more challenging as compared to oneShot. But, firmware support can be developed in the future.

Doesn't PX4 have a dshot driver? Does it require a hardware port or something else to be written that I'm not aware of?

[vxj9800]

@coderkalyan I haven't looked at your complete design. However, I would set up things as follows. FMU-IOProcessor : UART0 FMU, UART0 IOProcessor GPS : UART1 IOProcessor, I'm not sure if there are any issues associated with this. Telemetry : UART1 FMU SBUS : PIO, since it needs only the RX line, of either FMU or IOProcessor. The code implementation will be easier as compared to doing UART with RX and TX both. Debug : USB FMU

Doesn't PX4 have a dshot driver? Does it require a hardware port or something else to be written that I'm not aware of?

For oneShot, the output is a pulse of specific time width. Thus, you can use a hardware timer and it's done. Since DSHOT is a digital interface, the GPIO output needs to be controlled very accurately and the PX4 DSHOT driver is one part of the equation. The low level code to control GPIO output accurately needs to be developed, here is an implementation for STM32. A similar code needs to be developed for RP2040. I think it would be easier to do using PIOs. Moreover, current PX4 support for RP2040 doesn't have DMA activated. I would like to work on DMA first before thinking about adding more to the communication.