3DR Solo failing to update firmware

Joined
May 11, 2017
Messages
11
Reaction score
3
Age
44
Hi guys,

I'm facing really odd problem with one of my Solos and I hope that you can guide me in a right direction to solve it.

It's almost brand new, flew only one time without any crashes. Then all of a sudden - it could not boot anymore. Right after the start it was beeping - two short, two long and all green solid lights on motor ESCs(reboot is not helping).

And the worst thing - it's failing to flash any firmware(in the end of procedure of flashing - two long beeps). For example - I can do factory reset, but then I'm to able to flash anything newer(and I'm still not sure that factory reset is finising in a right way).

Tried with putting firmware to /firmware folder via WinSCP and with loading custom firmware via Mission Planner. File itself dissapears from /firmware and appearing in /firmware/loaded , but it's not updating firmware itself.

My latest success - I was able to update firmware with Solo APP(before that - it was always in "Looking for Solo" state) and looks like it's still corrupted(solid green lights, three short and two long beeps at start) - controller saying "waiting for Solo", but it gives SSH connection(so they are paired).

I still can't upload any firmware(in attached 3dr-solo.log you will see my attept to upload pre-release 1.5.3).

And "3dr_solo local1.err pix: not detected at any baud" line from 3dr-solo.log gives me a feeling that my problem could be really serious.

I hope that I provide every critical informating for you to determine possible problem.

And I cannot get it to service - I'm in Ukraine, so it could really be difficult)
 

Attachments

  • 3dr-solo.zip
    1.9 KB · Views: 28
Wow, That's so strange, can you check the SD card and reseat it?
 
When using a new known working SD card (from your other Solo), did you do a factory reset, then follow the normal process of paring and updating Solo and the Controller to revert back to stock fw?
Note: Recommend to make a backup the image of the known working Solo SD card before inserting it to another Solo to perform a reset.

I had similar issues as you are describing. What worked for me was to perform a factory reset to stock fw. Once that's all done, then I proceed to update the firmware to 1.5.3. Give this another try and report back your status.

Note: The ArduCopter-v2.px4 fw that you uploaded to the Solo's /firmware folder, is moved to the /firmware/loaded after the upgrade is completed, is normal.
 
Yeap... I've tried it with same bad luck. Also tried with complete main board from working Solo...

And looks like it's failing in earlier state - for example in LOG folder there are only two files 3dr-solo.log with almost no info and empty 3dr-wifi.log. Same with updating via Mission Planner or via /firmware folder.

Most "working" variant(at least with whole bunch of log files) is to update via Solo APP.

PS I know that movement of firmware file is normal. My problem - file is moving, but firmware is not updating...
 
Ok, if fw is not updating....Try this.

Open up the Solo again, and carefully flip the motherboard (solo mainboard) up to around 40 degrees so you can access to the Solo Cube. On one of the sides of the Solo Cube, there is a USB connector. Connect the USB cable (normal to micro) from the PC to the Cube and run MP. See if you can connect to the Solo Cube via standard serial connection (115200 baud). If you can, you can upload custom fw (I would use 1.5.3) from MP and wait for the upgrade to complete by listening for the ET tones.
 
btw. You can not just copy fw files from one SD card to another. This process will not work since the file systems are different on the Solo and your PC. You need to take an image of the working SD card and burn that image to a new SD card.
 
Ok, if fw is not updating....Try this.

Open up the Solo again, and carefully flip the motherboard (solo mainboard) up to around 40 degrees so you can access to the Solo Cube. On one of the sides of the Solo Cube, there is a USB connector. Connect the USB cable (normal to micro) from the PC to the Cube and run MP. See if you can connect to the Solo Cube via standard serial connection (115200 baud). If you can, you can upload custom fw (I would use 1.5.3) from MP and wait for the upgrade to complete by listening for the ET tones.

Also did that several times... Connecting without any problems(bootloader up and running, listening to heartbeat etc), erasing old fw, uploading new one, listening for all of the beepings to finish, but... Then it is just the same story...
 
  • Like
Reactions: Sargemo
I also got a feeling that my cube is dieing, but as an engineer I don't believe in that kind of sudden death without any reason.

Another thing is bothering me, is that main problem of cube not updating firmware - problem of getting heartbeat at any baud. And it's not problem at all when I'm doing it via MP.

I can even flash master ardupilot, but it's not working in another various kind of reasons...
 
And thanks for the link, but I already got another two spare Solos... Just wondering if there is a reason to get that one working or at least - find a reason of this failure...
 
Well, we know the bootloader is working and communicating with the host, MP, to receive fw update. The bootloader fw is different then the application fw, ArduCopter.

The heartbeat or anybaud not received is through Mavlink protocol (please correct if I am wrong). This requires that the application fw or AudruCopter is running. In your case, ArduCopter is not running hence no communication.

The following lines in the log file got my attention:
May 14 03:39:20 3dr_solo local1.info pix: loading /firmware/ArduCopter-v2.px4
May 14 03:39:55 3dr_solo local1.info pix: firmware loaded in 35.106 sec // ArduCopter is loaded
May 14 03:40:41 3dr_solo local1.err pix: timeout waiting for heartbeat after loading // Something went wrong
May 14 03:40:43 3dr_solo local1.warn pix: no version hashes received // (hw com issues or ArduCopter arborted?)
May 14 03:41:15 3dr_solo local1.warn pix: no build version received
May 14 03:41:15 3dr_solo local1.info pix: now running:
May 14 03:41:15 3dr_solo local1.info pix: build_version unknown
May 14 03:41:15 3dr_solo local1.info pix: ardupilot_git_hash unknown
May 14 03:41:15 3dr_solo local1.info pix: px4_git_hash unknown
May 14 03:41:15 3dr_solo local1.info pix: nuttx_git_hash unknown
May 14 03:41:15 3dr_solo local1.info pix: pixhawk.py finished

When I have time over the weekend, I will try to replicate your issues: Green lights on all four LEDs, 2 short and 2 long beeps.
 
If it's working via Mission Planner - then MavLink is working.
But this part of the log saying that it's not able to find anything:

May 14 03:39:02 3dr_solo local1.info pix: pixhawk.py starting
May 14 03:39:02 3dr_solo local1.info pix: checking baud...
May 14 03:39:05 3dr_solo local1.info pix: not at 921600
May 14 03:39:07 3dr_solo local1.info pix: not at 921600 // This is a right baud, and there is nothing.
May 14 03:39:10 3dr_solo local1.info pix: not at 115200
May 14 03:39:12 3dr_solo local1.info pix: not at 57600
May 14 03:39:15 3dr_solo local1.info pix: not at 230400
May 14 03:39:17 3dr_solo local1.info pix: not at 460800
May 14 03:39:20 3dr_solo local1.info pix: not at 1500000
May 14 03:39:20 3dr_solo local1.err pix: not detected at any baud // And this looks like a main problem to me
 
If it's working via Mission Planner - then MavLink is working.
But this part of the log saying that it's not able to find anything:

May 14 03:39:02 3dr_solo local1.info pix: pixhawk.py starting
May 14 03:39:02 3dr_solo local1.info pix: checking baud...
May 14 03:39:05 3dr_solo local1.info pix: not at 921600
May 14 03:39:07 3dr_solo local1.info pix: not at 921600 // This is a right baud, and there is nothing.
May 14 03:39:10 3dr_solo local1.info pix: not at 115200
May 14 03:39:12 3dr_solo local1.info pix: not at 57600
May 14 03:39:15 3dr_solo local1.info pix: not at 230400
May 14 03:39:17 3dr_solo local1.info pix: not at 460800
May 14 03:39:20 3dr_solo local1.info pix: not at 1500000
May 14 03:39:20 3dr_solo local1.err pix: not detected at any baud // And this looks like a main problem to me
Well, there are two parts, the first part is bootloader communication. The 2nd part is Mavlink communication.
The logging is showing that Solo is not able to communicate through the serial interface at a particular baud, so maybe I am not using the right baud rate. Let me loop through the list of available baud rates and see if I hear anything. Apparently, it's not able too. This led me to believe that the on board serial interface (hw issue?) could be the problem.
 
The old Pixhawk 1.0 has a debug serial interface dedicated for this. I am wondering if the Cube (PixHawk 2) has the same thing via the break out board.
 
Telemetry info:
May 14 03:41:24 3dr_solo local1.info dl: df-tfc: connecting to telem-forwarder at 10.1.1.10:14560

btw....Another thought....Can you connect to MP via wifi @ 10.1.1.10 on port 14560? If you can, what's the telemetry/MP status/response (any voice)?

We might get lucky to get some info from Solo through MP via wifi instead of serial interface.
 
So, looking at the Architectural diagram. Pixhawk (ArduCopter is running on) can not communicate with SoloLink via the MAVLink serial interface.

1. To know if ArduCopter is running: Connect a USB cable directly to the Pixhawk via the USB interface with MP.
1.a. Is MP able to connect and communicate with ArduCopter via the USB cable interface?
1.a.b. If MP can connect and communicate then ArduCopter is alive and well
1.a.b Therefore, the serial interface to the SoloLink could be bad
1.a.c. else ArduCopter is not running. Something went wrong in memory.
 
Last edited:
Looks like this is the case...
Found in MP Logs:

Check BRD_TYPE: no l3gd20 found

So it's not able to find it's own gyro sensor, so I assume you are absolutely right about serial interface.

And I doubt we'll be able to find what happened)))

Thanks a lot for your time and effort!
 

Members online

No members online now.

Forum statistics

Threads
13,096
Messages
147,752
Members
16,067
Latest member
Minh44