Jump to content
Loreto

Unexpected Behaviour With Ram Variables

Recommended Posts

I'm encountering a strange problem using BoostC.

I'm going to create a project using several devices and I'll need several variables and a large use of RAM.

I'm going to use uP PIC18F2525.

 

The first routine I realized were the LCD routines and I think that they works properly now.

I can select 2 wires or 6 wires to control LCD. In the attached file you see the 2 wire using the shift register.

All along I noticed a strange behaviour on the strings/data located in RAM memory.

Some variables that were correctly displayed at one time, were garbaged after adding other variables.

To solve the problem I tried to move as soon as all data to ROM memory. But now I cannot go ahead anymore.

To understand the problem I cut a lot of code and now I'm goig to ask for any support or suggestion.

This is my main()

/***************************************************
* M A I N 
*************************************************** */
#include 	"TMR0.h"
void main() {
Init_Registers();
initPorts();
LCD_initialize();
LCD_Clear();

while (1) {
	TMR0_GATE_LINE  = 0;				//Turn OFF LED
	LCD_print(0,0,	"Line1");							// line 10
	LCD_printf(0,7,   ":%03d ", 54);				   // line 11
	LCD_printRom(1,0, "Line2");   
	delay_s(1);
	TMR0_GATE_LINE  = 1;				//Turn ON  LED
	delay_s(1);	}}


/**********************************
* Print ROM String to LCD		*
**********************************/
void LCD_printRom(unsigned char LcdLine, unsigned char LcdColumn, rom unsigned char *text) {
LCD_gotoRC( LcdLine, LcdColumn);
LCD_printRom( text );
}

/***************************************************
* Print ROM String to LCD at current Cursor position 
*************************************************** */
void LCD_printRom( rom unsigned char *string ) {
char pi = 0, c;
LCD_MODE = Mode_DATA;		  // Set LCD Data MODE
while( 1 )  {
	c = string[pi++]; 
	if ( !c ) return;
	LCD_sendByte( c );  // Display on LCD
}}


/***************************************************
* Print String to LCD at Row, Column *
*************************************************** */
void LCD_print(unsigned char LcdLine, unsigned char LcdColumn, unsigned char *text) {
LCD_gotoRC( LcdLine, LcdColumn);
LCD_print( text );
}

/***************************************************
* Print String to LCD at current Cursor position 
*************************************************** */
void LCD_print( const unsigned char *string ) {
char pi = 0, c;
LCD_MODE = Mode_DATA;		  // Set LCD Data MODE
while( 1 )  {
	c = string[pi++]; 
	if ( !c ) return;
	LCD_sendByte( c );  // Display on LCD
}
}


/**********************************
* SET LCD Cursor Position		*
**********************************/
void LCD_gotoRC( unsigned char LcdLine, unsigned char LcdColumn) {
LCD_MODE = Mode_CMD;		   // Set LCD Command MODE
LCD_sendByte(0x80 + LcdLine*0x40 + LcdColumn);}

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

Note: The file "TMR0.h" contains definitions regarding variables NOT used by program.

 

The program works fine but if I remove the <#include "TMR0.h">

