2106 | ADC | ARM7 | Atmel | Bootloader | CAN | CrossStudio | CrossWorks | DDS | ECos | Ethernet | ETM | FIFO | FLASH | FPGA | GCC | GDB | GNU | GNUARM | GPIO | I2C | IAP | IAR | JTAG | Kickstart | LCD | Linux | LPC | LPC-E2294 | LPC2000 | LPC2100 | LPC2104 | Lpc2106 | Lpc210x | LPC2114 | LPC2119 | LPC2124 | LPC2129 | Lpc2138 | LPC213x | LPC21xx | LPC2210 | LPC2212 | LPC2214 | LPC2292 | LPC2294 | LPC2xxx | LPC3128 | MCB2100 | Olimex | Philips | PWM | Rowley | RTC | RTOS | SPI | SSP | UART | UART0 | UART1 | ULINK | USB | Watchdog | Wiggler

Every now and then on enumeration, I get a EP_SLOW interrupt in
USBDevIntSt, but nothing in USBEPIntSt. The next EP_SLOW interrupt is
OK. Why is that?

Also, in my Keil GUI, anybody had any issues with variables out of scope
when they aren't? I have some issues when coming out of routines, local
variables are all of a sudden out of scope. Sometimes, I have to create
bogus dummy variables and set them to the 'out of scope' variable.
Then, they become 'in scope'.
--
Sutton

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



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, Sutton Mehaffey wrote:
>
> Also, in my Keil GUI, anybody had any issues with variables out of scope
> when they aren't? I have some issues when coming out of routines, local
> variables are all of a sudden out of scope. Sometimes, I have to create
> bogus dummy variables and set them to the 'out of scope' variable.
> Then, they become 'in scope'.

I don't know specifically about the Keil debugger but these sorts of issues are typically related to optimisations that a compiler has performed on your behalf. For predictable behaviour I recommend using the compiler settings that result in no optimisation. Concentrate on designing your algorithms to best meet any performance requirements. You should only resort to compiler-based optimisation if and when profiling has determined that it is necessary and then only for the parts of the code where there are demonstrable performance bottlenecks.

--
Chris Burrows
CFB Software
Armaide: LPC2xxx Integrated Development System
http://www.cfbsoftware.com/armaide

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



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, "cfbsoftware1" wrote:
>
> --- In l...@yahoogroups.com, Sutton Mehaffey wrote:
> >
> > Also, in my Keil GUI, anybody had any issues with variables out of scope
> > when they aren't? I have some issues when coming out of routines, local
> > variables are all of a sudden out of scope. Sometimes, I have to create
> > bogus dummy variables and set them to the 'out of scope' variable.
> > Then, they become 'in scope'.

LOCAL variables should go out of scope when you return from a function. They were allocated on the stack and the stack has been 'popped'.

STATIC local variables will retain their values between function calls but can not be referenced directly from outside the function. You can pass out a pointer to the static local variable and then dereference it to get the value.

See:http://www.ehow.com/how_2056300_declare-static-variable-c.html

Richard

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



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

I've never had any other compiler ever that made local variables,
whether static or not, go away after a function call. Only in this Keil
uVision. The weird thing is that the variable in question is used
further down in the function and miraculously comes back to scope as
soon as I access it, but not before.

Sutton

rtstofer wrote:
>
>
> --- In l...@yahoogroups.com ,
> "cfbsoftware1" wrote:
> >
> > --- In l...@yahoogroups.com ,
> Sutton Mehaffey wrote:
> > >
> > > Also, in my Keil GUI, anybody had any issues with variables out of
> scope
> > > when they aren't? I have some issues when coming out of routines,
> local
> > > variables are all of a sudden out of scope. Sometimes, I have to
> create
> > > bogus dummy variables and set them to the 'out of scope' variable.
> > > Then, they become 'in scope'.
>
> LOCAL variables should go out of scope when you return from a
> function. They were allocated on the stack and the stack has been
> 'popped'.
>
> STATIC local variables will retain their values between function calls
> but can not be referenced directly from outside the function. You can
> pass out a pointer to the static local variable and then dereference
> it to get the value.
>
> See:http://www.ehow.com/how_2056300_declare-static-variable-c.html
> Richard

--
Sutton Mehaffey
Lookout Portable Security
4040 Royal Dr. #100
Kennesaw, GA 30144
800-207-6269, 770-514-7999, 770-514-1285 FAX
s...@lookoutportablesecurity.com

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

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

