SV: [Icc-avr] Var is not working correct

Tue Nov 13 08:29:48 PST 2007

Off the wall question:

Have you looked at the assembly listing to see exactly what the code is (not) doing?  I know that I've found more of my C coding errors ( or compiler quirks) that way than any other way so far...

Cheers!

Rodney Pearson

Software Engineer

Juniper Systems, Inc.

www.junipersys.com

________________________________

From: icc-avr-bounces at imagecraft.com [mailto:icc-avr-bounces at imagecraft.com] On Behalf Of Steven Lose
Sent: Tuesday, November 13, 2007 7:47 AM
To: Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this.
Subject: SV: SV: [Icc-avr] Var is not working correct

Hi again.

Well, I must say that I don't know where to dig, it's a bit weird.

Here is an example:

In Eeprom.C

static unsigned int LastBufferAdr[TOTALNROFBUFFERS]; /* keep the last adr. that was used to save data */

void InitEeprom(void)
{
 unsigned int uii;
 unsigned int uiVarAdr;

 /* Load buffers */
 for(uii = 0;uii<TOTALNROFBUFFERS;uii++)
 {
  if(NROFUCHARBUFFERS>uii) /* Load unsigned chars */
  {

   Do some stuff

   uiVarAdr = some adr. 
  }
  else if( (NROFUCHARBUFFERS+NROFSINTBUFFERS)>uii ) /* Load signed ints */
  {
   Do some stuff

   uiVarAdr = some adr. 
  }
  else if( (NROFUCHARBUFFERS+NROFSINTBUFFERS+NROFFLOATBUFFERS)>uii ) /* Load floats */
  {
   Do some stuff

   uiVarAdr = some adr. 
  }

  LastBufferAdr[uii] = uiVarAdr;                   /* Save the adr. as the last one used to save data */

//  LcdVar32Xy(uiVarAdr,5,1,0,0,20+5*(uii/13),uii%13,DRAW);            <- uiVarAdr IS CORRECT
//  LcdVar32Xy(LastBufferAdr[uii],5,1,0,0,20+5*(uii/13),uii%13,DRAW);  <- LastBufferAdr[uii] IS CORRECT
 }
  for(uii = 0;uii<TOTALNROFBUFFERS;uii++)
   LcdVar32Xy(LastBufferAdr[uii],5,1,0,0,20+5*(uii/13),uii%13,DRAW);  <- LastBufferAdr[uii] IS WRONG, ALL IS 65535
}

I might be blind, I don't know, but I can't see it.

Inside the scope of for loop, LastBufferAdr[uii] holds the correct values.

Outside the scope all is 65535/0xFFFF

No interrupt is enabled at this time, and no WDT is enabled.

Any suggestions? 

Does ICC have a InitEeprom() and gets confused?

Med venlig hilsen / Best regards / mit freundlichen Grüßen

EC POWER A/S

Steven Lose

Software Ingeniør

Tlf.: +45 87434100

Direkte tlf. +45 58286608

Email: sl at ecpower.dk <blocked::mailto:bsl at ecpower.dk> 

www.ecpower.dk <http://www.ecpower.dk> 

________________________________

Fra: icc-avr-bounces at imagecraft.com [mailto:icc-avr-bounces at imagecraft.com] På vegne af Steven Lose
Sendt: 13. november 2007 09:43
Til: Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this.
Emne: SV: SV: [Icc-avr] Var is not working correct

Thanks.

The WDT is a pitfall where I have ended up before due to long start up times, but in this case I haven't enabled the WDT.

I newer really understood the WDT case. Why did it coarse a malfunction? Why did it not just boot forever?

I mean, if the WDT is not cleared frequently enough and is triggered, it should boot right! Not just result in some undefined stuff.

Well, it's another story.

Med venlig hilsen / Best regards / mit freundlichen Grüßen

EC POWER A/S

Steven Lose

Software Ingeniør

Tlf.: +45 87434100

