Omnibusf4v6 UC: Failed to add Node 10

I am trying to add CAN bus support to my Omnibusf4v6. So what I have done was to modify the original hwdef file by reassigning the I2C pins to CAN pins. Then I build the latest copter firmware (4.0.4) and flashed the board. Next I wired up a SN65HVD230 transceiver module to the CAN pins. In the parameters I set the CAN_P1_DRIVER to 1 and also selected GPS2 type as UAVCAN.

To test my setup I build the f103-gps AP_Periph node, flashed it to a bluepill board and hooked up an old GPS I had laying around. On the bluepill I also added a SN65HVD230 transceiver. I tested this node with the UAVCAN GUI tool (using a SLCAN adapter not MP) and it seems to work fine. The dynamic id allocations works and I can see the node with operational status and adjust the parameters (changed node id to 20).

So then I hooked up the node to the flight controller to try it out. But it does not detect the GPS and I keep getting a “PreArm: UC: Failed to add Node 10!” messages. Even if I remove my node I still get these messages. Node 10 is suppose to be the copter’s id, so it seems to have trouble adding itself… Glancing at the code it seems this message is generated in AP_UAVCAN_DNA_Server.cpp, but I can’t yet figure out why.
It looks like the CAN interface on the board works, kind of, since when I use the SLCAN tool in Mission Planner I can see my node. Although it does not appear to be fully initialised as it does not show the node name (which it does in the UAVCAN GUI tool).
I can also not view the parameters.

Somewhere on gitter I read of somebody with a Sparky2 (also a F405 board) having a similar issue (failed to add node) and he was of the opinion that it could be a bug with F405 boards…

Does anybody have any ideas of what I can try to solve this?

The problem with the F405 is lack of memory, the way the storage is written boards with larger memory size can assign CANDNA
I think @bugobliterator @tridge would be better able to answer.
Which is one of the reasons I have been looking at adding the F413 with 1.5mb of memory. Same size footprint or smaller, the down side is maximum of 96mhz. I have a board on its way to test.


1 Like

Thanks for the feedback. To reduce the memory usage I tried again, but disabled the OSD and also added


to my hwdef file (EKF2 is also disabled). This gives:

But still getting the “Failed to add node 10” message…

The F413 sounds like an interesting option, any reason for not just jumping to the F427 (small difference in price)? Or is the smaller footprint that critical for your project?

Reducing the size of the build by adding “minimize features” will not have any effect, its the physical size of the memory on the CPU. Number of pages.
It is smaller footprint i’m looking for coupled with CAN for sub 250g machines. 1.5Mb will let me run full ardupilot with no limitations on a very small footprint.


It works! You were spot on with CANDNA

There one can see that CANDNA requires more memory to be allocated by the StorageManager than the current hwdef file allows. In the hwdef file I copied from omnibusf4v6 15360 bytes were allocated so I added an additional 1024 bytes and made it:

define HAL_STORAGE_SIZE 16384

Then rebuild and flashed and now the “failed to add node” message is gone and my omnibus can see my UAVCAN GPS node! Very exciting stuff and I learned a bit more about the Ardupilot code!

I guess this is a proper fix since I disabled the OSD and can therefore easily afford the extra 1k given to the StorageManager (which in the case of the omnibus also uses the MCU’s flash memory)? If I am lucky it might even also work with the OSD enabled.

This is not a proper fix and while bench testing is ok do not fly with it like this as I don’t know what would happen if it tries to use memory that doesn’t exist.
Again do not fly with it set like that.

Okay, I think I am starting to see the problem:
Looking at the STM32F405 memory layout, the first 4 sectors are all 16KB. The first 16KB is where the bootloader sits and the following two 16KB sectors are used by the StorageManager (when using the MCU flash memory).
Problem is that when writing to flash it first needs to perform a complete erase and the minimum erase size is the complete sector. So when writing to this memory the StorageManager needs to copy back and forth between these sectors and effectively we can only use 1 sector worth of memory, 16KB.
Then there is a second catch, we can’t use the full sector since the StorageManager needs some space to do it’s thing. This leaves me with pretty much the maximum 15360 bytes given in the original omnibusf4v6 hwdef file.

Like you said, better to keep this board on the ground then. In the meantime I can at least test my AP_Periph nodes on the bench.

So I guess my options to get it safely working are:

  • Try to use the SPI Flash chip (WINBOND 25Q128) on the omnibus for storage.
  • Modify the storage layout, maybe reduce the number of waypoints to try and win some space for candna.
  • Use the 2 last sectors for storage which is not really an option since these are 128KB sectors so I would be paying 256KB on an already memory constrained MCU.
  • Any other ideas?

How will you handle this problem on your F413 board?

I will handle it the same way the larger boards with 2mb of flash do… i need to check with the Devs on here but i believe this will solve my issue.
The F413 has 1.5mb… Failing that i was going to try and use sd card for parameters and use the extra space left over for CANDNA…
Unfortunately i’m not a programmer but have learnt a lot from making my own boards, which is just for hobby use.

I guess with the extra memory you can afford to use the last two sectors on your board.

Same here, just doing this for fun and trying to learn more about ArduPilot and UAVCAN.
If I find anything interesting I will keep you posted, thanks for your help so far!

1 Like

This PR should fix it properly:

1 Like