Unbricked! Here's some context/advice for anyone trying to do the same. If you purchased a cheapo STLINK V2 from Amazon as I did. Picture below... [image: 61TfQhFysAL._AC_SX679_.jpg] $0 Fix: What may very well happen to ya, is the RESET pin doesn't work. In this case you will need a friend. With said friend, you must dilligently connect to the board using Under Reset Mode and Hardware Reset. The second your homie clicks the connect button, you, the bricker of the board must move your jumper cable from the RESET pin which is 3.3V to an open Ground, leave it for exactly 1 second, then move it back to RESET. This should work like a charm, but may require one or two tries to get the right timing. See instructions below. [image: raiders.jpg] $10 Fix: Program a Pico/Arduino to do your 1 second ground for you. $78 Fix: Buy the real STLINK V2.

Hi @Jerry-Fuller - you need to update the most recent iteration of QGC where the changes have been made to actually upload/get the system out of bootloader mode. I would recommend downloading the most recent daily build of QGC and seeing if that helps flash the device.

@maxwelllwang Sorry here is a working link to the log. https://review.px4.io/plot_app?log=270f405a-88bd-4ba7-a4d2-a4eb3258e18d

Please follow the safety guidelines before running any mission: https://modalai.com/safety The failsafe is configured in PX4 via QGC. We do not set that explicitly as that before is up to you how to configure. Please review the PX4 failsafe documentation and understand how it behaves, and then test in safe conditions, before flying again https://docs.px4.io/main/en/config/safety.html These are drones for developers, and are highly configurable. Please take precaution and test each function before making any assumptions about behavior.

I have discovered that the entire module seems to stop. I had been assuming it was the UART that was failing. Is there some PX4 setting where when a telemetry link occurs that something would stop/pause running modules?

Hey the answer is yes. I use DroneBridge for ESP32 but I believe there's a ton of other similar mavlink apps for ESPs. cheers

Originally the FW update via QGC worked, and ideally that would be the way it works, but at some point the update stopped working (note that our bootloader didn't change). The px_uploader tool to me uses the same protocol as QGC, and as this works, I have a hunch the issue will be QGC side, but the jury is still out while we track it down. I decided to proceed to ship Flight Core v2 as I found the work around acceptable and had the work around publicly documented. I agree that our product line is still a bit bent towards power users at this point, so the use of git and such is a big ask for most people. If you have the chance, with respect to this topic in particular on this thread, please let me know where you got stuck with this particular process with our documentation and then I can use that feedback to improve things. https://docs.modalai.com/flight-core-v2-firmware/#how-to-upgrade-using-px_uploader-tool

Hi @billybob I just stumbled upon this thread. Thanks for contributing to this forum!! If you need us to respond to anything or have any questions, the best bet is always a new thread. We get alerted (the entire company) on new threads, but not so for thread responses or "tack-on" thread posts. Just an FYI I've been updating that cables section recently (still have more to do!!!) and we are finding and posting workaround solutions for various Mavlink ports when someone's port breaks or they wish to change for mechanical reasons. I'm happy to see you found some of my notes. We are working to improve that too, especially since the older 5V on Voxl J12 is problematic on some new stuff, so I want to be sure everyone has all the info they need!!

I verified the UART is working fine using the loopback method, at a few different baud rates. I think the issue is the sensor itself must be encoding the packets differently than I am reading them. I might need to reduce the baud rate down to 9600 and review the data on the oscilloscope. The Arduino's SoftwareSerial library didn't work properly until I inverted the input, but I didn't see that option for the linux UART.

I am connecting my RFD 900+ to the J5 connector on the Flight Core. The radio is configured for 57,600 baud. I don't have any experience setting mavlink "modes." This is an underwater vehicle, so I only communicate with it on the bench. My hope is to not have to open up the pressure vessel to pull off the data logs, which is our current method.

Hi @tangotoo , If you have a DMM handy, can you confirm you get a high resistance reading between the PWM output pins and DGND on J7 with the PCB powered OFF and disconnected from the ESCs? Pin 10 is DGND. For example, if you measure DCR on Pin-2 to GND (pin-10), you should get ~200-300KOhm. And for Pins 3-9 as well. If any of those are much lower, then that implies an ESD or overvoltage event might have damaged the pins from the STM MCU or the ESD protection devices we have creating an internal short in the MCU or on the ESD diodes on those specific bad channels. If all the readings are in that high value range for all 8 PWMS, then our SW team will have to jump in to help. Thanks!

@Vinny Thanks for more clarifications. I was comparing: https://github.com/PX4/PX4-Autopilot/blob/main/boards/holybro/pix32v5/src/board_config.h and https://github.com/PX4/PX4-Autopilot/blob/main/boards/modalai/fc-v2/src/board_config.h table comparing the hardware features I will appreciate if you can share. The Modalai flight core is tiny compared to pixhawk5x, I wanted to mix and match flight core with voxl(which is essentially snapdragon) or Nvidia Jetson processors for drones or robot. Thanks. suvasis

Have you asked in the px4.slack.com Slack channel? All of the developers are there and there is tons of good support. They would probably have better recommendations on how to add the driver properly than we would.

Flight Core does not have an internal magnetometer (compass) so there's no need!

@Zeev-Mindali Checkout your options here: https://www.modalai.com/pages/rma

Yes, this "can" work, but it is not ideal due to the many unknown variables on someone's host PC. Hence it is not a default option, and we would not recommend it. Issues can range from USB VBUS being out of spec (as it is, it is allowed +/- 10% which puts it in on the edge of our needs), and most "correctly designed" PCs will not provide more than 100mA unless a device is enumerated that asks for more. I'm not sure if all version of PX4 do that correctly. 100mA is insufficient for most use cases. In a strictly "QGC config" mode, I can see this work, but it is not something we plan on supporting on this version board due to those risks above. This also opens the door for someone to leave that power feed in-place while then later connecting the power module which will create a serious power rail shorting problem between the module and the PC. However, we do have a design already figured out that can take USB power for QGC/Config type of applications, and it validates the VBUS through a smart fuse/mux before using it. This will allows us to globally claim support, and if someone's system is not correct or out of range, we protect the HW. Stay tuned!

Hi @Jimk_Aero , Sorry to hear about the problems. Not being able to power off USB does make this hard and is a carry over from the VOXL Flight.... Even without ESC calibration, you can manually attempt to spin a motor, if using PWM, via this: https://dev.px4.io/master/en/middleware/modules_command.html#pwm Do you have an oscilliscope? You could probe the PWM channel output pretty easy (pins 2-5 for a quad) and see if you see any signal coming out of the board. If there's no signal, when you expect it, on a single channel, try to look at those ESD diodes right next to the connector and check for any fried parts. PX4 FW version you are running? There are two programs to handle some edge cases, px4-esc-cal-tool-v1-11.py and px4-esc-cal-tool.py