When uploading code to the robot, we will constantly fail to flash the cortex and corrupt the files and ~every 5 uploads or so we get the ‘Slave CPU error’. We have to re-downloaded robotC firmware on both the computer and the cortex every time this happens and really slows us down. We primarily use a wireless programming cable to upload code, but the errors still happen even when the computer is directly plugged into the cortex. Does anyone have any idea how to reduce this?
Just to chime in, we had the same issue happen about 3 times in a 4 hour programming session this week. No problems doing it with Cortex direct to the laptop, but wireless would flake out every so often. Only twice did we have to reload the firmware, others just needed to upload again direct to the Cortex. A 6’ USB extension made it easier when we gave up on wireless.
I’m having similar issues with Vex Cortex firmware. Vex says use their firmware, but that gives me "cannot communicate with Vex Cortex Slave CPU, Master CPU communication is not working. I can reload the RobotC firmware and establish communication, but that seems to be only temporary. The Cortex doesn’t function consistently with RobotC firmware either. After reboot the Cortex will not power the I/O even when using the debugger window.
Is the main battery turned on? Digital and analog IO only works when the main battery is also used, powering using the USB cable is not enough.
We are having this same issue. We have tried multiple programming hardware kits. Is this a VEXnet problem or a Cortex problem? Has anyone found a solution?
Same issue happened to me 7 times last season.
Only seven? We’re lucky if we make it through a day with 7 slave cpu issues. Still no fixes – only now about half the time the SlaveCPU shows up it goes to MasterCPU when we try to re-download firmware. We just use a different computer, but as you can imagine it becomes quite a hassle when every other time you upload code you have to grab a second laptop, and quite stressful at tournaments. Does anyone have any solutions?
I had the exact same problem. We were using an array for motor remapping like the team on this thread.
https://vexforum.com/t/24cs-motor-control-value-remapping/23959/1
As soon as I took out the array we used for the remapping code all of the problems went away.
Are you using motor remapping code?
To note, as this reminded me of issues I have had before, some insane things I have attempted in the past have caused the same issue every time I downloaded code to the cortex. So see if the same issue occurs on a clean piece of code (with no imports etc).
We are indeed using motor-speed remapping. We will try removing it and see how it goes. Thanks for the suggestion!
Can someone send me a program that is having trouble downloading. I see no reason why a program with speed mapping would download differently from any other program, but perhaps there is some sort of obscure bug we don’t know about.
I assume people doing speed mapping would be using Jordan’s array, or something very much like it. So the code will have an initialized static array:
const unsigned int TrueSpeed[128] =
{
0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 21, 21, 21, 22, 22, 22, 23, 24, 24,
25, 25, 25, 25, 26, 27, 27, 28, 28, 28,
28, 29, 30, 30, 30, 31, 31, 32, 32, 32,
33, 33, 34, 34, 35, 35, 35, 36, 36, 37,
37, 37, 37, 38, 38, 39, 39, 39, 40, 40,
41, 41, 42, 42, 43, 44, 44, 45, 45, 46,
46, 47, 47, 48, 48, 49, 50, 50, 51, 52,
52, 53, 54, 55, 56, 57, 57, 58, 59, 60,
61, 62, 63, 64, 65, 66, 67, 67, 68, 70,
71, 72, 72, 73, 74, 76, 77, 78, 79, 79,
80, 81, 83, 84, 84, 86, 86, 87, 87, 88,
88, 89, 89, 90, 90,127,127,127
};
It’s not very large, so that’s not the issue (wouldn’t think so, at least) but I’m willing to bet that initilized lookup tables don’t happen all that often in day to day use of RobotC for VEX.
Also, the array has those 11 bytes of nulls. It’s possible (but really, really unlikely) that something in the protocol stack doesn’t like a string of nulls wherever they fall in the download. (Inside the initialized data section, I suppose. Assuming things are even arranged that way, of course.)
That would, indeed, qualify as obscure.
If this is related to the issue, then it might matter where it (the array) ends up in the image. But you could always try just tossing it into some existing code to see if it makes download issues.
Here’s a link to the code:
It’s split into 5 documents – main downloaded code, LCD selection, functions, autonomous routines, and gyro code.
My team gets this error all the time, and we do use a look up table for speed mapping. I’ll try removing it and see if that fixes the issue.
Interestingly enough, our team also ran across the same problem. We’ve had no problem downloading for the majority of the year until we added a motor remapping array. After adding the array our program fails to download about 60% of the time and after several attempts downloading we often get the Slave CPU error, so we have to redownload the firmware. Through some basic testing it seems that removing the array drastically increases the success rate of downloads, although this could just be due to other factors.
Thanks, I will test tomorrow.
There were issues in the distance past where if the last byte of a packet happened to match a packet header byte things would fail, but that was fixed years ago. However, there may be some issue with the particular contents of that array and radio packets or something like that, we will see…
So I dug into this a little, and it turns out this is another manifestation of a known problem that’s tricky to solve at this stage of the cortex lifespan. Here is what I posted into our bug tracker system last year.
The workaround for the code using the trueSpeed array is to make it an array of short rather than int.
const unsigned short trueSpeed[128] =
{
0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 21, 21, 21, 22, 22, 22, 23, 24, 24,
25, 25, 25, 25, 26, 27, 27, 28, 28, 28,
28, 29, 30, 30, 30, 31, 31, 32, 32, 32,
33, 33, 34, 34, 35, 35, 35, 36, 36, 37,
37, 37, 37, 38, 38, 39, 39, 39, 40, 40,
41, 41, 42, 42, 43, 44, 44, 45, 45, 46,
46, 47, 47, 48, 48, 49, 50, 50, 51, 52,
52, 53, 54, 55, 56, 57, 57, 58, 59, 60,
61, 62, 63, 64, 65, 66, 67, 67, 68, 70,
71, 72, 72, 73, 74, 76, 77, 78, 79, 79,
80, 81, 83, 84, 84, 86, 86, 87, 87, 88,
88, 89, 89, 90, 90,127,127,127
};Despite the array being const, RobotC really just makes this a whole bunch of global variables, yes, it’s different from a “normal” compiler.
Interestingly enough, before getting the error we’d often get an “invalid opcode” error so it seems like this is the issue. I’ll try the short solution. Thanks!
Probably unrelated. This usually happens when the RobotC VM is not the same version as the program on the PC. However, whatever works…
Great, thanks @jpearman for the help! We will make this change tomorrow and see if it fixes the issue.