Code too long?

Comment

Comment by Hollis Milroy on February 28, 2011 at 6:43pm

This is an old thread, but in case ppl still refer back to it:

I only have one org statement.

My code is in multiple files, and it compiles and loads my main.asm code and then my lcd.asm back to back in program memory.

Also, I had to put everything, including my definitions, equates, variables, and macros after my org 0x00 statement (and after my tables)

Comment by Matt Nejati on January 27, 2011 at 11:40pm

Thanks for the heads up

Comment by Valentin on January 27, 2011 at 10:20pm

IMPORTANT

I've researched this thoroughly and looked through a ton of code from my project last year.

 

There IS in fact a 256 byte boundary (in program memory) at the beginning of the code within which all tables must be stored. Note this isn't 256 lines, but bytes - best viewed after compiling and selecting View > Program Memory and making sure there are no tables after 256 bytes.

 

I remember having to cut down on my tables last year because of this.

 

I've also found a forum post where clever manipulation of the PCLATH register allows for larger tables. However this may be a little complicated and I would just suggest keeping the tables compact.

 

http://www.edaboard.com/thread69866.html#post308188

Comment by Matt Nejati on January 27, 2011 at 10:05pm

I tried rearranging my code to include my DT statements on top as you guys suggested and everything seems to be working fine. 

 

My LCD.asm still starts at 0x700 and it is still separate so it seems as the problem was the DT statements.

 

Thanks guys for the help 

Comment by Yifan Wang on January 27, 2011 at 9:21am

"QUOTING THE OTHER BLOG"
If there is a certain length of code coming before the DT (define table) directive, then characters/entries in the DT past a certain point will fail to return a value. Instead, upon reaching that character, the program will restart from the beginning.

Remember, or realize, that DT is actually a short form for a long list of retlw instructions. That means that having a DT holding a long string counts as many instructions.

This does NOT appear to be an issue of crossing the 2000 line limit, because I counted my lines and each character in the DTs, and I am still a good ways away from the next program memory page.

I spent hours working this out. Our book was not helpful at all. I had many theories and many false leads. Unless we hear official word from someone more experienced, my reccomendation would be to keep your DTs at or near the top of your code.

Comment by Yifan Wang on January 27, 2011 at 9:20am

also, you should keep the LCD.asm at the beginning of your program mem, say 0x0100, and your code can begin in some later time say 0x0150, so you have the rest of the program mem for your main code if you wish to separate your .asm files

Comment by Yifan Wang on January 27, 2011 at 9:18am

I've seen one of my student in my lab session came across the very same problem. The quickest way to fix this is just to have everything in the same .ASM file.

 

I haven't figured out exactly why the code is behaving this way, but the PC is set back to 0 in the function calls between the two .asm files, and thus making your code revert back to the beginning.

 

A good way to debug if you want to, is to find the register that store the return address of a function call, trace it, and see exactly at which point did your PC's value was erased. 

Comment by Valentin on January 27, 2011 at 1:05am

You shouldn't have to. Because tables take up a big chunk of program memory, they may also become a problem. I've looked over some of my code from last year and here is how it's structured:

 

----------------------------------------

;definitions

;equates

;variables

;macros

;vectors

org 0x00 ;reset vector (power on)

goto main

org 0x04 ;interrupt service routine

{ interrupt code here }

retfie ;return from interrupt

;tables:

Alphabet

addwf PCL,f

dt "ABC",0

return

;main program

main

{your main code}

END

----------------------------------

 

Unfortunately my code wasn't broken down into multiple source files (I had one huge one). But I remember that you have to be cautious with org statements in multiple source files.

 

A good way to debug would be to use the View Disassembly function in MPLAB as you step through the code with the debugger to see exactly when and where your program is jumping to another place. I have a feeling it never makes it to lcd.asm. Keep trying and updating!

Comment by Matt Nejati on January 26, 2011 at 11:20pm

I am using the LCD/Keypad sample code which I have just modified. I had already moved the LCD.asm code to begin at 0x500 and it wasn't working so I tried it at 0x700 and the same thing happened with no noticeable difference in how far the code went before jumping back to the beginning again. 

 

I am assuming this means I am going to have to move some of my code to a different page in memory for it to work?

Comment by Valentin on January 26, 2011 at 11:03pm

This problem has come up a number of times so I advise all microcontroller members to read the following.

 

From what I can tell:

You're using the LCD/Keypad sample code. In this code, your main.asm begins placing instructions at 0x000. However a number of subroutines are also outlined in lcd.asm. The key thing here is that lcd.asm begins at 0x100 (from what I can remember). Therefore, once the code in your main moves into this region, you have a conflict between the two source files trying to use the same program memory locations.

 

To fix this:

Try changing the "org 0x100" in lcd.asm to "org 0x300". This will move the LDC subroutines to 0x300 and on, and give you more space to write code in your main. 

Note: from what I can remember, lcd.asm takes up about 0x50 lines in total. So moving to 0x800-0x50 (length of one page minus length of lcd) will yield the most free space for main. I may be wrong in exact lengths so double check this.

 

Bottom line:

Be sure to organize your program memory and always keep an eye on its length, especially with multiple source files!