temporary/stack string

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

temporary/stack string

1,010 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Jindra on Sat Apr 10 16:43:16 MST 2010
Please, I have another problem, probably with allocating variables on stack.
I try to do some methods which operate with temporary strings on stack.
Simplified it looks:

const char nums[] = "0123456789ABCDEFGH";
void method(int a, int b)
{
    char params[] = " 0x.., 0x..\n";
    params[4] = nums[a&0xf];                 // <-- here put breakpoint
    params[3] = nums[(a&0xf0)>>4];
    params[10] = nums[b&0xf];
    params[9] = nums[(b&0xf0)>>4];
    doSomething(params);
}

If I put breakpoint on marked row:
- in tooltip, in variables and expressions debugger shows: "\037\000 0x.., 0x\000"
- if I expand array items, both in variables and expressions it shows:
params    0x10001f63   
    params[0]    31   
    params[1]    '0'   
    params[2]    'x'   
    params[3]    'x'   
    params[4]    'x'   
    params[5]    ','   
    params[6]    ' '   
    params[7]    ' '   
    params[8]    ' '   
    params[9]    '.'   
    params[10]    '.'   
    params[11]    '.'   
    params[12]    '.'   

- if I look in memory window, there is correct charactes, but wrong addres - correct starting from 0x10001f64
(I also don't understand why 0x10001f60 is showed as 1 byte before 0x10001f63, and 0x10001f64 is showed as 3 bytes after 0x10001f63 ? )

- program don't work (behaves like using real values on shifted addres)

I want writable string with minimal coding, so can't use:
char *params = " 0x.., 0x..\n";
and I believe that this way is legal code.

I using lpc1114 and lpcXpresso 3.2.2

Thanks for response.
0 Kudos
Reply
6 Replies

995 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Jindra on Tue Apr 13 12:45:54 MST 2010
With 3.3.4 this looks working as expected. Thanks.
0 Kudos
Reply

995 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by CodeRedSupport on Mon Apr 12 01:36:12 MST 2010
1. The statically initialized data is placed into "bss". If it is const, then it is placed into "text"
2. removing --gc-sections only affects the linker and has no affect on the compiler.
0 Kudos
Reply

995 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Jindra on Sun Apr 11 13:33:10 MST 2010
1. But when it is copied to ram, then the ram should be reserved and so count into that sizes, no?
So small sizes looks like the strings are used directly from code region. Is exist some document about how exactly this works on lpcXpresso?

2. As I wrote, even without gc-sections it works only until rebuild whole project. And my real project is already without gc-sections.
Is exist something like official buglist - known issues?
0 Kudos
Reply

995 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by CodeRedSupport on Sun Apr 11 09:32:53 MST 2010
1. Yes, statically initialized data is added to Text. In the startup code, the statically initialized data is then copied into the RAM - that is the only way it can possibly work.

2. Yes, try removing -gc-sections. We are working on trying to fix that issue.
0 Kudos
Reply

995 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Jindra on Sun Apr 11 04:50:32 MST 2010
I not tried put it in main, as then it is useless. But also tried put uint32_t (int) before, it helps but not always and of course this is not solution.
Modified blinky - tried to remove as much as possible. Compiled on debug:
   text       data        bss        dec        hex    filename
    928          0          8        936        3a8    blinky.axf

data is 0 and bss 8 ?  where is my two strings, they count into text (code size)?

If I removed --gc-sections it works for first try. but after clean and build, it also not work.
I also thing that correctly working remove of death code is essential for every project other as blinky demos ...
   text       data        bss        dec        hex    filename
   7104          4          8       7116       1bcc    blinky.axf

--------

#include "LPC11xx.h"                        /* LPC11xx definitions */

const char nums[] = "0123456789ABCDEFGH";

void doSomething(const char *str)
{
}

void method(const char *instr, int a, int b)
{
     //int iii;   <- will work if uncoment
    char params[] = " 0x.., 0x..\n";
    params[4] = nums[a&0xf];
    params[3] = nums[(a&0xf0)>>4];
    params[10] = nums[b&0xf];
    params[9] = nums[(b&0xf0)>>4];
    doSomething(params);
}

int main (void) {
     method("test", 0x12, 0x34);
     while (1) ;
}

---------------
Sorry to be angry, but after lot of time I still not start working on my project but "debuging" basic things. So I think more and more, to move back on previous pltaform, as my goal is target product, not playing with devkits.
Maybe my expectations is too high to have idiot-proof toolchain, but lpcXpresso still looks very unreliable to me.
I don't know if it is unfinished, or it is because the way I expect it work, or I do something wrong ... ?
Currently time is my enemy and I feel very disapointed, so sorry.
0 Kudos
Reply

995 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by CodeRedSupport on Sun Apr 11 02:35:36 MST 2010
I just tried modifying the blinky example:

const char nums[] = "0123456789ABCDEFGH";

int main(void) {
    int a = 0, b = 0 ;
    char params[] = " 0x.., 0x..\n";
    params[4] = nums[a&0xf]; // <-- here put breakpoint
    params[3] = nums[(a&0xf0)>>4];
    params[10] = nums[b&0xf];
    params[9] = nums[(b&0xf0)>>4];
...

And it worked correctly for me.

The things to look at are:
You are running on an LPC1114. This has 8k of RAM, which has to be shared between the program data, the C heap and the stack. You need to look at how much data your app is using, how much heap, and how much stack - it is possible that one is overwriting the other - especially if you have nested interrupts as well.
0 Kudos
Reply