LPCXpresso IDE中的主题 Re: Cannot access memory at address 0x100080ec.

Cannot access memory at address 0x100080ec.

lpcware — Thu, 16 Jun 2016 00:49:08 GMT

Content originally posted in LPCWare by renan on Mon Dec 14 10:04:12 MST 2009
I'm getting this error using LPCXpresso and RDB1768:

"Execution is suspended because of error.
Cannot access memory at address 0x100080ec."

Does anybody has this problem too?

Thanks

Re: Cannot access memory at address 0x100080ec.

lpcware — Thu, 16 Jun 2016 00:49:09 GMT

Content originally posted in LPCWare by CodeRedSupport on Mon Dec 14 10:37:14 MST 2009
That location is beyond the end of memory on an LPC1768. The stack is normally placed at the top of memory, so it could be that your stack is overflowing, or you are corrupting the stack. Can you narrow it down to what you are doing when this error occurs? Can you reproduce the problem with Red Suite 2?

Re: Cannot access memory at address 0x100080ec.

lpcware — Thu, 16 Jun 2016 00:49:09 GMT

Content originally posted in LPCWare by renan on Mon Dec 14 13:02:05 MST 2009
Can you narrow it down to what you are doing when this error occurs?
If I understood your question, I was initializing my HMI (LCD 4x40 and some buttons).

Can you reproduce the problem with Red Suite 2?
Yes, Red Suite 2 does the same thing.

It was a little strange, because it didn't follow the code.
It was starting in the initialization code then it went to another function that wasn't even call at the time.

I commented that function and the error stops.

Re: Cannot access memory at address 0x100080ec.

lpcware — Thu, 16 Jun 2016 00:49:10 GMT

Content originally posted in LPCWare by CodeRedSupport on Tue Dec 15 00:48:10 MST 2009
Was the 'other function' an Interrupt Servce routine (or called from one). Have you set up a handler for any interrupots your device may be generating?

The vector table is defined in the startup file.

Re: Cannot access memory at address 0x100080ec.

lpcware — Thu, 16 Jun 2016 00:49:10 GMT

Content originally posted in LPCWare by renan on Wed Dec 16 10:46:00 MST 2009
No, the other function was just a routine to write an integer in a specific format in the display.

Re: Cannot access memory at address 0x100080ec.

lpcware — Thu, 16 Jun 2016 00:49:11 GMT

Content originally posted in LPCWare by CodeRedSupport on Wed Dec 16 11:22:44 MST 2009
Sorry, but you didn't answer the question. Have you setup the interrupt handler for the device?

Also when you end up in the other function, what is the list of functions on the stack (available in the Debug View).

Re: Cannot access memory at address 0x100080ec.

lpcware — Thu, 16 Jun 2016 00:49:11 GMT

Content originally posted in LPCWare by renan on Thu Dec 17 06:16:16 MST 2009
Sorry, but you didn't answer the question. Have you setup the interrupt handler for the device?

No.

Also when you end up in the other function, what is the list of functions on the stack (available in the Debug View).

In a few moments I will post the answer for this question.

Re: Cannot access memory at address 0x100080ec.

lpcware — Thu, 16 Jun 2016 00:49:12 GMT

Content originally posted in LPCWare by renan on Tue Feb 09 04:34:04 MST 2010
Well, I didn't answer the last question and it is haunting me again. :D
I rewrote that function and the error disappear.

It is happening again, but in another address: 0x10008054.
It is another function that my boss wrote. I can't see where it could be overflowing...

Here is the list of functions on the stack just before the error:
[HTML]
MCU GDB Debugger (09/02/10 09:25) (Suspended)
    Thread [0] (Suspended: Breakpoint hit.)
        2 lcd_reset() D:\lpcxpresso\workspace\Orion_Ihm\src\Lcd.c:323 0x00000608
        1 main() D:\lpcxpresso\workspace\Orion_Ihm\src\main.c:67 0x000014d6
[/HTML]

And this is the list of functions on the stack just after the error:
[HTML]
Orion_Ihm (Debug) [C/C++ MCU Application]
    MCU GDB Debugger (09/02/10 09:25) (Suspended) <Cannot access memory at address 0x10008054>
        Thread [0] (Suspended)
    arm-none-eabi-gdb (09/02/10 09:25)
    D:\lpcxpresso\workspace\Orion_Ihm\Debug\Orion_Ihm.axf (09/02/10 09:25)
[/HTML]

Renan

