Compiling Help!!

[ajsetter]

We're using the Microchip MPLAB version 7.00 and the C18 v2.4 compiler. We can load the pre-compiled code (FRC_default.hex) to the robot with no errors and it works just fine. Our problem is when we try to compile the code (that FRC_default is supposed to be compiled from) with no changes whatsoever to the code and load it to the robot, we get a program error (as in the program state LED on the robot controller is flashing green and red). We expierenced this problem last year as well, but i can't for the life of me remember what we did to fix it. It obviously seems to be a compiling issue because the pre-compiled default works fine. I have tried useing different computers to compile but nothing is working still. Any help from anybody would be great, thanks.

-Andrew
Team #612

[Mark McLeod]

Well there are several reasons this could happen.
Start with making sure you are compiling for the correct PIC version.

In MPLAB under Configure->Select Device does it show "PIC18F8520"?

[ajsetter]

Yes, the select device shows "PIC18F8520" However I have contacted older members of the programming team from previous years to see what they did to fix the problem. Our setup is as follows: an old p2 desktop with windows 2000 pro and all updated microlab, compiler and ifi loader (has 2 serial ports), our other computer is a p4 windows xp pro laptop with no serial ports, only USB slots, it also has all the updated software. As I was told from last year, when we had this problem, we just switched to using the new laptop (with a usb to serial converter) and everything was fine. Well our converter was stolen in between last year and this year, and we haven't been able to get our new converter to work yet. We can still edit and compile code on the laptop but it wont transfer to the robot. The old p2 computer will transfer the code to the robot, but only the FRC_default gives us no error, any other hex file we try to send to the robot (wether is was compiled on the p2 OR the laptop) won't work and gives us the bad code error. Maybe the old team is right and if we can just get the new usb to serial converter working on the laptop then maybe it will work. We are using a Bafo Technologies BF-810 converter and we've checked all the bitrates to make sure they match up and windows also recognises it as a usb to serial converter in COM2 but ifi loader still wont transfer the code (it gives the "make sure the program state LED is orange" error). I trust the old team members that once we get the laptop working, everything will work, so any help with this problem would be great as well. Thank you so much for you time.

-Andrew

[Mark McLeod]

Originally Posted by ajsetter

... in COM2 but ifi loader still wont transfer the code (it gives the "make sure the program state LED is orange" error).

I've sometimes seen this when using the COM port claimed by the manufacturer's manual on the new USB converter. The device seemed to be there, but it really wasn't. Try ignoring what port they declare it will be on and test it with each of the other ports one-by-one anyway. I had one from Radio Shack that said it was supposed to be in COM3, and I got a similar error. I actually found it worked on COM4 instead. That's one of those things you have to watch out for in software, making the assumption that the documentation is actually correct. My basic assumption is the documentation always lags what gets delivered, so it's up to me to discover the errata. Don't believe what you read, especially if you can easily test the alternatives.

Select the different COM ports one-by-one in IFI_Loader under the PortSettings pull-down and send.

It could also happen of course if there is other software, e.g., Hyperterminal or something like that, running on your PC that's trying to claim the same port. You can try disabling all unnecessary software running on the old desktop PC.

After you've attempted to downloaded the compiled HEX file and get the error message, does restarting the controller get it out of that state and back to regular operation, or must you redownload the default HEX file before you can drive your robot? I'm just wondering if any transmission takes place at all. Also, I assume you know you are really succeeding at re-downloading the default HEX file based on the IFI_Loader progress bar.

As a further diagnostic take a look at the sizes of the default vs the compiled hex file. They are probably different based on the debug settings selected in MPLAB under Project->Build Options...->Project then the "MPLAB C18" tab, then "Optimization" under the "Categories" pull-down. It's probably difficult to get them to be the same, because we don't know how the default HEX was originally constructed. I'm more curious if you're compiled HEX file is larger or smaller than the default HEX file.

[HaWkeYe15]

Our MPLAB is giving us a .cof file instead of a .hex... how do i make it come out as a hex file?

[ajsetter]

I have tried other ports other than COM2. When i look under windows device manager in the ports list, thats where I see the USB to serial converter. When I go into the properties, I can change which port its on (COM1, COM2, etc.) and i have most of them and none of them seem to work. I have also tried changing around bite rates to match IF loader and changing some settings about buffers, but nothing still seems to work.