My optimization level is at 0.

Sutton

cfbsoftware1 wrote:
>
>
> --- In l...@yahoogroups.com ,
> Sutton Mehaffey wrote:
> >
> > Also, in my Keil GUI, anybody had any issues with variables out of
> scope
> > when they aren't? I have some issues when coming out of routines, local
> > variables are all of a sudden out of scope. Sometimes, I have to create
> > bogus dummy variables and set them to the 'out of scope' variable.
> > Then, they become 'in scope'.
>
> I don't know specifically about the Keil debugger but these sorts of
> issues are typically related to optimisations that a compiler has
> performed on your behalf. For predictable behaviour I recommend using
> the compiler settings that result in no optimisation. Concentrate on
> designing your algorithms to best meet any performance requirements.
> You should only resort to compiler-based optimisation if and when
> profiling has determined that it is necessary and then only for the
> parts of the code where there are demonstrable performance bottlenecks.
>
> --
> Chris Burrows
> CFB Software
> Armaide: LPC2xxx Integrated Development System
> http://www.cfbsoftware.com/armaide

--
Sutton Mehaffey
Lookout Portable Security
4040 Royal Dr. #100
Kennesaw, GA 30144
800-207-6269, 770-514-7999, 770-514-1285 FAX
s...@lookoutportablesecurity.com

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

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, Sutton Mehaffey wrote:
>
> I've never had any other compiler ever that made local variables,
> whether static or not, go away after a function call. Only in this Keil
> uVision. The weird thing is that the variable in question is used
> further down in the function and miraculously comes back to scope as
> soon as I access it, but not before.
>

Maybe something like this is happening?

1. The local is loaded from memory and is stored in a register. You can access it in the debugger.

2. You then call a function from within that function

3. When you next try to view the variable the register has been reallocated to something else.

4. Later your code accesses the local again so it is reloaded from memory. You can now access it in the debugger.

If, as you say, you have optimisation set to the minimum value are there any compiler switches that control the register allocation method (e.g. pass parameters via registers, store locals in registers etc.)?

Otherwise you might be stuck with what you are doing - i.e. explicitly re-accessing the local again in your code.

--
Chris Burrows
Armaide: LPC2xxx Integrated Development System
http://www.cfbsoftware.com/armaide

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



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

>> are there any compiler switches that control the register allocation
method (e.g. pass parameters via registers, store locals in registers etc.)?

Not that I know of.

cfbsoftware1 wrote:
>
>
> --- In l...@yahoogroups.com ,
> Sutton Mehaffey wrote:
> >
> > I've never had any other compiler ever that made local variables,
> > whether static or not, go away after a function call. Only in this Keil
> > uVision. The weird thing is that the variable in question is used
> > further down in the function and miraculously comes back to scope as
> > soon as I access it, but not before.
> > Maybe something like this is happening?
>
> 1. The local is loaded from memory and is stored in a register. You
> can access it in the debugger.
>
> 2. You then call a function from within that function
>
> 3. When you next try to view the variable the register has been
> reallocated to something else.
>
> 4. Later your code accesses the local again so it is reloaded from
> memory. You can now access it in the debugger.
>
> If, as you say, you have optimisation set to the minimum value are
> there any compiler switches that control the register allocation
> method (e.g. pass parameters via registers, store locals in registers
> etc.)?
>
> Otherwise you might be stuck with what you are doing - i.e. explicitly
> re-accessing the local again in your code.
>
> --
> Chris Burrows
> Armaide: LPC2xxx Integrated Development System
> http://www.cfbsoftware.com/armaide

--
Sutton Mehaffey
Lookout Portable Security
4040 Royal Dr. #100
Kennesaw, GA 30144
800-207-6269, 770-514-7999, 770-514-1285 FAX
s...@lookoutportablesecurity.com

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

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, Sutton Mehaffey wrote:
>
> I've never had any other compiler ever that made local variables,
> whether static or not, go away after a function call. Only in this Keil
> uVision. The weird thing is that the variable in question is used
> further down in the function and miraculously comes back to scope as
> soon as I access it, but not before.
>
> Sutton
Variables local to a function certainly do disappear when that function returns. In fact, variables local to main() are also allocated in a page frame on the stack. Variables within {} blocks are also allocated to a different location on the stack and disappear when the block is exited. Technically they are still in the page frame until the page frame is trashed.

Here is a simple example:

