Programming issue

[ralpok]

The Basics:
CCS Compiler Version 4.027
Target PIC 184685
Debug Mode
Target Voltage 5V
Traget Oscillator 20mhz

I am having a problem where my array of floats is not getting cleared. When I dug into the assembly I found the attached code. I then used the debugger to look at all the associated memory addresses and 5F, 5E, and 5D are cleared but 60 is not. I also an unfamiliar with what the 'X' means in front of the 60. I also checked all the other memory addresses that had a value 60 in them (i.e. 160, 260, 360 ... f60) and none of them were cleared either. Some help in understanding what the assembly is doing will be helpful and any advice as to why when I "watch" this varaible right after I clear it does it still have a value to it?

[RossJ]

Data memory in many PIC families is banked, as opposed to being in one continuous address range. What this means is that a separate register (bank select) controls which bank of memory is accessed whe an instruction accesses a particular address. In the PIC18 instruction set, some instructions only contain the lower 8 bits (others like MOVFF contain the full address). If a banked access is used, the compiler shows this as xnn since only the nn parts (lower 8 bits) is indicated by the instruction. The MOVLB instruction loads the bank selection register with a literal value and is the most common instruction for controlling this register used by the compiler.

One other thing to consider is that some parts of memory are designated as 'access' memory. Essentially this is a small part of memory which can be accessed without depending on the current bank selection. Many instructions contain an 'a' bit which indicates whether an instruction accesses memory directly in the access bank or anywhere else with the help of the bank selection register.

In your example, I suspect that 5D-5F are being addressed via the access memory, while x60 is not, and depends on the current BSR. Possibly the compiler hasn't allowed for one variable to cross this threshold, and thus hasn't set the correct bank. Look at the preceeding instructions for a MOVLB instruction, and compare the bank with the .sym file's statement as to where your variable has been placed.

Also, you might find it helpful to look at a proper disassembly which shows the instruction binary as well. Then you can compare it with the datasheet for a better understanding of the difference between the instructions with and without an 'x'. I use MPLAB to do this, and import the .cof file.

If you suspect that the compiler is at fault here, it would be a good idea to try using the latest version since you are a little behind the times (current version is 4.035.

/Cheers, Ross.

[ralpok]

RossJ,

Thanks for your reply. It was very helpful in helping me understand how the PIC was working. Unfortunately it didn't solve the problem. I have updated to CCS compiler 4.035 and am experiencing the same problem.

While running my code in the problematic sections I looked at the BSR register. What I found was that it was set to 1 instead of 0. This didn't seem to make sense with the rest of the code around it, especially breaking the variable up across 2 different banks for the clearing of the following variable. Checking the RAM directly shows that 5D-5F and 160 got cleared and 060 did not.

[ralpok]

Found a way to hack around it.... but if anybody can give me a full explination as to why it wasn't working I would apreciate it.

The Hack is in the decleration:

[PCM programmer]

If possible, post a small test program that shows the problem.
Show all variable declarations. The test program should be able
to be copied and pasted into MPLAB and compiled without errors.

[ralpok]

So.. I tried to make a small test program displaying the problem and it worked without showing the issue, and then I went back to a .zip of the project that was displaying the problem (had it saved from when I sent the issue to CCS tech help) and it also behaved properly. I don't know if my call to #locate fixed the issue or what but all in all I am going to call this issue a mystery that I don't think will be solved at this point.

Thanks for the attempt at help PCM and all the help you give around the forums.

Ralpok

[RossJ]

Ralpok,

You are correct in your assumption about MOVFF. If you take a look at the instruction set summary in the data sheet, you will see many instructions contain 8 bits marked 'ffff ffff'. This represents the instructions that can only address a 256 byte page, with the help of the 4 bit BSR. MOVFF is the only instruction to have a 12 bit address (both source and destination) and thus does not depend on the BSR (and similarly doesn't need the option of addressing access memory either). So MOVFF can move any byte to any other byte of data memory (in two machine cycles), and is the instruction used by CCS when copying a variable from one fixed address to another.

Regarding how BSR came to have the value 1, remember it is just a SFR which happens to have a purpose made instruction for optimisation (MOVLB). So any instruction which modifies the BSR as a SFR could be responsible (including indirect accesses). Even faulty memory accesses could do it (you observed 0x160 being modified in error).

Another possible reason is that the LST file doesn't actually contain all the generated code! Cases I know of include certain types of switch statements and constant array lookups. There are probably others. You may find a call or jump instruction to an address not present in the LST file. I use MPLAB to import the COF file and view the disassembly listing when I need to see this code. So there might be a BSR modification in some code not shown in the LST file.

I tried to reproduce your problem (admittedly using an 18F2620), but was not successful. The compiler doesn't seem to care if large variables are split over the boundary of access memory. But it does appear to correctly insert MOVLB instuctions as required. So there must be something in the surrounding code which is causing the compiler to screw up.

If you think this is a fault in the compiler, it's in everyone's interest to try and see it through to a resolution. From what you have described, there is little doubt that it is a fault in the compiler. The question is under what circumstances it is triggered, and whether CCS has fixed it intentionally or otherwise) in a later version. If you have trouble reproducing the problem with the latest version, go back to a version you know the fault occurs in. Bugs like this can seem to be fixed in new compiler releases, but in fact the problem simply didn't occur because of differences in other parts of the generated code.

If you have submitted something to CCS, contact them to find out if they have pinned down this problem, before wasting time investigating this any further.

/Ross.

[PCM programmer]

[Jim Hearne]

[ralpok]

No word from CCS for the moment.

Okay... so it doesn't seem to reappear if I change the code to fit as a small example but I have been able to reproduce it with the updated compiler and I am going to try and give you guys all the information about the system. This is compiled and run with the #nolist commented out.

Included here is: basic code that gets executed,and the entire code base, screen shot of the debugging. If you want a look at any parts of the .lst file let me know, I did a quick search and didn't find anything new about setting the BSR register. I would have posted the entire .lst file but didn't want to due to protecting CCS's IP since the comments have all their code in it. Thanks in advance for everyone's help on this topic!

Image Hosting

the variable decleration:

[ralpok]

The entire code base