Re: Cannot access memory at address 0x100080ec.

lpcware — Thu, 16 Jun 2016 00:49:12 GMT

Content originally posted in LPCWare by CodeRedSupport on Tue Feb 09 04:43:18 MST 2010
This sort of error is normally caused by stack overflow (there is no stack overflow detection in these parts).

If the stack overflows into the heap, or your applications data area, then either the sack will be corrupted when your write to data/heap, and/or your data/heap will be corrupted with stack values.

Re: Cannot access memory at address 0x100080ec.

lpcware — Thu, 16 Jun 2016 00:49:13 GMT

Content originally posted in LPCWare by renan on Tue Feb 09 04:58:39 MST 2010
So, if there is no stack overflow detection in these parts, what could I do to know what's wrong?

I removed the breakpoint from the point it was giving me the error, and put it again some lines below. The error stops....
Could it be something with the breakpoints?

Re: Cannot access memory at address 0x100080ec.

lpcware — Thu, 16 Jun 2016 00:49:13 GMT

Content originally posted in LPCWare by CodeRedSupport on Tue Feb 09 05:14:58 MST 2010
No, there is nothing wrong with breakpoints.

When you hit a breakpoint, the debugger is reading the registers. It then uses the value in the SP to walk the stack, providing you with a stack trace, and the value of your local variables.

Somewhere in this process, the debugger is reading the value and it is getting the error.

Your application may appear to be working, but it will probably fail at some point, when the values that are being corrupted, become critical.

What can you do? Start looking for a function that could be causing the stack to grow too large. Such as:
- too many nested interrupts
- recursive function not exiting
- allocating large amount of data on the stack in a local variable.

Sorry, but as there is no hardware stack checking, it is difficult to track this sort of issue down.

Re: Cannot access memory at address 0x100080ec.

lpcware — Thu, 16 Jun 2016 00:49:14 GMT

Content originally posted in LPCWare by renan on Tue Feb 09 05:28:51 MST 2010

Quote:
Sorry, but as there is no hardware stack checking, it is difficult to track this sort of issue down.

This can be done in Red Suite 2?

Re: Cannot access memory at address 0x100080ec.

lpcware — Thu, 16 Jun 2016 00:49:14 GMT

Content originally posted in LPCWare by CodeRedSupport on Tue Feb 09 06:30:20 MST 2010
No, becasue there is no hardware stack checking on the chip. AFAIK, none of the ARM microcontroller cores have hardware stack checking.

Re: Cannot access memory at address 0x100080ec.

lpcware — Thu, 16 Jun 2016 00:49:15 GMT

Content originally posted in LPCWare by renan on Tue Feb 09 06:38:10 MST 2010
ok

Re: Cannot access memory at address 0x100080ec.

lpcware — Thu, 16 Jun 2016 00:49:15 GMT

Content originally posted in LPCWare by rkiryanov on Tue Feb 09 06:41:35 MST 2010

Quote: CodeRedSupport

I think, it is possible to configure MPU (M3) on current stack to protect first 4-32 bytes for writing.

Re: Cannot access memory at address 0x100080ec.

lpcware — Thu, 16 Jun 2016 00:49:16 GMT

Content originally posted in LPCWare by NXP_USA on Tue Feb 09 10:54:31 MST 2010

Quote: renan
Well, I didn't answer the last question and it is haunting me again. :D
I rewrote that function and the error disappear.

It is happening again, but in another address: 0x10008054.
It is another function that my boss wrote. I can't see where it could be overflowing...
...

Renan

Does your function have a lot of local variables? Something like this could overflow the stack because it allocates 2K of data on it. If this function calls something else, that data will remain allocated on the stack in the nested function.

void test(void)
{
char big_array[2048];
...
}

Generally... (nothing is ALWAYS true) on such a small part with no OS or dynamic allocation, it is better to use global variables for larger data structures because the linker is able to pre-allocate them and check that there is enough space. Otherwise the code can be stepped through and you can watch the stack pointer to see how much stack is used. The stack is considered to "overflow" when it grows down until it collides with the pre-allocated global data. Check the linker .map file to see where that data ends. If you set a specific stack size then the linker will warn you when there is not enough room. However, it will not warn you when the stack gets larger than the allocated size at runtime. Some techniques that can be used are adding macros into the code to record the stack size, or even adding an interrupt to poll the stack size periodically. This can be put into a global variable and viewed in the debugger.

-Dave

Re: Cannot access memory at address 0x100080ec.