As for the downloading hex file; When I download my compiled hex file, and get the error, restarting the controller doesn't do anything. Normally when the hex file is finished downloading the program state goes from blinking orange to solid green telling us the program is running. Once i download our hex file, the blinking orange light stays blinking until i reset the controller and then after its reset, it flashes red and green (bad code). I then have to re-download the default hex file and after it finishes, it runs as it should.

[ajsetter]

Originally Posted by HaWkeYe15

Our MPLAB is giving us a .cof file instead of a .hex... how do i make it come out as a hex file?

I used to have this problem as well. Check your output window to make sure that there are no errors in the compile process, if there is even just one error, all it'll give you is a .cof file.

[HaWkeYe15]

I have it set to stop compiling when there are any errors.. so i don't think thats the problem.. hmm...

im not sure the programming is the problem though, I reloaded the default and it still didnt work.
I have no idea why its not working though... the spike works when its plugged into another pwm port.. so its not the spike.. maybe i should change the programming to an unused pwm..
we'll see..
anyway, thanks for your help

[RbtGal1351]

i've gotten the green and red blinking lights on the controller a few times.
Normally it seems to be a problem with the serial port connection, and i re-plug in all the cables, and try again; and it usually works. It didn't think it was a problem with compiling the code.

~Stephanie
Team 1351

[Mark McLeod]

Originally Posted by ajsetter

Once i download our hex file, the blinking orange light stays blinking until i reset the controller and then after its reset, it flashes red and green (bad code). I then have to re-download the default hex file and after it finishes, it runs as it should.

It sounds like your downloading works okay since the original hex file downloads and runs. I've seen this happen when the hex file didn't get completely downloaded, or the hex file was a partial one, or as RbtGal1351 suggested the cable connection was noisy or otherwise poor, but unless the compiled hex is larger than the default hex I don't see why this would be your case.

To help isolate the culprit I've attached a default v2.2 hex file I compiled and tested on our robot. Try downloading this. If you still have problems then it isn't your compiler it's the connection, if you do have problems then lets dive into your compiler settings.

PS: I was backpacking in Mass. over the weekend, so I was out of touch for awhile.

[CJO]

Our MPLAB is giving us a .cof file instead of a .hex... how do i make it come out as a hex file?

One is supposed to be able to edit the workspace to output a hex, however, I have sometimes been unable to do this, in which case:

In the /bin folder of C18 you can find a cof2hex executable. This can be called from a shell script and used to convert your cof to hex.

[Joe Ross]

Are you, by any chance, using the camera default code without the camera attached?

[ajsetter]

OK, I've solved one of my problems. I switched from using the old p3 to using a newer Compaq p4 and it transfers the code fine over to the robot. It doesn't have the MP LAB Ode v7.00 yet because we can't find the install disk, but we know where one is. So right now we just compile it using our laptop, transfer it to the desktop via a flash drive and everything works fine. That brings me to the problem I still have at hand, I still can't get the laptop to transfer across the USB-serial converter. Windows recognizes its there (under device manager it sees a "prolific USB-serial converter" on port COM1). We've checked to make sure the bit rates are fine and checked the drivers, but for some reason, the IF loader still won't transfer the code across. Any suggestions about this problem would be great, and thank you so much for your help on the previous one.

-Andrew

[JamesBrown]

mplab 7.00 (and 7.20) can be downloaded from the Microchip website

[Mark McLeod]

Originally Posted by ajsetter

Windows recognizes its there (under device manager it sees a "prolific USB-serial converter" on port COM1).

I have run into USB driver conflicts from past USB drivers loaded onto a machine. Did you use the install disk that came with the BAFO or did you let Windows pick the driver?

I might still try testing the other COM ports through the IFI_Loader pull-down rather than the Device Manager properties. I did run into a strange case where Windows declared it to be on one COM port, but it actually worked if you lied to IFI_Loader and picked the port next to it. I think that was really a USB drive issue though and I don't remember what version of Windows that occurred under.

P.S. On a side note did you know that if you spend a long time replying you can avoid the CD timeout by going into Spell Check before attempting to post the message?