Direkte tlf. +45 58286608

Email: sl at ecpower.dk <blocked::mailto:bsl at ecpower.dk> 

www.ecpower.dk

________________________________

Fra: icc-avr-bounces at imagecraft.com [mailto:icc-avr-bounces at imagecraft.com] På vegne af Richard
Sendt: 13. november 2007 08:50
Til: Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribe to icc-announce if you are a member of this.; Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this.
Emne: Re: SV: [Icc-avr] Var is not working correct

Just to clarify, barring any strange AVR EEPROM, use of #pragma etc, generally speaking, whether you initialize a static or global variable explicitly to zero or no explicit initialization is the location of the variable. In the former case, the initialize value (0) is copied from flash to RAM by the startup code. In the latter case, the whole "bss" section are initialized to zeroes by the startup code. In some rare cases, we have customers whose programs have so many global avriables that need either explicit or implicit initialization that they must disable the watchdog timer because the startup code is taking too long, but your description sounds like a different case.

At 11:11 PM 11/12/2007, Steven Lose wrote:

Hi Richard.

Ok, I start the chase in hope of catching a SW bug, I don't believe in lack of resource hence I had an extra 32K chip that I have enabled now.
I have a similar eeprom module running in another SW, and here the variables are not initialized and it is running on 5th year.
(or maybe I have newer discovered that there were something odd!!!!!, Naaa unthinkable ;o) )

I'll let the list know if I find something, or don't.

Med venlig hilsen / Best regards / mit freundlichen Grüßen
EC POWER A/S
Steven Lose
Software Ingeniør
Tlf.: +45 87434100
Direkte tlf. +45 58286608
Email: sl at ecpower.dk <blocked::mailto:bsl at ecpower.dk> 
www.ecpower.dk <http://www.ecpower.dk/> 

________________________________

Fra: icc-avr-bounces at imagecraft.com [ mailto:icc-avr-bounces at imagecraft.com <mailto:icc-avr-bounces at imagecraft.com> ] På vegne af Richard
Sendt: 13. november 2007 03:14
Til: Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribe to icc-announce if you are a member of this.; Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this.
Emne: Re: [Icc-avr] Var is not working correct

Sorry for not following up earlier - it should not make a difference. If it does, then you either have a program bug, a hardware misconfiguration, a compiler bug, or just plain running into lack of resources on the chip that happens to show up under one case.

I'd definitely not sweep this "under the rug." Something is not quite right.

At 07:11 AM 11/9/2007, Steven Lose wrote:

Could someone help me by explaining why my variable is not getting initialized correct?

In my Eeprom module, I have an array with information on all variables.
It's an array of struct like this:

typedef struct{
     unsigned int   uiEepromStartAdr;
     unsigned int   uiEepromEndAdr;
     unsigned char  ucBufferSize;
     unsigned char* ucpStaticRamData;
     unsigned char  ucMinValue;                 /* MinValue included */
     unsigned char  ucMaxValue;                 /* MaxValue included */
     unsigned char  ucDefaultValue;    /* Value to set if Value is <> Min or Max */
    }Uchar_Buffer_T;

The function InitEeprom() is then loading the values from Eeprom into memory and does a boundary check.
Works fine as long as the variable pointed to is initialised!
The variables is defined in module as global for the module
Like this:

static unsigned char ucK0SensorNr=0;   <= works
or
static unsigned char ucK0SensorNr;     <= does not work

The difference is only where the variable is put in memory.
I have printed out the adr. of the variable and the adr. Of the variable stored in array, they are equal and also equal to the adr. Shown in the ICC browser.

Just to make sure that it was not coursed my insufficient memory I enabled the extern memory, but did not help

Any suggestions?

// richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com)
_______________________________________________
Icc-avr mailing list
Icc-avr at imagecraft.com
http://dragonsgate.net/mailman/listinfo/icc-avr

// richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20071113/d6ca1697/attachment-0001.html