#include

int i = 99;

void fun(void)
{
int i = 11;

printf("Inside fun(), i = %d\n",i);
}

int main(void)
{
int i = 33;

{
int i = 22;
printf("Inside block, i = %d\n",i);
}
fun();
printf("At end of main, i = %d\n",i);
}

Compile it with:
gcc -o test -Wa,-adhnls=test.lst test.c

from test.lst you can see that all of the local variables are allocated on the stack relative to %rbp. The global 'i' is allocated in the .data segment and it is the only variable that is. This makes it accessible to all functions but each block and function has defined its own 'i'. The global variable is never referenced.

In the case of fun(), the 'leave' instruction cuts the stack back and %rsp is restored to its previous value. %rbp is also restored so that it is pointing at a previous stack frame. The local 'i' variable is gone. The next function to come along will write over the old values.

When compiled with:

arm-elf-gcc -o test -Wa,-adhnls=test.lst test.c

the results are identical although the generated code is somewhat different.

Now, as to whether uVision loses its mind and can't remember scope, who knows?

Richard

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



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

What I have is:
main()
{
int i = 99;
int val;

fun(); // no variables of same name in here - shouldn't matter

// scope of 'i' goes away here - Keil uVision

if (i == 0)
{
// I have to put this dummy read in to see what 'i' is,
// but it will be 99. And, 'i' will come back into scope
// as soon as statement below is executed

val = i;

}
}

rtstofer wrote:
>
>
> --- In l...@yahoogroups.com ,
> Sutton Mehaffey wrote:
> >
> > I've never had any other compiler ever that made local variables,
> > whether static or not, go away after a function call. Only in this Keil
> > uVision. The weird thing is that the variable in question is used
> > further down in the function and miraculously comes back to scope as
> > soon as I access it, but not before.
> >
> > Sutton
>
> Variables local to a function certainly do disappear when that function
> returns. In fact, variables local to main() are also allocated in a page
> frame on the stack. Variables within {} blocks are also allocated to a
> different location on the stack and disappear when the block is exited.
> Technically they are still in the page frame until the page frame is
> trashed.
>
> Here is a simple example:
>
> #include int i = 99;
>
> void fun(void)
> {
> int i = 11;
>
> printf("Inside fun(), i = %d\n",i);
> }
>
> int main(void)
> {
> int i = 33;
>
> {
> int i = 22;
> printf("Inside block, i = %d\n",i);
> }
> fun();
> printf("At end of main, i = %d\n",i);
> }
>
> Compile it with:
> gcc -o test -Wa,-adhnls=test.lst test.c
>
> from test.lst you can see that all of the local variables are allocated
> on the stack relative to %rbp. The global 'i' is allocated in the .data
> segment and it is the only variable that is. This makes it accessible to
> all functions but each block and function has defined its own 'i'. The
> global variable is never referenced.
>
> In the case of fun(), the 'leave' instruction cuts the stack back and
> %rsp is restored to its previous value. %rbp is also restored so that it
> is pointing at a previous stack frame. The local 'i' variable is gone.
> The next function to come along will write over the old values.
>
> When compiled with:
>
> arm-elf-gcc -o test -Wa,-adhnls=test.lst test.c
>
> the results are identical although the generated code is somewhat different.
>
> Now, as to whether uVision loses its mind and can't remember scope, who
> knows?
>
> Richard

--
Sutton Mehaffey
Lookout Portable Security
4040 Royal Dr.
Kennesaw, GA 30144
770-514-7999, 800-207-6269
Fax: 770-514-1285
http://www.lookoutportablesecurity.com
s...@lookoutportablesecurity.com

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



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Hi,

> What I have is:
>=20
> main()
> {
> int i =3D 99;
> int val;
>=20
> fun(); // no variables of same name in here - shouldn't matter
>=20
> // scope of 'i' goes away here - Keil uVision
>=20
> if (i =3D=3D 0)
> {
> // I have to put this dummy read in to see what 'i' is,
> // but it will be 99. And, 'i' will come back into scope
> // as soon as statement below is executed
>=20
> val =3D i;
>=20
> }
> }

"i" at the "if" statement has value 99 as executing fun () cannot change
"i". At the "if" statement, i=3D=3D0 can proven by the compiler to be fals=
e and
hence the code for "if" and its body need not be generated. Hence, "i" can
be eliminated after the call to fun().

