18F46K22 rom problem

Thread Starter

Shehwar Hussain

Joined Oct 26, 2014
21
Hey there,
I had been working on Led-Dotmatrix display project using PIC18F46K22. I used CCS-5.008 compiler. Problem i am facing is that i need to save alot of patterns in rom (using 'const' keyword) to display on Dotmatrix. If i save more than one pattern, nothing displays on dotmatix. Although the circuit has been tested with another PIC (18F452) and it works fine using same code. I suspect that patterns are being corrupted in ROM. Everything (circuit and code) has been tested using 18F452 but it doesn't work for 18F46K22.

I have checked all the fuses and configurations. They are all fine as a simple Led Blink program works on 18F46K22 but its not working with DotMatrix.

Can anyone throw some light whether its compiler issue or any other. Any help would be appreciated.
Thanks.
 

takao21203

Joined Apr 28, 2012
3,702
Nobody can know a thing from your post.

Its most likely a problem with the algorithm.

My guess it is mostly "dependent code", also containing direct IO assignments, a lot of constants, maybe too many global variables too.

"dependent" in a way if some situation throws off a line, the rest isnt doing what it is supposed to do, but hangs, does nothing, or produces garbage.

Some programmers for instance limit values which can produce out-of-bounds array access.
With
Code:
index_x&=0x1f;
you make sure it cant access at [32].

You dont have to spike your program with it, but its good practice for some critical things.
 

Thread Starter

Shehwar Hussain

Joined Oct 26, 2014
21
Nobody can know a thing from your post.

Its most likely a problem with the algorithm.

My guess it is mostly "dependent code", also containing direct IO assignments, a lot of constants, maybe too many global variables too.

"dependent" in a way if some situation throws off a line, the rest isnt doing what it is supposed to do, but hangs, does nothing, or produces garbage.

Some programmers for instance limit values which can produce out-of-bounds array access.
With
Code:
index_x&=0x1f;
you make sure it cant access at [32].

You dont have to spike your program with it, but its good practice for some critical things.
Thanks for replying. I don't agree with algo problem. There's a simple while loop that continuously display data on Dotmatrix. I can say this because i have tested it on PIC18F452. It works fine. I also placed some prints (to UART) in case of 18F46K22. It dumps data quite OK. If i need to put (say) 10 patterns to display, i'll surely put it in ROM. I donot have that many global variables or constants. One more thing is that, both PICs are pin compatible. So no direct IO problems.

What more can i post to make my problem more clear?
 

Thread Starter

Shehwar Hussain

Joined Oct 26, 2014
21
To make my problem more clear, i'll post an example code. Lets say we have two files, 'main.c' & 'patterns.c'.
main.c has the following data:
int const alpha[5] = { 1,2,3,4,5 };

and

patterns.c has the following data:
int const beta[5] = { 9,8,7,6,5 };

if i dump both arrays on UART,
alpha results out to be { 1,2,3,4,5 } and beta results as { 0,0,0,0,0 }; Although its correctly included in main.c from where i am accessing these arrays but it doesn't give right result.
 

takao21203

Joined Apr 28, 2012
3,702
Thanks for replying. I don't agree with algo problem. There's a simple while loop that continuously display data on Dotmatrix. I can say this because i have tested it on PIC18F452. It works fine. I also placed some prints (to UART) in case of 18F46K22. It dumps data quite OK. If i need to put (say) 10 patterns to display, i'll surely put it in ROM. I donot have that many global variables or constants. One more thing is that, both PICs are pin compatible. So no direct IO problems.

What more can i post to make my problem more clear?
Well thanks to you for keeping up a good conversation.
I just wrote some generic ideas about reasons.

You'd need to post your code, the more of it, the better. We have some members here, they can spot a mistake fast, which maybe, is hard to see for you.

Then you need to get to a point where you can find some ideas why it doesnt work, and test them one by one. First make sure there is no algorithm problem, or as you say, Compiler/PIC related issue.

These two PICs arent from same sub family so their registers, interrupts and so on, are different.

Can you single step some parts of it in MPLABX? And show the configuration fuse dump too from MPLABX.
 

takao21203

Joined Apr 28, 2012
3,702
To make my problem more clear, i'll post an example code. Lets say we have two files, 'main.c' & 'patterns.c'.
main.c has the following data:
int const alpha[5] = { 1,2,3,4,5 };

and

patterns.c has the following data:
int const beta[5] = { 9,8,7,6,5 };

