Hi,
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.
Thanks for the feedback. To reduce the memory usage I tried again, but disabled the OSD and also added
define HAL_MINIMIZE_FEATURES 1
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.
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!
