CubeOrange potentially bricked after reverting Cube ID upload

Hardware Vendors CubePilot/ProfiCNC/HEX
, , , ,
1

The problem
I setup a cubeorange to work with the UART version of the Cube ID remote id module last week, but realized this week that it may not work properly with dronekit code which I needed to test later this week. Due to this realization, I tried to undo the Cube ID setup, causing the cubeorange module to become unresponsive to uploads in both qgroundcontrol, mission planner, and with the python uploader tool.

The setup
To setup the cubeorange for the Cube ID ODID firmware, I used the following page/video, and performed the following steps, based on my understanding of the instructions, which I admit is probably incorrect.

  1. I plugged in the Cube ID module into the gps2 port of my cubeorange board, with the serial4 settings configured for mavlink2
  2. I cloned a new ardupilot copy to my home directory, $git clone --recurse-submodules GitHub - Nick-Kakavitsas/ardupilot: ArduPlane, ArduCopter, ArduRover, ArduSub source
  3. Per the video, I did the following:
    • Using the CubeOrange-ODID hwdef folder under ~/ardupilot/libraries/AP_HAL_ChibiOS/hwdef/CubeOrange-ODID, and ensuring that all of the options were configured properly (including the APJ_BOARD_ID 10140), I built the firmware and uploaded it to my board.
    • I built the bootloader using (from my ardupilot directory)
      • $ Tools/scripts/build_bootloaders.py CubeOrange-ODID
    • I configured the files (?) with waf:
      • $ ./waf configure copter --board CubeOrange-ODID
    • I tried the regular upload, to ensure that (per the video) it would fail
      • ./waf --upload
    • I ran the upload python tool with the force command, from my ardupilot directory
      • Tools/scripts/uploader.py --force build/CubeOrange-ODID/bin/arducopter.apj
  4. After this, I was able to configure the output of the module in mission planner, and it seemed to be working, after setting the proper parameters

I then realized that I probably wouldn’t be able to use my dronekit setup for testing later in the week, and so I wanted to undo these steps. I should have tested the dronekit setup prior to doing this, but unfortunately, that didn’t happen. My attempts at reversing these steps are as follows:

  1. Using the CubeOrange-ODID hwdef folder under ~/ardupilot/libraries/AP_HAL_ChibiOS/hwdef/CubeOrange, I built what I thought would be the default cubeorange firmware and uploaded it to my board.
  2. I built the bootloader from my ardupilot directory
    • $ Tools/scripts/build_bootloaders.py CubeOrange
  3. I configured the files (?) with waf:
    • $ ./waf configure copter --board CubeOrange-ODID
  4. I ran the force upload command
    • Tools/scripts/uploader.py --force build/CubeOrange/bin/arducopter.apj

After this, my mavlink usb com port stopped responding, and the device looks like this on windows device manager:
image

I’ve tried to fix this by reinstalling mission planner, clearing the drivers, then reconnecting the usb to my computer and trying to connect to the cubeorange in mission planner, but that didn’t seem to work. I can get the bootloader to recognize in the install firmware page of mission planner, but the mavlink connection times out whenever I try to connect on this page.

I’ve also tried to force upload the same ODID firmware, built in the same way, with the board id set to 140, instead of 10140, but that was not successful either.

Whenever trying to force the default, or any other version of the ODID firmware without a hardware id of 10140 to the board using the uploader I get the following errors:

image
image736×75 15.7 KB

I’ve tried force pushing plane firmware to the board to clear all of the parameters and restart, but that didn’t work either.

Currently
While typing this to get notes for this post, I tried the following, which seems to have gotten me back to the point I was at after initially installing the ODID firmware:

  1. Create a folder in the sd card on the cubeorange called “etc”
  2. Add a text file called “extras.txt”
  3. add the line “mavlink start -d /dev/ttyACM0”
  4. Re-insert it into the cube, re-install mission planner and refresh the drivers
  5. Force push the ODID firmware, using the same steps above

Now I can connect to the quad per usual, but I can’t upload any other firmware at all. In qgroundcontrol, I don’t have the option to select a firmware, probably due to the board id being 10140:

image
image1920×479 59.9 KB

How can I fix this issue of the board id being 10140, assuming that I will comply with remote id in another way?

Thanks in advance for any assistance, and apologies for the long post.

2

10140 is the odid firmware

and you have a odid bootloader installed as well.

depending on the source of how the bootloader got on it, you might/might not be able to restore it to a standard cubeorange, as odid is designed to be tamper proof, if implemented properly.

to revert

compile a cubeorange-odid with the older bootloader embeded
connect, and update the bootloader - ie downgrade the bootloader.
reboot
And its back as a cube orange.

this all asumes you have all the keys etc to do this.

3

Thanks for your quick reply. I’ll give this a shot when I get a chance next week. We did the testing today with another quad, so this wasn’t as big of an immediate issue, but it would be really nice to revert the bootloader.

Out of curiosity, I’m not 100% clear what you mean by having the keys. Do I need to have some additional permissions or do you just mean admin privilege’s for the computer on which I’d be configuring the FC?

Thanks!

4

I think Michael means, that if you installed the bootloader and did not add signing or added signing but have the keys, then it is ok.
But if it is signed and you don’t have the keys, then it won’t work.