ConVEX - open source firmware for the cortex

[jpearman]

@JVN

Of course, it is important to note that some of these tools are utilizing pieces of the VEX hardware and firmware which are normally hidden from the end user. Some of these pieces when changed can affect the performance of the hardware in negative ways. There are even parameters of the software which when changed can result in a failure of the hardware. Unfortunately, in this instance VEX Robotics is unable to provide warranty support.

Please, be mindful when experimenting.

I wanted to respond to John’s post in the thread discussing programming options for the cortex. I’m happy that VEX supports the creation of both PROS and ConVEX and also understand that they can not be liable for any damage that this unofficial software may cause. Of course, code written in both EasyC and ROBOTC can also damage the cortex, access to the source code is not necessary to do this. Any embedded system that runs a language where pointers are available and relies on the firmware to play nice with it’s hardware is at risk.

So lets take a look at what is at risk, what may cause that and how to avoid it.

**Motor ports 1 and 10
**
Jumping straight in, it’s the control of motor ports 1 & 10 that poses the most serious risk for damage. I explained in some detail in this thread the problems of shoot through with a H-bridge circuit. The control of the four FETs in the H-Bridge is completely under control of the user firmware in the cortex (unless the competition switch or field control has disabled them). If the high side and low side FETs are enabled at the same time the battery is essentially shorted. The FETs are rated somewhere around 8A so, in a short time, if the cortex is being powered from a VEX battery, they will overheat and magic smoke will be produced. If the battery is low on charge a different situation may happen where the short causes the battery voltage to drop enough that the cortex resets, an endless loop of reset and firmware causing a short will now occur, this can make it near impossible to load new code that does not have the bug.

So how to avoid this problem.

1. Don’t mess with the low level motor control firmware, leave the file vexmotor.c alone, there’s nothing to be gained by trying to change the built in firmware in this area so just keep on using vexMotorSet (or SetMotor if using the smart motor library) function.

2. Don’t reconfigure the GPIO ports on the processor, especially port D. The initial conditions for these ports are part of the board support files, board.c and board.h, leave these files alone.

When I was developing the ConVEX library there was obviously a period where I had to control the H-bridge for the first time. I did several things to avoid damage when doing this. First, I tested the code on a different hardware platform that had a similar micro-controller (the same but with less memory and IO), this allowed the control signals to be monitored with an oscilloscope with no potential risk to anything. Secondly, I use a current limiting power supply. If by mistake I had a bug in the code that shorted the power, the power supply would limit the current to safe levels by dropping it’s voltage, no damage would occur. Thirdly, I always use some safety bypass features at the beginning of the code where I can stop all code from running using a switch. If the code were to go into the endless reset, bug, shorted FET condition I have a way to break out from that cycle. Anyway, being the coding guru that I am ( ) none of these secondary and tertiary measures were needed and everything ported from the eval card to the cortex without drama. I did all this so you don’t have to, however, I still released the source as it’s worth studying and may help you with something in the future at college or work.

I see no other significant areas of risk, the IO ports are protected by series resistors so misconfiguring them (even as open collector) should not be a problem. The I2C and UART ports pose no risk beyond that of connecting devices with an incompatible electrical interface, this is no different in ConVEX than any other language including EasyC and ROBOTC. So it’s completely safe to bypass the existing ime or lcd code, you may crash the firmware by adding new code that has bugs, but that happens to me all the time with ROBOTC and would be expected.

So I can’t argue with John’s position but I would say the following.

ConVEX is safe when used appropriately, remember I advertise this as being suitable for the advanced user. I have tested ConVEX extensively but there may be some bugs left, testing can only exercise a limited number of conditions and you may attempt something that I could not test (five ultrasonic sensors perhaps). I am an experienced engineer who has worked on embedded systems like this (amongst many other things) for 30+ years, I know what I am doing but also remember that I did this by reverse engineering the cortex, I have no access to schematics or any technical information from VEX and it is possible there are unknown hardware problems I did not discover.

To teams experimenting with ConVEX, if you have any concerns over the code you have written or want input on how to improve it, send me a PM or post publicly and I will help.