the first line of LCD is BLANK (seems that lines 10 and 11 don't work anymore).

 

Tracing the program with BoostC I see that all the right characters are sent to the LCD_sendByte() with or without #include.

My feel is that inside the PIC LCD_printRom() see the right string and LCD_print() see a NULL string and the routine exits on line

<if ( !c ) return;>

 

Analysing the compilation output fileGOOD.casm fileERR.casm, the main differences consists to use BANK switch on fileGOOD.casm.

 

I attached the main routines used for the LCD output. I didn't insert <LCD_sendByte()> because it's the same for LCD_print and LCD_printRom

My question is: Why adding or removing UNUSED variables on program, the PIC behaviour changes??

Can anywone help me to understand where is my mistake ????

I attached the fileGood.casm and fileERR.casm.

Thank You

 

Loreto

Loreto.zip

Edited by Pavel
Wrong code formatting

Share this post


Link to post
Share on other sites

I had a very similar problem and the only fix was to turn off optimisation. I found that a variable in a completely different bank was being updated (using ICD2, same offset but different bank). I could change which variable was incorrectly updated by adding or removing unused variables. I hope I am wrong so I can turn optimisation back on but until then .....

Share this post


Link to post
Share on other sites

Please try release candidate 6.85 that was just released. In it we have reworked compiler core that deals with complex expressions to improve generated code reliability. This might be one of those cases when these compiler improvements may help.

 

Regards,

Pavel

Share this post


Link to post
Share on other sites

I just downloaded version 6.85 and the problem is the same.

The file.hex is exactly the same as version 6.84.

I tried also to remove the optimization (-O0 on both assembling and linkedit steps) without positive results.

It seems that the string pointer passed to the RAM routine is pointing to a 0x0 filled area. Rarely a garbage character appears just to indicate that it's pointing wrong area.

I don't know why but the debugger shows the correct strings.

 

Do you have any other suggestion??

Regards

Ciao

Loreto

Share this post


Link to post
Share on other sites
...Do you have any other suggestion??...

 

To fix this problem we need to be able to reproduce it. A zipped project and instructions of steps to reproduce the problem sent to support@sourceboost.com will help.

 

Regards,

Pavel

Share this post


Link to post
Share on other sites
...Do you have any other suggestion??...

 

To fix this problem we need to be able to reproduce it. A zipped project and instructions of steps to reproduce the problem sent to support@sourceboost.com will help.

 

Regards,

Pavel

 

I'm going to prepare the package and I'll send it you.

Thanks

Share this post


Link to post
Share on other sites

I am having a similar kind of problem. I am building a telemetry system for model aircraft, which sends data down to the ground using a Radio modem. The data is sent on a timer interrupt, with some analogue inputs, and a GPS receiver. I am using the PIC16F767, and lately changed to PIC16F886. The GPS strings are stripped and only the required info is used.

 

I have a static transmit buffer, which has fixed header information, except for a packet counter, and the variables are unpdated in the main loop, and the data is sent using the TX interrupt till the buffer is complete. The problem I experienced is that some of the data seems to get corrupted. I use a TX busy flag to stop the buffer being updated during the data transmission. To speed up processing, I wanted to just update the variables, but it turns out that it is only valid for the first iteration, there after they are garbage. To get around this, I have to rewrite the buffer before sending it.

 

I don't know if this is a problem, but each module is contained in a separate file, e.g. GPS processing, analogue inputs, serial transmittting and packetising. I had thought of putting all the buffers in the main program, and just pass pointers to them, or do the transmission of the data in the main loop, with just a flag to start the transmission. I had to increase the processor speed to 8MHz to cope with the GPS processing. There was quite a bit of footwork to process the GPS strings without storing the entire string in memory.

 

I am using MPLAB 8.0 IDE with the ICD2 for programming and debugging.

Share this post


Link to post
Share on other sites

Loreto,

A zipped project was sent to support last Saturday.

I don't know if a forum update is required.

This is just it.

Adding and removing your #include "TMR0.h" will change the code because in this file there is a global array that causes some initialisation code to be added to the program.

 

I have tried the files you sent and can't see a problem. I used the LCD plugin in the SourceBoost Debugger, and for both cases the same characters are displayed on the LCD.

 

Can you please try this?

 

The only thing I can think of is that maybe you timimg for LCD data writing is borderline and the additional code added for the initialisation of global data in TMR0.h changes some other code slightly as everything gets moved around in memory and the delays aren't as big as they used to be, so display writes fail. The plugin may succeed as its signal timing is more tolerant than an actual display.

 

Regards

Dave

Share this post


Link to post
Share on other sites

Ciao Dave,

thank you for your answer and for your time.

I'm sure that you are right.

Using the LCD plugin you can see the code working properly. In fact using the simulator I don't see any problem.

The problem arises after writing the code into PIC memory.

 

To have a better understand about the problem, I inserted two displays (4 bits to 7 segments) on PortC to capture the output bytes. I inserted a 1 sec sleep before sending out characters on PortC.

 

I see the output bytes related to LCD initialization and to the following line :

	LCD_printRom(1,0, "Line2");			// LineROM 1

 

 

but I don't see the bytes related to the following lines:

	LCD_print(0,0,	"Line1");			// lineRAM 1
LCD_printf(0,7,   ":%03d ", 54);	   // lineRAM 2

 

This is discordant to the simulator view (where all the characters are displayed).

For this reasons my feel is that, probably, the simulator doesn't correctly map PIC Hardware behaviour.

 

It seems that the pointer passed to the function LCD_print(..., *text):

void LCD_print(unsigned char LcdLine, unsigned char LcdColumn, unsigned char *text) {
LCD_gotoRC( LcdLine, LcdColumn);
LCD_print( text );
}

void LCD_print( const unsigned char *text) {
unsigned char pi = 0, c;

LCD_MODE = Mode_DATA;		  // Set LCD Data MODE
while( 1 )  {
	c = text[pi++]; 
	if ( !c ) return;		  // EXITING line
	LCD_sendByte( c );		 // Display on LCD
}
}

 

is pointing to a NULL area and NO bytes are sent to PortC (see <if ( !c ) return;>).

 

If the problem was due to a LCD timing, I would expect to see all the characters and not only the ROMs.

 

What wrote jknichel is another aspect of RAM mulfunctions (garbage characters) I encountered too, but I'm focalized on this problem just because I was able to re-create it.

 

If you have a time I would invite you to prepare a simple HW circuit with PIC and LCD/LEDs (LED display could be better to avoid LCD timing) and varify the PIC behaviour.

 

Anyway I'm available to perform any tests and to pickup any suggestion.

 

I don't know if my thinking is clear, and I apologize for my english.

 

Thank you again for your time.

 

Regards

Loreto

Share this post


Link to post
Share on other sites

Ciao Dave,

I have a little news and I need your help to understand if this news is important or not!

 

I tried to compile the same project, I sent you, with MPLAB (using SourceBoost as toolsuite) and I got a MsgBox error which states as follow:

"The Extended CPU Mode configuration bit is enabled, but the program that was loaded was not built using extended CPU instructions. Therefore, your code may not work properly."

PIC18F2525 technical reference states:

Extended Instruction Set: The PIC18F2525 family introduces an optional extension to the PIC18 instruction set, which adds 8 new instructions and an Indexed Addressing mode. This extension, enabled as a device configuration option, has been specifically designed to optimize re-entrant application code originally developed in high-level languages, such as C. .... The mapping of the Access Bank is slightly different when the extended instruction set is enabled (XINST configuration bit = 1).

 

I modified my #PRAGMA data to include _XINST_ON_4L bit but I was not able to remove the MSGBox Error.

I attached the MsgBox error (.DOC) and chapter regarding the Data Addressing modes (.PDF) for PIC18F2525.

 

Do you think that this error could address my problem??

What about SourceBoost Extended Instruction set???

Why SourceBoost IDE doesn't issue Extended Instruction Set Error???

 

I'm exausting the tests so I'll appreciate any your suggestions..

 

P.S. I noted that MPLAB C18 have two library called 18f2525_e.lkr (extended Instruction Set) and 18f2525.lkr.

Could be I missed the BoostC extended library???

 

Ciao

Loreto

LoretoDOC2.zip

Share this post


Link to post
Share on other sites

I suspect that SourceBoost C does not support the extended instruction set so you will have to remove the setting from the config word to stop MPlab grumbling when the hex file is loaded I would think.

 

If you instist on using the extended instruction set, you may have to resort to using C18 non-student version.

 

Cheers

 

Reynard

Share this post


Link to post
Share on other sites

Hi Reynard,

I don't insist to use extended instruction set.

I just reported them because I got error running a project using SourceBoost under MPLAB env (see attached DOC).

 

My goal is to have a working code using BoostC and nothing more.

 

Regards

Loreto

Share this post


Link to post
Share on other sites

Join the conversation

You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...