Arm Community
Site
Search
User
Site
Search
User
Support forums
Arm Development Studio forum
armcc problem?
Jump...
Cancel
Locked
Locked
Replies
4 replies
Subscribers
119 subscribers
Views
4363 views
Users
0 members are here
Options
Share
More actions
Cancel
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion
armcc problem?
Ric Peregrino
over 12 years ago
Note: This was originally posted on 20th April 2009 at
http://forums.arm.com
Hello,
We're using armcc here version:
ARM/Thumb C/C++ Compiler, RVCT3.1 [Build 739]
And it seems to have an issue. Here's some simple c-code:
main () {
volatile unsigned int tmp32;
printf ("GPIO: 1_reset: before\n");
// touch tb_gpio
*(unsigned int *)(0x50000004) = 0x12345678;
tmp32 = *((volatile unsigned int *)(0x50000004));
printf ("GPIO: tmp32 = 0x%0x\n", tmp32);
printf ("GPIO: tmp32 = 0x%0x\n", tmp32);
if (tmp32 != 0x12345678) printf("FAIL: 1st tb_gpio WRV failed!\n");
Here's the resulting output:
# GPIO: 1_reset: before
# GPIO: tmp32 = 0x12345678
# GPIO: tmp32 = 0x0
# FAIL: 1st tb_gpio WRV failed!
Why is the 2nd printf of tmp32 different? Here's the disassembled code, and it seems that the first printf is printing not tmp32 which is in r4, but the literal that was written, which is in r6:
0x00040082: 4e2b +N LDR r6,[pc,#172] ; [0x40130] = 0x12345678
0x00040084: f04f45a0 O..E MOV r5,#0x50000000
0x00040088: 606e n` STR r6,[r5,#4]
0x0004008a: 686c lh LDR r4,[r5,#4]
0x0004008c: 4631 1F MOV r1,r6
0x0004008e: a029 ). ADR r0,{pc}+0xa6 ; 0x40134
0x00040090: f000fcf6 .... BL __0printf ; 0x40a80
0x00040094: 4621 !F MOV r1,r4
0x00040096: a027 '. ADR r0,{pc}+0x9e ; 0x40134
0x00040098: f000fcf2 .... BL __0printf ; 0x40a80
This make sense? Is this an armcc bug? If so, what next?
Cheers,
Ric Peregrino
Dust Networks
Parents
Samar Samar
over 12 years ago
Note: This was originally posted on 24th April 2009 at
http://forums.arm.com
Can you try to make tmp32 global and check the assembly? Also please make sure you can actually write and read back from 0x50000004 location.
The move from r6 to r1 may be because it does not think tmp32 to be volatile. In fact it did not even assign a memory location to tmp32.
Move from r4 to r1 looks correct to me but i am surprised to see 0 in the second line of output. That makes me think that the location 0x50000004 wasnt written to properly or is not read properly.
Another thing you can try is:
volatile unsigned int *loc = (volatile unsigned int *)0x50000004;
main () {
unsigned int tmp32;
printf ("GPIO: 1_reset: before\n");
// touch tb_gpio
*loc = 0x12345678;
tmp32 = *loc;
printf ("GPIO: tmp32 = 0x%0x\n", tmp32);
*loc = 0x87654321;
tmp32 = *loc;
printf ("GPIO: tmp32 = 0x%0x\n", tmp32);
if (tmp32 != 0x12345678) printf("FAIL: 1st tb_gpio WRV failed!\n");
Please share the findings.
Samar
Cancel
Vote up
0
Vote down
Cancel
Reply
Samar Samar
over 12 years ago
Note: This was originally posted on 24th April 2009 at
http://forums.arm.com
Can you try to make tmp32 global and check the assembly? Also please make sure you can actually write and read back from 0x50000004 location.
The move from r6 to r1 may be because it does not think tmp32 to be volatile. In fact it did not even assign a memory location to tmp32.
Move from r4 to r1 looks correct to me but i am surprised to see 0 in the second line of output. That makes me think that the location 0x50000004 wasnt written to properly or is not read properly.
Another thing you can try is:
volatile unsigned int *loc = (volatile unsigned int *)0x50000004;
main () {
unsigned int tmp32;
printf ("GPIO: 1_reset: before\n");
// touch tb_gpio
*loc = 0x12345678;
tmp32 = *loc;
printf ("GPIO: tmp32 = 0x%0x\n", tmp32);
*loc = 0x87654321;
tmp32 = *loc;
printf ("GPIO: tmp32 = 0x%0x\n", tmp32);
if (tmp32 != 0x12345678) printf("FAIL: 1st tb_gpio WRV failed!\n");
Please share the findings.
Samar
Cancel
Vote up
0
Vote down
Cancel
Children
No data