I’m using the CAN bus to output some information to another microcontroller offboard being used for testing (specifically, getting info over CAN about the GPS state). I was able to get it working and am successfully reading the expected CAN messages. However, when I power off the Pixhawk (2.4.6 2MB hardware on 4.4.0 Arducopter), CAN is no longer working when I power it back on sometime later. To get it working again, I have to change CAN_P1_DRIVER to 0, reboot, change CAN_P1_DRIVER to 1, and then reboot again. At that point, CAN is working properly.
This may not be the only way to get it working, but it’s the only way I’ve found so far.
Additional information: if looks like if I repeat the steps above, but with CAN_D1_PROTOCOL, CAN comes back as well. Maybe it will work if I change any of the CAN settings that are available. I’ll try some others and see.
I changed CAN_P1_BITRATE (from 500000 to 1000000), and upon reboot, CAN was up again (just at the wrong bitrate of course).
So it’s something about performing a powered reboot after changing a CAN parameter that causes CAN to be functional. I’m not well versed in the boot up sequence of a Pixhawk. I’m hoping someone here can shed some light on what may be going on. If you need more information, please let me know and I’ll be glad to collect whatever is needed to debug this. Much appreciation in advance!
I realized that it wasn’t the fact that I was changing some CAN parameter. It was just that I was rebooting it at all. The bootup sequence from the battery pack ends up bringing the 5 volt rail to the Pixhawk up slowly (due to charging of capacitance - it’s intentional). It is probably messing with the bootup sequence of the Pixhawk. I played around with the BRD_BOOT_DELAY as you suggested - although found for my situation, I had to go higher than 3000 ms. I tried 1500, 3000, and then just went to the max allowed of 10000. Only when I tried 10000 did it work. I didn’t attempt other values after that. I have some things I can do with the power rail to bring it up faster which may solve the problem.
But thank you very much for taking the time to offer a suggestion (a very good one!)
I haven’t heard of any case where more than 5000 is required. But the delay parameter is there specifically to allow peripherals to initialize before trying to talk to them. If AP starts querying first, situations like yours can happen.