Jump to content

Recommended Posts

I've run into a huge problem when using BoostC under MPLAB IDE and ICD2. The code runs fine if I

use the simulator. When I run the same code on the ICD2 "ptr1" gets trashed with a random value.

I've tried working around this by passing an argument directly to the dummy routine instead of

a pointer. No luck, the argument gets trashed. I wrote this sample code as a simplified version of my project. BTW, I'm monitoring x and ptr1 in an MPLAB watch window.

 

I'm in a bind here, I've got a big project and no way to run it under ICD2! Am I doing something wrong?

 

 

#include <system.h> //The target micro is an 18F2450

#include <icd2.h>

 

//Configuration Fuses

#pragma DATA _CONFIG1L,_PLLDIV_2_1L&_CPUDIV_OSC1_PLL2_1L //Config1L options

#pragma DATA _CONFIG1H,_FOSC_HS_1H&_FCMEM_OFF_1H&_IESO_OFF_1H //Config1H options

#pragma DATA _CONFIG2L,_PWRT_ON_2L&_BOR_OFF_2L&_BORV_21_2L //Config2L options

#pragma DATA _CONFIG2H,_WDT_OFF_2H&_WDTPS_1_2H //Config2H options

#pragma DATA _CONFIG3H,_MCLRE_ON_3H&_LPT1OSC_OFF_3H&_PBADEN_OFF_3H //Config3H options

#pragma DATA _CONFIG4L,_STVREN_OFF_4L&_LVP_OFF_4L&_BBSIZ_BB1K_4L&_ICPRT_OFF_4L&_XINST_OFF_4L&_DEBUG_ON_4L

#pragma DATA _CONFIG5L,_CP0_OFF_5L&_CP1_OFF_5L //Config5L options

#pragma DATA _CONFIG5H,_CPB_OFF_5H //Config5H options

#pragma DATA _CONFIG6L,_WRT0_OFF_6L&_WRT1_OFF_6L //Config6L options

#pragma DATA _CONFIG6H,_WRTB_OFF_6H&_WRTC_OFF_6H //Config6H options

#pragma DATA _CONFIG7L,_EBTR0_OFF_7L&_EBTR1_OFF_7L //Config7L options

#pragma DATA _CONFIG7H,_EBTRB_OFF_7H //Config7H options

 

 

#pragma DATA 0xF00, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF

#pragma DATA 0xF08, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF

#pragma DATA 0xFF0, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF

#pragma DATA 0xFF8, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF

 

 

void dummy(char *ptr1); //function prototype for dummy routine

 

char x; //demo variable

 

char *ptr1; //General purpose pointer

 

 

 

//Begin executable code

 

void main(void)

{

x=2;

ptr1=&x;

x=x+1;

 

while (1)

{

dummy(ptr1);

}

}

 

 

void dummy(char *ptr1) //when execution jumps here ptr1 gets trashed

{

*ptr1=*ptr1+1; //change x by indirect reference

}

Share this post


Link to post
Share on other sites
I've run into a huge problem when using BoostC under MPLAB IDE and ICD2.  The code runs fine if I

use the simulator.  When I run the same code on the ICD2 "ptr1" gets trashed with a random value.

I've tried working around this by passing an argument directly to the dummy routine instead of

a pointer.  No luck, the argument gets trashed.  I wrote this sample code as a simplified version  of my project.  BTW, I'm monitoring x and ptr1 in an MPLAB watch window.

 

I'm in a bind here, I've got a big project and no way to run it under ICD2!  Am I doing something wrong?

Does the small program you have provided demonstrate the problem, or is it just when you run you large program?

 

Make sure that you use linker -rt option to reserve the ROM required for ICD2.

 

Regards

Dave

Share this post


Link to post
Share on other sites

Aegis-tec,

 

The must be some bugs/problems with MPLAB.

If you look at the addresses of the variables in variable watches, you find that some of them are incorrect, so they are showing data from the wrong locations and hence the wrong value.

 

If you actually look at the file registers at the correct address, you find that the data there is correct.

 

Everything works correctly with MPLABs simulator, that means the contents of the coff file (debug info) must contain the correct addresses of the variables.

 

So the code executes correctly, its just the variable watching in MPLABs when using ICD2 that tells some lies ;-)

 

So sadly there is not much we can do about that.

