Out of space?

Technical Programming
1

We are having a strange problem when uploading our code. It almost seems like we are out of space, but we do not really have much code written. Mostly we’ve used the camera code (although it is the “bells and whistles” version) and the gyro code.

The code compiles and runs fine, but then we might add something simple like a new printf() and then when uploading the yellow light will stay on and the terminal will show a hex dump.

We are going to start paring out some whistles (but hopefully leave the bells).

Is this definitely an oversize indication? One of our coders noticed this in camera.map:

                          Program Memory Usage 
                           Start         End      
                       ---------   ---------      
                        0x000800    0x007f3f      
        30528 out of 132120 program addresses used, program memory utilization is 23%

Is there another more restrictive limitation somewhere? How do we determine if our generated hexfile is out of bounds?

2

Are you using the most current version of the IFI Loader, v 1.1.0?

3

> Are you using the most current version of the IFI Loader, v 1.1.0?

Yes.

4

<EDIT>I just saw that you included this in your post…I glazed over it thinking it was a signature</EDIT>

In your project directory should be a .map file. If you open it with a text editor you can find out how much memory you’re actually using. Look for the section that looks like this


                              Program Memory Usage 
                               Start         End      
                           ---------   ---------      
                            0x000800    0x0050a7      
18600 out of 132120 program addresses used, program memory utilization is 14%
5

> you can find out how much memory you’re actually using

>> 30528 out of 132120 program addresses used, program memory utilization is 23%

So as long as this number is not 100% we’re definitely not having a space problem?

Is there a document that tells about those hex dumps?

Any other ideas what might cause these symptoms?

6

You’re not having a program space problem. You’re probably not having a data memory problem, either, since IIRC the compiler catches that one.

Odd, since Team 95’s current code is just about as large (basically the stripped camera code, adc, gyro, encoder, custom PWM driver code, and a bunch of routines that use trig functions), and we haven’t had problems. Are you sure you’re using 1.1.0?

7

This message all but clinches it for me that you are NOT using IFI Loader, v 1.1.0.

This year’s robot controller has 4 times the memory of last year’s, and 1.1.0 is the first version that supports the new improved RC. It was not released until January 26th. (There was a subsequent re-release on February 7 which I think was to address installation problems experienced by some people.) BE ESPECIALLY CAREFUL THAT YOU’RE NOT USING V 1.0.10, since it is so easy to conflate the two.

8

> This message all but clinches it for me that you are NOT using IFI Loader, v 1.1.0.

Well… I know that we have upgraded IFI Loader twice already. Once going to 1.0.12 and then again to 1.1.0, but I will (triple) check tomorrow when I get back to the lab.

“”"
Program Memory Usage
Start End
--------- ---------
0x000800 0x007f3f
30528 out of 132120 program addresses used, program memory utilization is 23%
“”"

Isn’t this message generated by mcc18 and not by IFI Loader? How could this message indicate a problem with using the wrong Loader?

9

if it compiles, the problem HAS to be the IFI Loader. everything else is DONE when it finishes compiling. IFI Loader doesn’t call mcc18.

10

This message is produced by mplink.exe, which KNOWS about the extra memory that the PIC18F8722 has. The older ifi_loader DOESN’T know about it, and ralphs when it gets too full. :eek:

11

>> 30528 out of 132120 program addresses used, program memory utilization is 23%

> This message all but clinches it for me that you are NOT using IFI Loader, v 1.1.0.

> The older ifi_loader DOESN’T know about it, and ralphs when it gets too full.

So you’re saying that since the new one allows 4 times as much space and ours is failing at about 1/4th full it is almost certainly a Loader problem. Makes sense.

I’m starting to wonder if we have some kind of a mixed IFI Loader install. I remember having trouble uninstalling the old version to install the new one. I am almost certain that going to “About” shows 1.1.0, but maybe there is an old .dll lingering and causing trouble.

Hopefully a full re-install of IFI Loader will solve the trouble. Thanks for your help.

12

Yeah, if you just install the new IFI_LOADER over top of the old one, the old one sticks around and it’s really easy (at least it was for me) to run the wrong one.

13

I’ve never had that problem (with ifi_loader.) My guess is that you must have installed the new one in a different directory, and then invoked the old loader using an old shortcut.

14

OK. It is working now. Definitely a Loader problem.

> Yeah, if you just install the new IFI_LOADER over top of
> the old one, the old one sticks around and it’s really easy
> (at least it was for me) to run the wrong one.

I finally gave up trying to uninstall IFI Loader. Installing without uninstalling does not work.

Luckily, we are able to just run the .exe from the expanded zipfile.

Thanks for your help!