Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Help, my code is crashing when data table is called

Status
Not open for further replies.

holax12

New Member
Hello,

Thanks for stopping by, am making a 7x5 display with pic16f628a.
i have set up the code properly to the best of my understanding but one problem persist and its really giving me headache. Each time i call the table that contains the text to be displayed, the program jumps to an unintended location. Attached is the copy of the asm code.



BEGIN
call text ;
CLRF TTEMP2
MOVWF TTEMP2
;
;
;
TEXT
incf TTEMP1, f
movfw TTEMP1
addwf PCL ;program jumps to text and crashed
 
Its a bit long of a program from what I could see. have you tried putting the table at the beginning of your main routine? you might be going over the page boundery. also jfyi you might want to start commenting your codes more, its helps to get into the habit of doing it, I never used to, but later I learned it helps :)
 
Sounds like you've got a problem with paging. You've got a large table and you're only manipulating PCL. Look up how to deal with large tables using PCLATH.
 
Have you tried simulating the code in MPLAB?

I find that using the breakpoint and single step functions there to be quite valuable in finding why my code doesn't do what I intended it to.
 
Move the subroutine "text" to just before the label "start" and it should work fine. Alternatively, change your tables code so it works in any bank - it currently will only access the first 256 bytes of flash.

Mike.
 
I've had this mamy times ans stared at the screen trying to find out why.
Adding to pcl as the term implies only adds to the lower byte of the program counter, if the 256 page boundary is crossed the jump will be incorrect quite often sending the pic backwards location wise.
When I use a lookup table I usually assemble the proyhgram then look a the xxx.lst list file and look at the adress the table starts, then go back to the assembler listing and set pclath to the correct page just before the add to pcl is performed, also if the table crosses a page boundary you can use the org command to postion the assembly of the table at the start of a page.
Despite what might be said you can have 256 loactions in a lookup table with a single add to the pcl, I have software that does it.
 
Last edited:
@ dr pepper and pommie, can you please write a simple code that does what you pointed out. Thanks for your responses
 
;
; this lookup table is in page 2 of the pics memory 0x200 to 0x2ff
;
table movlw d'2'
movwf pclath
;
movf tablepointer,w
addwf pcl,f
;
retlw first table entry
retlw second table entry
etc,etc


After initial assembly you know which page the lookup table is, in this example I assumed it was page 2 (0x200 to 0x2ff), you have to make sure that the table length doesnt go over the end of the page (in this example 0x2ff), when I use short lookup tables say 25 lines then anywhere in the page is fine at least for later pics (not p16c5x series), also its good practice to check the value used to add to the pcl before actually adding it, and if its greater than the number of lines in the table do something about it, I sometimes reserve the first entry in the table as a jump to an error handler.
 
@dr pepper, thanks for your urgent response, I have two questions to ask you:

1. Is it within the table subroutine that I will move the page number to the pclath or before calling the table

2. How do I know where a page starts and end in pic16f628a and for any other PIC that uses paging.
 
Ok then,

If your lookup table is a short one (less than 250 lines approx) then you can load the value into pclath within the same sub where the lookup table is situated (and this is good practice esp if the routine can be called from more than one place in the software), in my example you can see the label 'table', I load up pclath straight after the software calls 'table'.

You can count the lines of assembler to work out exactly where the table starts in the pics memory, I cant be bothered and just write the software and use a dummy value to load into pclath (2 in my example), then assemble the code, then open the .lst file that the assembler generates (you might have to enable the list file generator on your assembler) and look at the page the table is situated in, I think the first or second column of the .lst file is the address in hex, the third and fourth least significant bits are the page number, 00 page zero, 01 page 1, 10 page 2 etc, then just go back and edit the dummy value with the actual page number.

You can if your lazy put the lookup table right at the start of the code listing to guarrantee that the lookup table is within page zero, because pclath resets to zero you can then just forget all about pclath and write the code as per normal.

All this only applies to absolute code.
 
Last edited:
@dr pepper, thanks a lot , your posts have been really helpful to me. I would like to contact you more, my email is holax12@yahoo.com. Please kindly inbox me so that I can know your contact mail.
 
Your right of course Nigel, if a prgram works ok and took less time and bother then I spose its good practice.
My last few programs had 256 byte lookups, and you cant do this in page0 as the first few bytes are needed for reset and interrupt vectors.
Some think you cant have 256 byte lookup tables, you can with a couple of tricks.
I'm not an expert on pics but I've had some proper hum dingers with bugs.
 
Last edited:
Your right of course Nigel, if a prgram works ok and took less time and bother then I spose its good practice.

It is - it would be bad practice to ignore it.

I commonly stick a 16 byte table in page zero for hexadecimal conversions, it avoids any problems, and means it's smaller and faster than putting it elsewhere.

My last few programs had 256 byte lookups, and you cant do this in page0 as the first few bytes are needed for reset and interrupt vectors.
Some think you cant have 256 byte lookup tables, you can with a couple of tricks.
I'm not an expert on pics but I've had some proper hum dingers with bugs.

My tutorials include various types of tables, including unlimited sized ones.

But if you move to the enhanced 16F1827 tables become even easier - and with even more options :D
 
Thats interesting, I've been thinking how I'd implement a 16 bit lookup, maybe lower 8 bits added to the program counter and higher bits added to pclath to select the page, well maybe not 16 bit for a 16f series, but I'd get more than just 256 entries.
I'll check out the tutorials.
 
Last edited:
Thats interesting, I've been thinking how I'd implement a 16 bit lookup, maybe lower 8 bits added to the program counter and higher bits added to pclath to select the page, well maybe not 16 bit for a 16f series, but I'd get more than just 256 entries.
I'll check out the tutorials.

The 8x8 LED matrix ones uses large tables, one for the scrolling text data, and one for the font data.
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top