--
Paul Curtis, Rowley Associates Ltd=A0=A0 http://www.rowley.co.uk
CrossWorks V2 is out for LPC1700, LPC3100, LPC3200, SAM9, and more!

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



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

I thought of that. But, my optimization level is set to 0. Maybe
level 0 means 'some optimization'.

Sutton

Paul Curtis wrote:
>
>
> Hi,
>
> > What I have is:
> >
> > main()
> > {
> > int i = 99;
> > int val;
> >
> > fun(); // no variables of same name in here - shouldn't matter
> >
> > // scope of 'i' goes away here - Keil uVision
> >
> > if (i == 0)
> > {
> > // I have to put this dummy read in to see what 'i' is,
> > // but it will be 99. And, 'i' will come back into scope
> > // as soon as statement below is executed
> >
> > val = i;
> >
> > }
> > }
>
> "i" at the "if" statement has value 99 as executing fun () cannot change
> "i". At the "if" statement, i==0 can proven by the compiler to be false and
> hence the code for "if" and its body need not be generated. Hence, "i" can
> be eliminated after the call to fun().
>
> --
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
>
> CrossWorks V2 is out for LPC1700, LPC3100, LPC3200, SAM9, and more!

--
Sutton Mehaffey
Lookout Portable Security
4040 Royal Dr.
Kennesaw, GA 30144
770-514-7999, 800-207-6269
Fax: 770-514-1285
http://www.lookoutportablesecurity.com
s...@lookoutportablesecurity.com

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



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, Sutton Mehaffey wrote:
>
> What I have is:
> main()
> {
> int i = 99;
> int val;
>
> fun(); // no variables of same name in here - shouldn't matter
>
> // scope of 'i' goes away here - Keil uVision
>
> if (i == 0)
> {
> // I have to put this dummy read in to see what 'i' is,
> // but it will be 99. And, 'i' will come back into scope
> // as soon as statement below is executed
>
> val = i;
>
> }
> }
>

Sounds like a uVision problem to me! I would look at the assembly code for this code snippet and see if something jumped out at me regarding fun() but I would be more than willing to blame it on uVision.

Or, maybe uVision has a limit to the number of things it can track and it isn't a matter of 'i' dropping out of scope but just that it is dropped from the list due to a limit on the number of items.

I don't have the best of luck with debuggers. I tend to avoid them at every opportunity.

Richard

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

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

I think it's a uVision problem too. I'm only tracking 3 variables in my
watch window, so there must be some underlying issue.

Sutton

rtstofer wrote:
>
>
> --- In l...@yahoogroups.com ,
> Sutton Mehaffey wrote:
> >
> > What I have is:
> >
> >
> > main()
> > {
> > int i = 99;
> > int val;
> >
> > fun(); // no variables of same name in here - shouldn't matter
> >
> > // scope of 'i' goes away here - Keil uVision
> >
> > if (i == 0)
> > {
> > // I have to put this dummy read in to see what 'i' is,
> > // but it will be 99. And, 'i' will come back into scope
> > // as soon as statement below is executed
> >
> > val = i;
> >
> > }
> > }
> > Sounds like a uVision problem to me! I would look at the assembly code
> for this code snippet and see if something jumped out at me regarding
> fun() but I would be more than willing to blame it on uVision.
>
> Or, maybe uVision has a limit to the number of things it can track and
> it isn't a matter of 'i' dropping out of scope but just that it is
> dropped from the list due to a limit on the number of items.
>
> I don't have the best of luck with debuggers. I tend to avoid them at
> every opportunity.
>
> Richard

--
Sutton Mehaffey
Lookout Portable Security
4040 Royal Dr.
Kennesaw, GA 30144
770-514-7999, 800-207-6269
Fax: 770-514-1285
http://www.lookoutportablesecurity.com
s...@lookoutportablesecurity.com

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



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Hi,

(first post, interesting read)

Sutton Mehaffey wrote:
> I thought of that. But, my optimization level is set to 0. Maybe
> level 0 means 'some optimization'.

Looking at the ARM compiler manual on the Keil website:

http://www.keil.com/support/man/docs/armcc/armcc_cjaieafa.htm

"-O0

Minimum optimization. The compiler performs simple optimizations that do not impair the debug view."

Constant folding is a pretty simple optimization (and in some cases mandated by the C language), so your predicate "i == 0" will turn into "0", and the compiler will elide your if() body.

Cheers,
Neil
--
http://www.njohnson.co.uk

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



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )