Wpilib or external Hal error can not initialized when deploying code

Starting today every time we deploy code we get the following error message which occurs about 3-4 times, after which our code works. This adds about a minute to our deploy time. After the code starts for the first time, it continues to work and boot in a normal amount of time, even after restarting/rebooting the Rio. Looking up this error message it appears it’s related to declaeing a can device multiple times, but we only declare devices in a singleton file. As well, the issue clears up after a bit of time and then works normally. Any ideas what is causing this, it’s significantly slowing our development time.
https://imgur.com/a/nNqhBBT

Can you post your code/Github?

1 Like

https://github.com/FRC3683/Robinson/tree/allSubsystems

It says page not found. Is your repo public?

Sorry our repo is private and we’re not able to share it until after the season. If there’s any specific parts of the code you need let me know and I can paste it in the thread. Thanks.

Just wherever you are making the CAN objects. It is a lot harder to help when we can’t see your code.

Have you made sure all your firmware is updated?

It looks like the robot program isn’t shutting down properly or quickly enough; the deployment process kills the previous user program and then the robot program does a more forceful kill, but it appears neither complete in time to free up the CAN resource. Do you have your own custom threads? Custom RT priority settings? Updating to the latest vendor libraries may also help.

If you aren’t using threads or RT priorities, the fault may not be in your code. Several teams have reported similar issues this year and we’ve not isolated the cause yet (so we’re looking at other workarounds for next year). What vendor libraries are you using? Several vendor libraries have background threads and it’s possible one of those is causing the issue, so datapoints help.

The good news is this will never happen on a cold start / reboot of the RIO, only on deploy.

Thanks for the info. We’re not using any threads, and only have the navx, rev and ctre vendor reps.

So I managed to figure this out today. I recently added a pi pico connected to a rev colour sensor which was sending serial comms to the Rios USB port. This is what was keeping the code running after deploy, and after disabling the serial comms from it and using digital IO to read it’s output, the problem was resolved.

There is a thread in that code, assuming you’re using what @Thad_House put together. Is that what you were using?

Custom, but based off of their code on the pico side. On the Rio side I wrote my own driver that just read DIO from the pico.