PX4 FMU v2 no serial console at all

PX4 Autopilot Flight Controllers šŸ’»
1

Hi, Im a newbie to FMUs but a fairly experienced electronics engineer (not st devices though).

so, i have aquired a possibly faulty drone to play with, Chitwan QW350. Correction, it IS faulty, but hoping the hardware is all ok.

It uses a PX4 FMU v2 (Manufacturer is i believe GUBA), STM32F407 which seems standard.

I have loaded bootloaders seemingly successfully (i may be corrected on this) , latest being ā€œpx4fmuv2_bl.binā€ GC seems happy loading firmware too, have tried few different versions and frames.

I cant get any kind of console through any port on the board, i dont know anything much about the px4 firmware and bootloaders.

The board is on its own, no other boards or modules connected, just the fmu and power (is this the issue?)
When you power the board (usb or external) the red light is solid (power light i think), a blue light flashes at 4Hzish for 7seconds then off (red light still on). While blue led is flashing computer recognises it as a PX4_FMU_v2 and i can connect to the port albeit nothing sent out of the port, when led stops flashing the serial interface (CP210x i think) dissapears.

while in firmware update on gc ,before flashing, the port will stay open.

Should there be a console output from the bootloader under most conditions? (No SDCARD yet, before you tell me to look on there for logs as it is remote to the FMU and i have to repair the ribbon cable). Have probed all the ports, is there a command that it has to see on a port to open a console ?
If i can gain some sort of console or log then i should be able to get somewhere but i`m working blind at present. Just need a starting point.

GC and MP will not connect to it even during the 7 seconds while port is open, except to upload firmware.

Any help on this is greatly appreciated. Could be a fun little project.
Thanks.

2

I think the ā€˜standardā€™ processor is 427 than a 407, or just a typo?

3

@Andrew_Kirkham: How ā€œoldā€ is this drone of yours?

The original Px4FMU-v1 used an STM32F405. All of the subsequent Px4s (e.g. Pixhawk v1 and v2.1) use an STM32F427.

If you have an STM32F405 on your board, flashing the firmware for the Px4FMU-v2 (STM32F427) onto your board is going to result in something not working (not just the serial port). The bootloader that you flashed onto the board will work, because the USB registers on the F407 and F427 are the same, so you wonā€™t notice a difference.

I donā€™t suppose you know what firmware is ā€œusuallyā€ flashed onto your drone?

If your chip is actually an STM32F427, then your problem might be that the standard firmware for the FMU-v2 has the console on one of the UART ports and not the USB - you can change it to be no the USB, but you have to change a config file and recompile the firmware. This could be your problem. In the bootloader the USB port shows up on your computer, but as soon as the firmware jumps to the main application, then USB will disappear. If you have an FTDI cable you can connect it up to the console UART (unfortunately I donā€™t know which one that is off the top of my head), and you can then interact with the NSH shell.

I hope that helps.

4

Iā€™m not home but will check later, sure itā€™s a 407, if so then Iā€™ll look at datasheet see what differences.
Maybe memory map diff.
It is a bit of an odd board so poss right.

5

It came with V2 firmware but not to say itā€™s correct as the previous guy made a right mess.
Itā€™s Def a 4x7 device but Iā€™m doubting myself as to which one now, sure itā€™s 407 but Iā€™ll see later.
Googling does reveal a couple of pictures of this board mentioning V2.

But as I stated I have probed ALL serial interfaces on the chip, even looked with logic analyser for any activity, nothing.
I tried v1 bootloader but didnā€™t work either.
Have flashed via GC , and dfu, JTAG next maybe.
Tried diff block sizes as someone mentioned it being an issue.
Am I correct in assuming that if the light is flashing then something should be thrown out of a serial port somewhere? At what point of loading do you get something out?

6

Once the board has left the bootloader, (and provided the console is on the UART port), then you should start seeing ā€œbootā€ messages on the console port. Once the main firmware has fully booted it will give you access to the NSH shell on that UART console port.

7

Ah, so no op from bootloader then?
Not till main app starts loading.

If so itā€™s a shame, be easier with some verbosity.

8

The bootloader only starts talking once it has been spoken to by a computer. And unfortunately the bootloader only ā€œrespondsā€ to commands from the uploading program. There is no ā€œverboseā€ output. Also, the bootloader will only respond on the port it has been spoken to. If you start communicating with it on the USART, it will continue communicating on the UART. If it was spoken to on the USB, then it will only respond on the USB.

9

Thank you Ksschwabe for the help.
Thatā€™s what I needed to know, Iā€™ll dig deeper.

One more thing, I figure that even though there are no modules or even the io board plugged in I should get some kind of console. Or does it just throw itā€™s hands in the air and give up?

10

Yes, you should get a console, provided that the microcontroller hasnā€™t hardfaulted during startup for some reason. But even if it hardfaults, it should provide you with the stackdump on the console port. (Note: the stackdump only works on the UART console; it doesnā€™t work on the USB console, if configured).