lpcware — Thu, 16 Jun 2016 00:49:17 GMT

Content originally posted in LPCWare by renan on Tue Feb 09 12:58:06 MST 2010
Well, I am a little bit lost.

I don't think that my function has a lot of variables, this is part of my code:

#define LCD_BEEP_N        Pin(0, 28)    
#define Pin(Port32, Pin32)    ((Port32 * 32) + Pin32)   
enum pinPullMode_ts                
{
    PULL_UP_MODE   = 0,
    REPEATER_MODE  = 1,
    PULL_NONE_MODE = 2,
    PULL_DOWN_MODE = 3
};
typedef enum pinPullMode_ts pinPullMode_t;

enum pinDirection_ts              
{
    IN  = 0,
    OUT = 1
};
typedef enum pinDirection_ts pinDirection_t;

#define PIN_AS_GPIO        00
#define OFF             FALSE
#define ON              TRUE

enum BOOLEANS                
{
    FALSE = 0,
    TRUE  = 1
};        
typedef enum BOOLEANS bool;

#define ConfigPinConnect(Port16, pin_N, pull, func)           \
    LPC_PINCON->PINMODE##Port16 &= (~Mask16(pin_N, 0x3,  2)); \
    LPC_PINCON->PINMODE##Port16 |=  Mask16(pin_N, pull, 2);   \
    LPC_PINCON->PINSEL##Port16  &= (~Mask16(pin_N, 0x3,  2)); \
    LPC_PINCON->PINSEL##Port16  |=  Mask16(pin_N, func, 2)

#define Mask16(pinN, val, width) (val << ((pinN % 16) * width))

#define ConfigPinGpio(Port32, masc32, od, out, set)         \
    LPC_PINCON->PINMODE_OD##Port32 &= ~masc32;              \
    if (od)                                                 \
    {                                                       \
        LPC_PINCON->PINMODE_OD##Port32 |= masc32;           \
    }                                                       \
    LPC_GPIO##Port32->FIODIR &= (~masc32);                  \
    if (out)                                                \
    {                                                       \
        LPC_GPIO##Port32->FIODIR |= masc32;                 \
    }                                                       \
    LPC_GPIO##Port32->FIOMASK  = (~masc32);                 \
    LPC_GPIO##Port32->FIOCLR  = masc32;                     \
    if (set)                                                \
    {                                                       \
        LPC_GPIO##Port32->FIOSET = masc32;                  \
    }

void iniLCD()
{
//    LPC_SC->SCS |= 0x00000001;   // set GPIOx to use Fast I/O

    initPinAsGpio(LCD_BEEP_N, PULL_UP_MODE,   FALSE, OUT, ON);
    initPinAsGpio(LCD_E1_N,   PULL_DOWN_MODE, FALSE, OUT, OFF);
    initPinAsGpio(LCD_E2_N,   PULL_DOWN_MODE, FALSE, OUT, OFF);
    initPinAsGpio(LCD_RS_N,   PULL_DOWN_MODE, FALSE, OUT, OFF);
    initPinAsGpio(LCD_RW_N,   PULL_UP_MODE,   TRUE,  OUT, ON);
    initPinAsGpio(D0_N,       REPEATER_MODE,  FALSE, OUT,  OFF);
    initPinAsGpio(D1_N,       REPEATER_MODE,  FALSE, OUT,  OFF);
    initPinAsGpio(D2_N,       REPEATER_MODE,  FALSE, OUT,  OFF);
    initPinAsGpio(D3_N,       REPEATER_MODE,  FALSE, OUT,  OFF);
    initPinAsGpio(D4_N,       REPEATER_MODE,  FALSE, OUT,  OFF);
    initPinAsGpio(D5_N,       REPEATER_MODE,  FALSE, OUT,  OFF);
    initPinAsGpio(D6_N,       REPEATER_MODE,  FALSE, OUT,  OFF);
    initPinAsGpio(D7_N,       REPEATER_MODE,  FALSE, OUT,  OFF);

    ihm_Col = Ihm_Start_Column;
    ihm_Lin = Ihm_Start_Line + LcdLines;  // Inicializa Lcd Superior, linhas 3 e 4

    int loopCount = 0;  // Contador do loop do while

    do
    {
        lcd_putController(Tab_ResetLcd[loopCount], LcdCmd);
        loopCount++;
        msDelay(5);     // delay > 4ms
    }
    while (loopCount < ((sizeof Tab_ResetLcd)/(sizeof Tab_ResetLcd[0])));

    ihm_Lin = Ihm_Start_Line;     // Inicializa Lcd Superior, linhas 1 e 2
    loopCount = 0;  // Zero o contador para poder iniciar o display de baixo
    do
    {
        lcd_putController(Tab_ResetLcd[loopCount], LcdCmd);
        loopCount++;
        msDelay(5);     // delay > 4ms
    }
    while (loopCount < ((sizeof Tab_ResetLcd)/(sizeof Tab_ResetLcd[0])));
    pihm_Token = &ihm_Token;
}