It would be worth reporting the problem to Microchip, then it might get fixed in a future release.

 

Regards

Dave

Share this post


Link to post
Share on other sites
Aegis-tec,

 

The must be some bugs/problems with MPLAB.

If you look at the addresses of the variables in variable watches, you find that some of them are incorrect, so they are showing data from the wrong locations and hence the wrong value.

 

If you actually look at the file registers at the correct address, you find that the data there is correct.

 

Everything works correctly with MPLABs simulator, that means the contents of the coff file (debug info) must contain the correct addresses of the variables.

 

So the code executes correctly, its just the variable watching in MPLABs when using ICD2 that tells some lies ;-)

 

So sadly there is not much we can do about that.

It would be worth reporting the problem to Microchip, then it might get fixed in a future release.

 

Regards

Dave

 

 

I also ran into this problem and reported this problem in a microchip forum about two weeka ago.

There was no reply yet.

Is there a chance that this is a BoostC problem?

Share this post


Link to post
Share on other sites
Aegis-tec,

 

The must be some bugs/problems with MPLAB.

If you look at the addresses of the variables in variable watches, you find that some of them are incorrect, so they are showing data from the wrong locations and hence the wrong value.

 

If you actually look at the file registers at the correct address, you find that the data there is correct.

 

Everything works correctly with MPLABs simulator, that means the contents of the coff file (debug info) must contain the correct addresses of the variables.

 

So the code executes correctly, its just the variable watching in MPLABs when using ICD2 that tells some lies ;-)

 

So sadly there is not much we can do about that.

It would be worth reporting the problem to Microchip, then it might get fixed in a future release.

 

Regards

Dave

 

 

I also ran into this problem and reported this problem in a microchip forum about two weeka ago.

There was no reply yet.

Is there a chance that this is a BoostC problem?

