I know this version is new but was wondering if anyone has had the same problem. After upgrading and re tethering, the vexNET light shows connected and the robot light shows that there is a User Microprocessor issue. The weird thing is the joystick shows all green. Any help would be appreciated.
Also, the robot works fine when tethered.
I can’t say I’ve noticed any issues.
Have you upgraded both cortex and joystick to V3.20 firmware?
Have you loaded the RobotC firmware version 9.10 ?
Were you running RobotC V3.05 before you upgraded or an earlier version?
I’ve had the V3.20 firmware loaded for a couple of weeks (well since 3.05 came out) and have been bouncing around between using RobotC 3.04, 3.05, EasyC 4.0.2.8 and now 3.06 without changing firmware or having any issues. I normally have the cortex and joystick tethered to avoid using joystick batteries.
I actually went from 3.04 to 3.06. Should I get 3.05 and update the firmware through that. When I opened the file I made in 3.04, I got a bunch of typedef warnings.
No need to use 3.05, the same master firmware is included with both 3.05 and 3.06, I was just curious if you had everything working with 3.05 or not.
There were some problems with using enumerated types in 3.05, same in 3.06 I think. For example, I used to something similar to this.
// Possible tests
typedef enum {
kVersions = 0,
kJoystickTest = 1,
kMotorTest = 2,
kAnalogTest = 3,
kDigitalInTest = 4,
kNumberOfTests
} TestMode;
string DisplayText[kNumberOfTests];
Now I have to cast to a short as follows.
string DisplayText(short)kNumberOfTests];
Does a software inspection show all versions are OK?
I haven’t tried 3.05. I also don’t use enum, I use struct. I don’t know if that is similar but it worked with 3.04. I can still download to the robot since they are errors but It is a little annoying.
I’m not sure if this is true with ROBOTC, but with EasyC, I’ve that found old programs embedded in a competition template are sometimes not compatible with a new software version. I have make a new program using a new version template, but I’m able to import code blocks from the old template through user functions or copying and pasting.
Generally this is not the case with ROBOTC as there is nothing particularly special about the competition template. Occasionally something will change in a header file that may be incompatible, for example, there was a case when a constant name changed from kButtonRight to kRightButton, but that does not happen very often. It is important to have the correct virtual machine (the ROBOTC firmware) loaded for the development environment version you are using. For V3.04 the firmware was 9.04, for V3.06 the firmware is 9.10. Using the software inspection menu will alert you to any problems with the installed firmware.
So to be clear, it is not necessary in my experience to use all the incremental updates for ROBOTC. It is perfectly OK to go from version 3.04 to version 3.06 and skip last months release.
If there is a problem with a certain program, try and create a small example that demonstrates the problem and post it here. I will try and duplicate the issue and, if it is indeed considered to be a bug, will forward to the developers to be addressed in the next release.
The master firmware handles the VEXnet connection and USB tethering. If you still have a problem with that then the common solution is to reload the master firmware and try again. I have been using master firmware 3.20 for the last month and have not noticed any issues.
But when I use the USB A-A cable connected from the joystick to the cortex, the program runs perfect. It is just when the VEXnet key is used where the cortex lights are:
Robot: Red Blip every second or so
VEXnet: Green
Game: Blank
and the joystick lights:
Robot: Green
VEXnet: Green
Game: Blank
Anytime the tether works, but Vexnet doesn’t, makes me think of
- bad vexnet key
- loose vexnet key connection
- school ad-hoc wifinetwork blocker
The thing is, the vexNET key works with the 3.04 version firmware but not the 3.06.
Sorry to keep pushing the same point but have you reloaded the master firmware? Does your software inspection match the following in terms of version numbers?
Communications Link: COM Port 'COM3' to VEXNET Joystick
Standard Firmware File Names:
=============================
VEXNET Joystick: .\Firmware\JOY_V3_20.BIN
VEX Cortex Master CPU Firmware: .\Firmware\CORTEX_V3_20.BIN
VEX Cortex CPU Firmware: .\Firmware\VEX_Cortex_0910.hex
VEXnet Joystick Integrity:
==========================
Firmware Version: 3.20 Up to Date
Battery Voltage: 4.8V Poor (<6.1V)
Calibrated: Yes
Joystick State: Powering Up
Cortex Master CPU Integrity: Value Status
============================
Firmware Version: 3.20 Up to Date
Main Battery: 7.5V Good (>6.5V)
Backup Battery: 0.0V Poor (<8.0V)
Team Name: "01ROBOTC" OK
Cortex User CPU Integrity: Value Status
==========================
Firmware Version: 9.10 Up to Date
Program Type: VEXNET Wi-Fi (required) GoodHave you tried a very simple program as an alternative to whatever code you are trying to run? Do all programs have this same behavior?
Are the batteries good?
If all the above are OK then I’m out of ideas as I cannot duplicate what you are seeing.
Here is mine:
Communications Link: COM Port 'COM10' to VEXNET Joystick
Standard Firmware File Names:
=============================
VEXNET Joystick: .\Firmware\JOY_V3_20.BIN
VEX Cortex Master CPU Firmware: .\Firmware\CORTEX_V3_20.BIN
VEX Cortex CPU Firmware: .\Firmware\VEX_Cortex_0910.hex
VEXnet Joystick Integrity:
==========================
Firmware Version: 3.20 Up to Date
Battery Voltage: 6.9V Weak (7.1V - 6.1V)
Calibrated: Yes
Joystick State: Powering Up
Cortex Master CPU Integrity: Value Status
============================
Firmware Version: 3.20 Up to Date
Main Battery: 7.7V Good (>6.5V)
Backup Battery: 9.2V Good (>8.7V)
Team Name: "" Not Assigned
Cortex User CPU Integrity: Value Status
==========================
Firmware Version: 9.10 Up to Date
Program Type: VEXNET Wi-Fi (required) Good
The only thing different is the Team Name. What is that?
Team name is a new feature in this (and 3.05) version, EasyC has had this for a while. It lets you store a string in non volatile memory, the name of your team, I don’t really see the point but suppose it’s of some use. It would be nice to be able to read this from code (need to check, perhaps you can) and then it could be used for other sneaky things 
It seems like your problems are similar to this: ROBOTC
I can’t really offer any help, but perhaps an answer will be reached in that topic.
That is the exact thing I have been having problems with. I reinstalled 3.04 and the firmware and everything works fine. I still do’t know what the problem is.
Hey tutman -
Can you share your entire program (privately, if you prefer)? I’m trying to recreate the problems you and the user on the ROBOTC forums are experiencing, but have been unable to do so with their motors and sensors configuration.
When I upgraded to 3.05 a few weeks or so ago, I started noticing a problem similar to this. During testing, I would continuously have to restart the Microcontroller, because the robot would suddenly twitch, and the Microcontroller would give me nothing but a green light on VEXnet, and would be disconnected from the joystick. They wouldn’t pair again until I restarted the Microcontroller (power off, power back on).
I tried disconnecting the Backup Battery, and though this seemed to help the first time, it continued happening. We were able to make it through one tournament that way, I believe, but on the field before the match started, a couple times we had to restart our Microcontroller because it would do this.
I had already tried re-downloading Mastercode, and Firmware to both the Microcontroller and VEXnet Controller. I also tried un-installing RobotC, and doing a clean install. None of these fixed the problem.
Before our last tournament we started seeing this problem occur more frequently. So frequently that we had to restart our Microcontroller about 10 times in some instances before getting a connection for 5 seconds or more, to get a program downloaded and tested. The day before the tournament, I went completely back to RobotC 3.04 and I never saw it again.
~Jordan
I just finished running our league championship here in Georgia this past weekend and we had 2 teams in the finals that experienced similar problems. going into the finals, one team experienced connection problems with their robot when tethered to the field. Before their next match, they upgraded their firmware but were then not able to establish a connection with their robot on the field at all. Their alliance partner experienced the same thing when they did a firmware update in the next match. We ended up utilizing a competition switch for both teams and manually starting and stopping autonomous and driver modes to complete the competition.
If you would like, I can reach out to those teams and have them both provide a copy of their robot code also.
I have to say that feels like a master firmware issue to me rather than something specific to ROBOTC. It may be firmware combined with specific hardware, I will try and compile a detailed list of questions later on that perhaps tutman96 you could try. The first thing we have to try and eliminate is the user program, we need to prove that with the same code some users have an issue and other don’t. We need to dumb the code down to something like this and know if the problem exists or not.
#pragma config(Motor, port1, motorA, tmotorVex269, openLoop)
//*!!Code automatically generated by 'ROBOTC' configuration wizard !!*//
task main()
{
while(1)
{
motor motorA ] = vexRT Ch2 ];
wait1Msec(50);
}
}I don’t see how it could be the user code that prevents VEXnet from working. As I said before, the robot works perfect when tethered. I don’t think it is the user code that is the problem so I won’t share it.