if i dump both arrays on UART,
alpha results out to be { 1,2,3,4,5 } and beta results as { 0,0,0,0,0 }; Although its correctly included in main.c from where i am accessing these arrays but it doesn't give right result.
I think I have an idea about that.

You need to re-declare the variable everywhere you use it with
Code:
extern int const beta[5];
Then you need to declare it one time without the extern keyword.

If you re-declare it, its just a different identifier. You need to work with .h files properly in such a case.

Maybe that is the problem already. Just trying. But its essential if you want to share access spanning over several .c files

I think the .h file also just has the decleration with extern, and it doesnt matter where it actually resides (could be really external from an .obj file). The compiler finds it one time somewhere, then when using the variable identifier it knows its "extern", and refers to the one instance it found.
 

Thread Starter

Shehwar Hussain

Joined Oct 26, 2014
21
I am CCS-IDE, with compiler version 5.008.
Configurations are:

#FUSES NOWDT //No Watch Dog Timer
#FUSES PUT //Power Up Timer
#FUSES BORV29 //Brownout reset at 2.85V
#FUSES NOPBADEN //PORTB pins are configured as digital I/O on RESET
#FUSES NOHFOFST //High Frequency INTRC waits until stable before clocking CPU
#FUSES NOSTVREN //Stack full/underflow will not cause reset
#FUSES NOLVP //No low voltage prgming, B3(PIC16) or B5(PIC18) used for I/O
#FUSES NOXINST //Extended set extension and Indexed Addressing mode disabled (Legacy mode)
#FUSES INTRC_IO //Internal Oscillator, no CLKOUT
#FUSES PLLEN //HW PLL enabled
#FUSES NODEBUG //No Debug mode
#use delay (clock = 32000000)

#use standard_io(A)
#use standard_io(B)
#use standard_io(C)
#use standard_io(D)
#use standard_io(E)
 

Thread Starter

Shehwar Hussain

Joined Oct 26, 2014
21
@takao21203
Yeap, that might be possibility. I'll try that and post the results. But i am half sure it won't because it is working in case of 18F452. I am able to access each and every byte correctly in 18f452 case. But thanks for showing up.
 

takao21203

Joined Apr 28, 2012
3,702
Well in such a case, I single step it, check address reference to the array, and see why access is made to different area, or why result is 0.

In MPLABX you can hover over variables, when the simulator is at HALT. Its quite useful.
 

ErnieM

Joined Apr 24, 2011
8,377
To make my problem more clear, i'll post an example code. Lets say we have two files, 'main.c' & 'patterns.c'.
main.c has the following data:
int const alpha[5] = { 1,2,3,4,5 };

and

patterns.c has the following data:
int const beta[5] = { 9,8,7,6,5 };

if i dump both arrays on UART,
alpha results out to be { 1,2,3,4,5 } and beta results as { 0,0,0,0,0 }; Although its correctly included in main.c from where i am accessing these arrays but it doesn't give right result.
Well that has zero informative value.

How does an array get "dumped" onto the UART?

Is there a debugger available to inspect the data?

Statements such as "Although its correctly included in main.c from where i am accessing these arrays but it doesn't give right result." are fairly meaningless. Posting how the arrays are included is essential in someone seeing where your mistake is.

After all, if a mistake did not exist the part about "but it doesn't give right result" would not be there.
 

Thread Starter

Shehwar Hussain

Joined Oct 26, 2014
21
@ErnieM Array values are dumped in the following way:
say we have a variable unsigned char x;

for(i=0; i<5; i++)
{
x = alpha[ i ];
SendByteSerially(x);
}

and for the case of including files. In main.c, i included other file as #include "patterns.c" and patterns.c has that 'beta' array.
 

ErnieM

Joined Apr 24, 2011
8,377
#including a dot c file is not the recommended procedure so I am not sure how it works with your compiler. Normally each dot c file is compiler separately and the linker merges the objects, and dot h files are used to make the symbols match across objects.
 

takao21203

Joined Apr 28, 2012
3,702
#including a dot c file is not the recommended procedure so I am not sure how it works with your compiler. Normally each dot c file is compiler separately and the linker merges the objects, and dot h files are used to make the symbols match across objects.
Its kindof archaic, would need to dig about specification. Assembler programmers do that.
Support for it might be non-standartized.

Its not modern or desireable C programming practice. Please, dont chain up .c files, create proper .h files, and use extern directives for symbol sharing accross files.

I'm not even sure if the extern definition is in the .h file too, but there are countless small additions to the rules, which over time, you just have to know. Its almost impossible to write step-by step failsafe instructions.

From using the simulator, you can improve fast, and learn correct techniques too.
 
Top