This problem was resolved in V6.70 (see the version log http://www.sourceboost.com/CommonDownload/VersionLog.html ), its was caused by use of local auto variable types in coff file. In MPLAB when local auto variables are used the variable offset is combined with the contents of SFR register and this is the address that MPLAB displays the contents of. This was fixed by changing the type of variables contained in the coff file.

 

Regards

Dave

Share this post


Link to post
Share on other sites

I also ran into this problem and reported this problem in a microchip forum about two weeka ago.

There was no reply yet.

Is there a chance that this is a BoostC problem?

This problem was resolved in V6.70 (see the version log http://www.sourceboost.com/CommonDownload/VersionLog.html ), its was caused by use of local auto variable types in coff file. In MPLAB when local auto variables are used the variable offset is combined with the contents of SFR register and this is the address that MPLAB displays the contents of. This was fixed by changing the type of variables contained in the coff file.

 

Regards

Dave

 

Dave,

 

I just installed V6.8 and it didn't help.

I installed by running sourceboost.exe.

 

Is there something that I missed?

Share this post


Link to post
Share on other sites

OrmatEli,

I just installed V6.8 and it didn't help.

I installed by running sourceboost.exe.

 

Is there something that I missed?

I can't think what.

 

If you can provide a simple example MPLAB project demonstrating the issue we can investigate.

 

Regards

Dave

Share this post


Link to post
Share on other sites
If you can provide a simple example MPLAB project demonstrating the issue we can investigate.

 

#include <system.h>
#include "RunTrial.h"
#include <icd2.h>
#include <stdio.h>

#pragma 	DATA 	_CONFIG1H, 	_OSC_HS_1H		//	highspeed crystal oscillator
#pragma	DATA	_CONFIG2L,	_PWRT_OFF_2L	//	Turn PWRT (Power-up Reset Timer) off
#pragma 	DATA 	_CONFIG2H, 	_WDT_OFF_2H	  //	watchdog timer off
#pragma	DATA	_CONFIG4L,	_DEBUG_ON_4L & _LVP_OFF_4L 	// Background debugger enabled, RB6 and RB7 are dedicated to In-Circuit Debug
#pragma	DATA	_CONFIG5L,	_CP0_OFF_5L & _CP1_OFF_5L & _CP2_OFF_5L
#pragma	DATA	_CONFIG5H,	_CPB_OFF_5H & _CPD_OFF_5H 
#pragma	DATA	_CONFIG6L,	_WRT0_OFF_6L & _WRT1_OFF_6L & _WRT2_OFF_6L
#pragma	DATA	_CONFIG6H,	_WRTB_OFF_6H & _WRTC_OFF_6H & _WRTD_OFF_6H
#pragma	DATA	_CONFIG7L,	_EBTR0_OFF_7L & _EBTR1_OFF_7L & _EBTR2_OFF_7L
#pragma	DATA	_CONFIG7H,	_EBTRB_OFF_7H

#define  CondT_ADcon0   0b00001001  //=9  enable capture from channel AN2
#define  BATV_ADcon0	   0b00100001	//=33 enable capture from channel AN8
#define  OECV_ADcon0	   0b00100101	//=37 enable capture from channel AN8

signed int ConDTemp, OECVoltage, BatteryVoltage;

typedef struct 
{
unsigned int 	A; 
unsigned int	B;
unsigned int	c;
unsigned int	reg;
} CaptureStruct;

volatile CaptureStruct CondT_capture, OECV_capture, BatV_capture;


void A2DRead()
{
switch (adcon0)
  {
  case CondT_ADcon0 : 					// capture condenser temperature	   
	 CondT_capture.reg = adres;	 					// read conversion		
	 adcon0= OECV_ADcon0;		 // next capture: Load current				
  break;

  case OECV_ADcon0 :
 		OECV_capture.reg = adres;
	 adcon0= BATV_ADcon0;
  break;

  case BATV_ADcon0 :
 		BatV_capture.reg = adres;
	 adcon0= CondT_ADcon0;
  break;

}	
}


void interrupt (void)
{
if (pir1.ADIF)
{
	A2DRead();
pir1.ADIF=0;
	adcon0.GO=1;
}
}

signed int getReading(CaptureStruct CapSt)
{
static signed int temporaryPar; // temporary parameter for storing intermediate results 

  pie1.ADIE=0;
  temporaryPar   = CapSt.reg * CapSt.A; 
  temporaryPar   = temporaryPar / CapSt.B;			 // then multiply
  temporaryPar	= temporaryPar - CapSt.c;
  pie1.ADIE=1;
  return temporaryPar;
}

void main()
{
CondT_capture.A =	16; 
CondT_capture.B =	25;
CondT_capture.c =  263;

OECV_capture.A =	13; 
OECV_capture.B =	4;
OECV_capture.c =  0;

BatV_capture.A =	13; 
BatV_capture.B =	2;
BatV_capture.c =  0;

intcon.GIE=1;
intcon.PEIE=1;

trisa.2 = 1;
trisa.1 = 1;
trisf.3=1;
trisf.4=1;


adcon1 = 0b00000101;
adcon2 = 0b10011101; 

adcon0=CondT_ADcon0;
adcon0.1 = 1; //initiate A2D conversion

pie1.ADIE=1;
pir1.ADIF=0;
ipr1.ADIP=1;


// EUSART1 configuration
//RCSTA1.SPEN

trise.0 = 0;
trise.7 = 0;
trisd.3 = 1;
trisd.4 = 1;

//portb.5 = 1; //D117

while(1)
{
	porte.0 =	portd.3; 	// D122
	porte.7 = 	portd.4;		// D123
	ConDTemp 	= 	getReading(CondT_capture);
	OECVoltage	=	getReading(OECV_capture);
	BatteryVoltage = getReading(BatV_capture);
}


}

 

What the program does is manage multiple analog inputs.

The CaptureStruct struct stores the parameters for transforming the A2D readings into engineering units (getReading routine).

 

Both the CaptureStruct parameters and the reading come out corrupted.

 

OrmatEli

Share this post


Link to post
Share on other sites

I have a similar app using ICD2, MPLAB & SourceBoost. I found that a value in the correct position but the wrong RAM bank was being updated. I switched off optimisation and the problem went away. I tried this idea as I read of a similar problem in another thread (can't find it now)

Share this post


Link to post
Share on other sites
I have a similar app using ICD2, MPLAB & SourceBoost. I found that a value in the correct position but the wrong RAM bank was being updated. I switched off optimisation and the problem went away. I tried this idea as I read of a similar problem in another thread (can't find it now)

 

 

Thanks, :)

 

It seems to help.

 

Is this a bug in MPLAB or Boost C?

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...