void initPinAsGpio(int pinNo, pinPullMode_t pull, bool od, pinDirection_t out, bool set)
{
    int i;
    i = 1 << (pinNo % 32);    // recria a máscara de 32 bits
    if (pinNo <= 15)
    {
        ConfigPinConnect(0, pinNo, pull, PIN_AS_GPIO);
    }
    else if (pinNo <= 31)
    {
        ConfigPinConnect(1, pinNo, pull, PIN_AS_GPIO);
    }
    else if (pinNo <= 47)
    {
        ConfigPinConnect(2, pinNo, pull, PIN_AS_GPIO);
    }
    else if (pinNo <= 63)
    {
        ConfigPinConnect(3, pinNo, pull, PIN_AS_GPIO);
    }
    else if (pinNo <= 79)
    {
        ConfigPinConnect(4, pinNo, pull, PIN_AS_GPIO);
    }
    else if (pinNo <= 95)
    {
        ConfigPinConnect(5, pinNo, pull, PIN_AS_GPIO);
    }
    else if (pinNo <= 111)
    {
        ConfigPinConnect(6, pinNo, pull, PIN_AS_GPIO);
    }
    else if (pinNo <= 128)
    {
        ConfigPinConnect(7, pinNo, pull, PIN_AS_GPIO);
    }
    else if (pinNo <= 143)
    {
        ConfigPinConnect(8, pinNo, pull, PIN_AS_GPIO);
    }
    else if (pinNo <= 159)
    {
        ConfigPinConnect(9, pinNo, pull, PIN_AS_GPIO);
    }
    
    if ( pinNo <= 31 )
    {
        ConfigPinGpio(0, i, od, out, set)
    }
    else if (pinNo <= 63)
    {
        ConfigPinGpio(1, i, od, out, set);
    }
    else if (pinNo <= 95)
    {
        ConfigPinGpio(2, i, od, out, set);
    }
    else if (pinNo <= 128)
    {
        ConfigPinGpio(3, i, od, out, set);
    }
    else if (pinNo <= 143)
    {
        ConfigPinGpio(4, i, od, out, set);
    }
}

gdb output:
[HTML]
No symbol "new" in current context.
set remotetimeout 60000
set mem inaccessible-by-default off
mon ondisconnect nochange
mi_cmd_var_create: unable to create variable object
mi_cmd_var_create: unable to create variable object
Note: automatically using hardware breakpoints for read-only addresses.
Cannot access memory at address 0x1000805c
Cannot access memory at address 0x1000805c
Cannot access memory at address 0x1000805c
Cannot access memory at address 0x1000805c
Cannot access memory at address 0x1000805c
Cannot access memory at address 0x1000805c
Cannot access memory at address 0x1000805c
Cannot access memory at address 0x1000805c
Cannot access memory at address 0x1000805c
Cannot access memory at address 0x1000805c
Cannot access memory at address 0x1000805c
Cannot access memory at address 0x1000805c
Cannot access memory at address 0x1000805c
Cannot access memory at address 0x1000805c
Cannot access memory at address 0x1000805c
Cannot access memory at address 0x1000805c
Cannot access memory at address 0x1000805c
Cannot access memory at address 0x1000805c
Cannot access memory at address 0x1000805c
Cannot access memory at address 0x1000805c
[/HTML]Stack before error:
[HTML]
Orion_Ihm (Debug) [C/C++ MCU Application]
    MCU GDB Debugger (09/02/10 17:51) (Suspended)
        Thread [0] (Suspended)
            1 initPinAsGpio() D:\lpcxpresso\workspace\Orion_Ihm\src\TsLpc17.c:212 0x0000111e
    arm-none-eabi-gdb (09/02/10 17:51)
    D:\lpcxpresso\workspace\Orion_Ihm\Debug\Orion_Ihm.axf (09/02/10 17:51)

