The 8.2 (or 8.3) Battery Voltage Bug

[Eldarion]

Originally Posted by Kevin Watson

You beat me to this question. I'm using 2.44 (version can be found in readme.c18) and have seen *none* of the problems teams are seeing. All of the code on my website has been compiled with the 2.44 version. Has anyone had a problem with the pre-compiled code in my .zip files?

-Kevin

Hmm, I am using 2.40. I wonder if the Microchip folks know about the problem, and have fixed it in 2.44? Where did you get 2.44?

Here's an idea for someone with access to a 2006 controller:
Try compiling your code for the PIC18F8520 instead of the PIC18F8722 and see if that cures the problem. It'll still run on the '8520, but I wonder if it might fix some of the problems (if it is truly a compiler bug, maybe it is restricted to the '8722 compiler). Just a hunch...

[yoyodyne]

Originally Posted by Kevin Watson

You beat me to this question. I'm using 2.44 (version can be found in readme.c18) and have seen *none* of the problems teams are seeing. All of the code on my website has been compiled with the 2.44 version. Has anyone had a problem with the pre-compiled code in my .zip files?

-Kevin

Kevin, we are using v2.40 17 November 2004. I didn't think we were allowed to use any newer versions. Saturday morning I was showing Dave Lavery the problem at the VCU regional and he went over and talked to the "IFI guy" who said that it was not possible for the user processor code to corrupt the battery voltage reading or the RC to OI comms. And that makes sense to me unless memory is shared between the processors or the MP passes the rxdata structure transparently or something like that. Is there any documentation on the interaction between the user processor and the master processor? The only thing I know is the tx and rxdata structures and the format of the dashboard data which provides clues as to what the OTA format between them is. Our one and only 2006 controller is locked in a crate awaiting the Atlanta regional so I can't do any testing but I do have code that parses through the dashboard output and generates an output file I can suck into excel for analysis. I would be interested in what actually comes out of the dashboard port when this is happening to see if data is skewed by a byte or two. I know when we have this problem, control input that should effect PWM5 turns actually gets coupled to PWM1 or 2 (they used to drive the same motor pair) I can give more details if anyone is interested.

Greg

[Eldarion]

Thanks to the Wayback Machine (www.archive.org), I was able to find the 2.42 upgrade file here:
http://ww1.microchip.com/downloads/e...oc/C18_242.zip

Aha! I found the 2.44 upgrade file here:
http://ww1.microchip.com/downloads/e...rade-v2_44.exe

I found this interesting section in the Readme (emphasis mine):
"The following parts have updates and/or corrections:
18F6520, 18F6620, 18F8520, and 18F8620"

Also, it makes mention of the 18F8722 having a problem or two...

[Eldarion]

Originally Posted by yoyodyne

Kevin, we are using v2.40 17 November 2004. I didn't think we were allowed to use any newer versions. Saturday morning I was showing Dave Lavery the problem at the VCU regional and he went over and talked to the "IFI guy" who said that it was not possible for the user processor code to corrupt the battery voltage reading or the RC to OI comms. And that makes sense to me unless memory is shared between the processors or the MP passes the rxdata structure transparently or something like that. Is there any documentation on the interaction between the user processor and the master processor? The only thing I know is the tx and rxdata structures and the format of the dashboard data which provides clues as to what the OTA format between them is. Our one and only 2006 controller is locked in a crate awaiting the Atlanta regional so I can't do any testing but I do have code that parses through the dashboard output and generates an output file I can suck into excel for analysis. I would be interested in what actually comes out of the dashboard port when this is happening to see if data is skewed by a byte or two. I know when we have this problem, control input that should effect PWM5 turns actually gets coupled to PWM1 or 2 (they used to drive the same motor pair) I can give more details if anyone is interested.

Greg

That makes sense, however why didn't we see this last year if the only change was the user processor?

Has anyone tried a master update in case some of the RCs have a corrupted master firmware?

[kaszeta]

Originally Posted by yoyodyne

Kevin, we are using v2.40 17 November 2004. I didn't think we were allowed to use any newer versions. Saturday morning I was showing Dave Lavery the problem at the VCU regional and he went over and talked to the "IFI guy" who said that it was not possible for the user processor code to corrupt the battery voltage reading or the RC to OI comms.

At the BAE regional, the IFI person (Corey) at first thought we had a user code bug, but later said that he was of the belief that something was wrong with the RC or the Master CPU code, for the same reasons (user processor code shouldn't be able to corrupt the comms or battery voltage readings). I've given them my code, FWIW. I haven't gotten the 8.2V bug to show up on our 2006 RC with the pure default code dated 2/24 (but I *did* get this code to show the problem with a loaner RC at BAE), but using gyro.hex from frc_gyro.zip I can get this to show up simply by loading the hex code a few times.

[yoyodyne]

Originally Posted by kaszeta

At the BAE regional, the IFI person (Corey) at first thought we had a user code bug, but later said that he was of the belief that something was wrong with the RC or the Master CPU code, for the same reasons (user processor code shouldn't be able to corrupt the comms or battery voltage readings). I've given them my code, FWIW. I haven't gotten the 8.2V bug to show up on our 2006 RC with the pure default code dated 2/24 (but I *did* get this code to show the problem with a loaner RC at BAE), but using gyro.hex from frc_gyro.zip I can get this to show up simply by loading the hex code a few times.

If I had the 2006 processor I would reload the master processor bin file. So many things that I normally would have done to narrow this problem down did not happen in the heat of battle.

I asked IFI if they knew what master processor version was shipped but I haven't gotten a reply yet.

Part of post to IFI new problem under gsmith last night...
*******
I ran into a problem at the VCU regional starting last Friday where the communications between the OI and RC were getting corrupted. It looks like the data structure between the master processor and the OI is shifted by a byte or so. We are using the 2006 RC and OI received in the FIRST KOP. We have not re-flashed the master processor and I don’t know what firmware revision it is although I noticed that the date of the Frc_master_v12.bin file, the latest?, is 10/27/2005 so I assume we have the latest master code.

*****

[Eldarion]

Originally Posted by yoyodyne

*******
I ran into a problem at the VCU regional starting last Friday where the communications between the OI and RC were getting corrupted. It looks like the data structure between the master processor and the OI is shifted by a byte or so. We are using the 2006 RC and OI received in the FIRST KOP. We have not re-flashed the master processor and I don’t know what firmware revision it is although I noticed that the date of the Frc_master_v12.bin file, the latest?, is 10/27/2005 so I assume we have the latest master code.

*****

Where did you find the Version 12 Update file? The latest on IFI's website is Version 11, dated 4-15-2005.

[yoyodyne]

Originally Posted by Eldarion

Where did you find the Version 12 Update file? The latest on IFI's website is Version 11, dated 4-15-2005.

It's in the

"2006 RC Code (zip,21-28-2006) Contains both Default/User and Master Code, contains new libraries below."

Zip file.

[Eldarion]

Originally Posted by yoyodyne

It's in the

"2006 RC Code (zip,21-28-2006) Contains both Default/User and Master Code, contains new libraries below."

Zip file.

Thanks!

[Bharat Nain]

I have a 2004 upgraded to a 2006 RC sitting at my house. I will try to get a battery and try to reproduce the results. Since we were also having similar problems through the day, I would be glad to test out anything suspectible. Please get in contact with me if you think you have a possible solution to this problem or a way to get there. I never spent time at NJ trying to correct the bug. I just replaced the battery. Thanks
-Bharat

[kaszeta]

IFI appears to be working on this, and has sent me an updated linker script which I am going to test to see if this corrects the issue. I'll let you know how testing turns out.

[Kevin Watson]

Originally Posted by kaszeta

IFI appears to be working on this, and has sent me an updated linker script which I am going to test to see if this corrects the issue. I'll let you know how testing turns out.

Can those folks who are having problems please try building your code with the attached 18f8722beta.lkr link script and testing your code. If you still have problems, then try the attached 18f8722_2.44.lkr script and test again. Please report back here with the outcome.

-Kevin

[ScottM]

We were running our practice robot tonight and ran into a very similar problem. In the middle of running the robot manually, the inputs stopped working and the OI displayed 8.6v. After cycling power on the robot, it worked fine. Could this be another manifestation of this issue? We are using the 2005 controller and easyC.

[chris31]

I dont have our 2006 controller or any parts with me. But anyone who had this issue please post what you find after using this new linker script.

[kaszeta]

Originally Posted by Kevin Watson

Can those folks who are having problems please try building your code with the attached 18f8722beta.lkr link script and testing your code. If you still have problems, then try the attached 18f8722_2.44.lkr script and test again. Please report back here with the outcome.

-Kevin

I breadboarded up our 2006 RC, and now I'm in the frustrating situation that I can't duplicate the error, even using the exact same .hex files as in the pits at BAE. So I couldn't get the error to show up, so I can't tell if 18f8722beta.lkr is doing anything. Anyone yet found a highly reliable way to duplicate this? (very frustrating, since it was showing the error reliably in the pit)

As for 18f8722_2.44.lkr, if you try to use it as provided, you get a "Error - section '_entry_scn' type is non-overlay and absolute but occurs in more than one input file" from the linker, which requires that you comment out the first "FILE" line in the .lkr script. After that, IFI Loader won't upload it, giving an "invalid address : 0x20 (Correct Range: 0x800-0x7fff)" error.