Cannot access memory at address 0x100080ec.

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Cannot access memory at address 0x100080ec.

5,164 Views
lpcware
NXP Employee
NXP Employee
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
0 Kudos
27 Replies

3,401 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by renan on Wed Feb 10 10:34:37 MST 2010
Just to give some feedback, if someone is having the same problem as myself, here is a workaround:

Remove"--gc-sections" from in the settings from Linker, Miscellaneous section completely.

[COLOR=black][FONT=&quot]Then clean and rebuild your application.[/FONT][/COLOR]

Renan
0 Kudos

3,401 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by renan on Wed Feb 10 09:16:27 MST 2010
Message sent now with subject: Cannot access memory at address  0x1000805c.

Thanks
Renan
0 Kudos

3,401 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by CodeRedSupport on Wed Feb 10 08:33:45 MST 2010
Hmm - private messages used to work... Please email our support group - details can be found on the Code Red website - www.code-red-tech.com
0 Kudos

3,401 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by renan on Wed Feb 10 08:17:09 MST 2010
It would be great to send you a private msg, but private msgs are disabled in this forum, as you can see on this link.
http://knowledgebase.nxp.com/faq.php?faq=vb3_user_profile#faq_vb3_private_messages

I found it in the section:
User Profile Features
Private Messages

Is there any other way to contact you to send my code? (Perhaps the email support Code Red? If so, in who's name should I send? )

Renan
0 Kudos

3,401 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by CodeRedSupport on Wed Feb 10 06:56:28 MST 2010
So that seems to indicate that the SP is corrupted (the registers are stored on the stack) If thde bugger can't access the stack, it can't display the registers,

I'm sorry, but without your code/environment it is difficult to help you more. Perhaps you send me a private message through the forum and you could send me your code?
0 Kudos

3,401 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by renan on Wed Feb 10 04:46:54 MST 2010
Hi,

It does not show anything when I set the breakpoint in the end of iniLCD().

If I run step by step, it give the error in the title of this thread. When I select the Core Register Tab I got this error:

[HTML]
An error has occurred. See error log for more details.
java.lang.NullPointerException
[/HTML]

It shows me some registers in this case, but I cannot save them to a file. I can take another screenshot if necessary.

Renan
0 Kudos

3,401 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by CodeRedSupport on Wed Feb 10 04:43:57 MST 2010
What are the register values at that point? Does it even show them? If not, this is a strong indication that the SP has been corrupted.
0 Kudos

3,402 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by renan on Wed Feb 10 04:39:13 MST 2010

Quote: NXP_USA
Hi Renan,
Can you experiment with breakpoints and stepping and narrow down what code is executing when it stops working?
-NXP



Hi,

gdb log starts giving me this error in the moment I call initPinAsGpio.
This is the gdb log when I step into initPinAsGpio:
[HTML]
Cannot access memory at address 0x1000805c
Cannot access memory at address 0x1000805c
[/HTML]

Every step in this function gives me 2 messages like that.

Renan
0 Kudos

3,405 Views
lpcware
NXP Employee
NXP Employee
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
0 Kudos

3,405 Views
lpcware
NXP Employee
NXP Employee
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
0 Kudos

3,405 Views
lpcware
NXP Employee
NXP Employee
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.
0 Kudos

3,405 Views
lpcware
NXP Employee
NXP Employee
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
0 Kudos

3,405 Views
lpcware
NXP Employee
NXP Employee
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
0 Kudos

3,405 Views
lpcware
NXP Employee
NXP Employee
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.
0 Kudos

3,405 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by renan on Tue Feb 09 06:38:10 MST 2010
ok
0 Kudos

3,405 Views
lpcware
NXP Employee
NXP Employee
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.
0 Kudos

3,405 Views
lpcware
NXP Employee
NXP Employee
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?
0 Kudos

3,405 Views
lpcware
NXP Employee
NXP Employee
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.
0 Kudos

3,405 Views
lpcware
NXP Employee
NXP Employee
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?
0 Kudos

3,405 Views
lpcware
NXP Employee
NXP Employee
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.
0 Kudos