First of all a big thank you to all the developers from Ardupilot!
After updating my slightly modified SPARKY2 board to Copter 4.0.0 I only see a single initialization UAVCAN message, and then CAN communication stops. It does not react on a uavcan.protocol.GetNodeInfo message (send from the Zubax Babel CAN dongle which I connected to the flight controller UAVCAN bus 1) In case I connect the ESCs there is also no communication with the ESCs.
With Copter 3.6.11 the UAVCAN is fully functional (same settings). In case ESCs are connected there was also communication with the ESCs and I did some flying without issues.
Please find the UAVCAN settings, sniffer data and hwdef.dat in the attachment. (I disconnected the ESCs from the UAVCAN bus to be sure they are not disturbing)
Could anyone please help me with this? Am I overlooking something? Or is there a bug in the Copter 4.0.0 code? hwdef.dat.txt
HAL_MINIMIZE_FEATURES was added to the hwdef as this board doesn’t have enough flash space for the full firmware.
I suspect that is the cause.
I thought that UAVCAN was included in the minimize-features though. I’ve added this to our Copter-4.0 issues list so it won’t be forgotten. Hopefully we can find a developer with the board so we can reproduce the issue.
Txs for the report!
Thank you for your quick responses!
As far as I can trace it back in the code UAVCAN should still be included even with HAL_MINIMIZE_FEATURES turned-on. But I am not a C++ expert so I cannot rule out that I overlooked something.
Thank you for adding this to the Copter-4.0 issues list.
I just retried it with Arducopter 4.0.1
Unforturnately with exactly the same results as with 4.0.0 (as described i my initial post)
It also seems to be that there is no relation with the HAL_MINIMIZE_FEATURES option, since i managed to compile without HAL_MINIMIZE_FEATURES (by disabling other IO in the hwdef file).
But this gave the same result.
Thanks for checking Copter-4.0.1. I’m afraid the issue is still on the Copter-4.0 issues list under the, “Regressions from 3.6.x”. So we haven’t forgotten about it we just haven’t gotten to it yet. Sorry for the delay.
Please supply specific git hash that was working.
The git hash of Copter 3.6.11 that was working is: f0d5929408599b453da2d04ff886699dbf03a5a8
Try to Disable CAN1 as that board only has CAN2.
CAN_P1_DRIVER = 0
I have a Pixhawk V1 and ZUBAX GNSS and upon upgrading to 4.0.3 the mag is no longer detected. Is there something I’m missing or is that a bug ?
Was working fine on 3.6.7
I finally found the solution…6 months later. I even designed a new flight controller based on the STM32F7 (my first HW design was based on sparky2/STM32F405 with 1M of flash), since i initially thought that it might have to do with the HAL_MINIMIZED_FEATURES setting.
After all it turned out that the following setting in the sparky2 hwdef.dat setting needs to be done:
define HAL_STORAGE_SIZE 15360 as it is default in the sparky2 hwdef.dat
needs to become:
define HAL_STORAGE_SIZE 16384
You have to be careful with that, I had a similar problem (Omnibusf4v6 UC: Failed to add Node 10) and thought I could solve it that way. Problem is the way the StorageManager uses the memory which prevents you from using the full 16KB sector, I also explained it in that post.
What I have tried in the meantime and seems to work on the bench (want to fly it in the next week or two) is to modify the layout in StorageManager.cpp. A big chunk of memory is allocated for OSD parameters which I don’t use so I used this area for StorageCANDNA. After re-building the firmware and flashing it to my modified Omnibusf4v6 UAVCAN has been working like a charm.