.hex file too large for 2004 controller?

[AL_E]

Gang,

While attempting to test a program based on Kevin's "bells and whistles" camera code (with the addition of our own autonomous and RC mode drive code) we ran into a problem when loading the .hex file into the 2004 controller.

The download appears to complete correctly however the program state LED goes to red and the controller does not operate. We double checked the compile options (Device = PIC18F8520) and confirmed that the correct linker script and library have been selected for the 8520.

The .map file reports "30471 out of 33816 program addresses used, program memory utilization is 90%" I do not see a corresponding space usage summary report for the data area (RAM).

My question is this: Does the memory utilization figure reported in the .map file tell the whole story or are there other considerations (RAM usage or other factors) which would contribute to this problem. In short, is there a way to determine from the .map file whether or not the .hex file is too large for the 2004 controller?

Thanks in advance for the assistance

-Al

[Bharat Nain]

Unless you modified the code, the bells and whistles version code is not supposed to work with the older controllers. It is meant for the 2006 controller.

[steveg]

From the Documentation:

To compile this project to work with your 2005 [or 2004!] FRC (18F8520) system do the following:

  1.  Select the correct device from the MPLAB IDE. 

      Configure->Select Device->PIC18F8520

  2.  Replace the library file with the appropriate one.

      Remove the FRC_Library.lib file and replace it with FRC_Library_8520.lib
       
                                        or

      Remove the FRC_alltimers.lib file and replace it with FRC_alltimers_8520.lib

  3.  Remove the 18f8722.lkr file and replace it with the 18f8520.lkr file

  4.  Rebuild your project and download the HEX file to your controller.

[Mark McLeod]

The two risk areas where we can try to stuff too much are the Program Space and the Data Space. Either one will blow your code out of the figurative water.

90% as reported in the .map file represents full Program Space as far as the user is concerned. The other 10% of that space gets taken up by IFI overhead not covered by the report.

The .map file doesn't have a neat report for the Data Space. You have to check it yourself using the Data Space memory mapping at the end of the .map report. Compare the linked addresses to the blocks open to the user in the .lkr file.
From my notes 1,343 bytes of ram were available to the user after the 2004 default code (IFI, stack, etc), but that has to cover dynamically allocated local function variables as well that won't show up in the linker report.

There are usually some distinctive behaviors that indicate we are trying to stuff too much into the controller, but with the latest version of the IFI_Loader those symptoms may have all changed. I usually take time to experiment and measure the RC limitations, but there's no time yet. Today I'll be at four different schools.

[AL_E]

Thanks for the quick and substantive responses folks.

We had made the changes to the "bells and whistles" camera code as required for the 04 controller and it worked fine on our 04 controller until we loaded our old autonomous and RC code into the build. We suspect program size too large and from what I understand from the above posts we are at risk in the data space area. -- will dig in to it more tonight and followup. Funny thing though, we receive no linker errors. I would expect at least a warning if we were beyond the limit of the data space.

Thanks, Al

[steveg]

Instead of the bells and whistles version, you might want to try the streamlined version. It should take up less space and probably generally be better suited to the 2004 RC.

[AL_E]

Bharat, Steve, Mark,

Thanks all for your responses to my question. It turns out that when I added our autonomous mode code to Kevin's default camera code I overlaid the 2006 InterruptHandlerLow () function with last year's version. This apparently caused the processor fault. One of our students found this.

Mark, One of these days I'd like to dig into the details of data space usage a bit more - I have a lot to learn in that area. I notice that most of our variables are loaded in lower memory while some "system" variables seem to be loaded in high memory. The map shows a gap between the end of our variables and the start of the system variables - I assume that this is available data memory.

Steve, We may end up using the streamlined verison of the code for our production build. At this point we are using the full version to get a handle on camera setup parameters. With the default settings from Kevin's code we are able to track the standard target at about 30 feet although we need to be about 10 feet away to acquire it. (camera lens screwed out about 3/4 of way) More testing / setup is obviously needed...

Best Regards, Al