[/HTML]Stack after error:
[HTML]
Orion_Ihm (Debug) [C/C++ MCU Application]
    MCU GDB Debugger (09/02/10 17:53) (Suspended) <Cannot access memory at address 0x1000805c>
        Thread [0] (Suspended)
    arm-none-eabi-gdb (09/02/10 17:53)
    D:\lpcxpresso\workspace\Orion_Ihm\Debug\Orion_Ihm.axf (09/02/10 17:53)

[/HTML]I have attached my .map too.

If necessary I can post more info too.

Renan

Re: Cannot access memory at address 0x100080ec.

lpcware — Thu, 16 Jun 2016 00:49:17 GMT

Content originally posted in LPCWare by CodeRedSupport on Tue Feb 09 13:10:23 MST 2010
Hi,

It is not necessarily that function that is causing the problem - but something else in the call stack.
- what calls this function?
- can it be called from an interrupt service routine?
- could it be called recursively?

Another thought that might be worth investigating:
What target board are you using it, and how is it powered? Many PC USB ports don't supply the spec'd power of 500mA. Can you check that your board is being supplied with enought power - power it from another source if possible.

We have encountered many strange problems that have been caused by insufficent power being supplied to the target.

Re: Cannot access memory at address 0x100080ec.

lpcware — Thu, 16 Jun 2016 00:49:18 GMT

Content originally posted in LPCWare by NXP_USA on Tue Feb 09 13:58:49 MST 2010

Quote: renan
Well, I am a little bit lost.

I don't think that my function has a lot of variables, this is part of my code:

...

...
I have attached my .map too.

If necessary I can post more info too.

Renan

Hi Renan,

I don't see anything wrong with the part of the code that was in your post. Your .map file shows that you have a lot of space free- you are only using about 1087 bytes of your 32K of RAM (LPC17xx family part) so the rest is free for stack and heap. Can you experiment with breakpoints and stepping and narrow down what code is executing when it stops working?

-NXP

Re: Cannot access memory at address 0x100080ec.

lpcware — Thu, 16 Jun 2016 00:49:19 GMT

Content originally posted in LPCWare by renan on Wed Feb 10 04:34:07 MST 2010

Quote: CodeRedSupport

1. what calls this function?
2. can it be called from an interrupt service routine?
3. could it be called recursively?
4. What target board are you using it, and how is it powered? Many PC USB ports don't supply the spec'd power of 500mA. Can you check that your board is being supplied with enought power - power it from another source if possible.

Hi

1. Sorry for not saying where I call that.
iniLCD( ) is called from main. That's the starting point, then it calls initPinAsGpio(LCD_BEEP_N, PULL_UP_MODE,   FALSE, OUT, ON);
The error shows up in the end of that function, but if you see the gdb log, you will notice that it was happening before that. To be exact it starts when I call initPinAsGpio.

2. I don't think any reason that it cannot be done.
There is no reason to do it as well, since it is just the LCD inicialization code.

3. Yes.

4. Board: RDB1768, USB powered. Yes, the board is being supplied with enought power. I have tryied in my boss computer with the same results.

I have noticed a strange behavior. If I remove all my breakpoints, and set one breakpoint in the last line of iniLCD( ),     pihm_Token = &ihm_Token, I have no errors showing up. The call stack says it hit the breakpoint at that line, but nothing in LPCXpresso says that I really am on the line.

gdb log:
[HTML]
No symbol "new" in current context.
set remotetimeout 60000
set mem inaccessible-by-default off
mon ondisconnect nochange
mi_cmd_var_create: unable to create variable object
mi_cmd_var_create: unable to create variable object
Note: automatically using hardware breakpoints for read-only addresses.
Cannot access memory at address 0x1000805c
Cannot access memory at address 0x1000805c
Cannot access memory at address 0x1000805c
[/HTML]Call stack:
[HTML]
Orion_Ihm (Debug) [C/C++ MCU Application]
    MCU GDB Debugger (10/02/10 09:17) (Suspended)
        Thread [0] (Suspended: Breakpoint hit.)
    arm-none-eabi-gdb (10/02/10 09:17)
    D:\lpcxpresso\workspace\Orion_Ihm\Debug\Orion_Ihm.axf (10/02/10 09:17)
[/HTML]This is the link with a screenshot that do not shows me that 'arrow' that should show me where I am.

http://img535.imageshack.us/img535/5420/screenur.png

New link:
http://img413.imageshack.us/img413/1928/screenl.png

PS.: In the new image I have circulated the only breakpoint in my project.

Renan