Arm Community
Site
Search
User
Site
Search
User
Groups
Arm Research
DesignStart
Education Hub
Graphics and Gaming
High Performance Computing
Innovation
Multimedia
Open Source Software and Platforms
Physical
Processors
Security
System
Software Tools
TrustZone for Armv8-M
中文社区
Blog
Announcements
Artificial Intelligence
Automotive
Healthcare
HPC
Infrastructure
Innovation
Internet of Things
Machine Learning
Mobile
Smart Homes
Wearables
Forums
All developer forums
IP Product forums
Tool & Software forums
Support
Open a support case
Documentation
Downloads
Training
Arm Approved program
Arm Design Reviews
Community Help
More
Cancel
Developer Community
Tools and Software
Software Tools
Jump...
Cancel
Software Tools
Arm Development Studio forum
armcc problem?
Tools, Software and IDEs blog
Forums
Videos & Files
Help
Jump...
Cancel
New
Replies
4 replies
Subscribers
126 subscribers
Views
2899 views
Users
0 members are here
Related
armcc problem?
Offline
Ric Peregrino
over 7 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
Offline
Ric Peregrino
over 7 years ago
Note: This was originally posted on 22nd April 2009 at
http://forums.arm.com
Downloaded and tried again with:
[rperegrino@hdev02 1_reset]$ armcc --vsn
ARM/Thumb C/C++ Compiler, RVCT3.1 [Build 794]
For support see [url="
http://www.arm.com/support/
"]
http://www.arm.com/support/[/url]
Software supplied by: ARM Limited
and got same result. Here's the invocation of the compiler and linker:
armcc -g -DVLOGTIME -DTIME -O3 -Otime --no_inline --cpu Cortex-M3 -c 1_reset.c -
o 1_reset.o
armcc -g -DVLOGTIME -DTIME -O3 -Otime --no_inline --cpu Cortex-M3 -c clib.c -o c
lib.o
"clib.c", line 66: Warning: #167-D: argument of type "unsigned char *" is incom
patible with parameter of type "char *"
sendchar(&tempch);
^
clib.c: 1 warning, 0 errors
armcc -g -DVLOGTIME -DTIME -O3 -Otime --no_inline --cpu Cortex-M3 -c exceptions.
c -o exceptions.o
armlink --info totals --symbols --inline \
--scatter cm3_code_on_codebus.scat \
--entry=__main --map \
--keep=exceptions.o\(exceptions_area\) \
1_reset.o clib.o exceptions.o\
--callgraph --elf -o 1_reset.elf > link.txt
Cancel
Up
0
Down
Reply
Cancel
Offline
Samar Samar
over 7 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
Up
0
Down
Reply
Cancel
Offline
Peter Harris
over 7 years ago
Note: This was originally posted on 21st April 2009 at
http://forums.arm.com
That looks like a compiler bug to me - although I'm not a C spec expert...
Can you try patching RVCT to the latest patch level (3.1 Build 794) and see if the issue still occurs? There were some known issues with volatiles in builds at high optimization levels which have since been fixed.
The patch download can be found here: [url="
http://www.arm.com/support/downloads/RVDS_31.html
"]
http://www.arm.com/support/downloads/RVDS_31.html[/url]
If you still have a problem can you also post the compiler and linker command lines you used?
Cancel
Up
0
Down
Reply
Cancel
Offline
Peter Harris
over 7 years ago
Note: This was originally posted on 22nd April 2009 at
http://forums.arm.com
Hi Ric,
My usual fixes for compiler bugs when no patch is available it to try a lower optimization level for the file in which the bug occurs, or try restructuring the code to see if it "goes away".
Splitting the known buggy function out into a separate file can reduce the impact of the lower optimization level, because the other code can still be compiled at -O3.
Raising the issue formally with ARM support (email
support@arm.com
) may be able to provide more information.
Cancel
Up
0
Down
Reply
Cancel
More questions in this forum
By title
By date
By reply count
By view count
By most asked
By votes
By quality
Descending
Ascending
All recent questions
Unread questions
Questions you've participated in
Questions you've asked
Unanswered questions
Answered questions
Questions with suggested answers
Questions with no replies
Suggested Answer
DS-5 bare metal wait error after run "debug"
0
DS-5 Development Studio
Debugging
Arm Compiler 5
Memory
30862
views
14
replies
Latest
3 months ago
by
prasadghole
Suggested Answer
ARM development studio with ARM Juno r2 board
0
Juno Arm Development Platform
Arm Development Studio
Products
Arm Support
8007
views
2
replies
Latest
3 months ago
by
Ronan Synnott
Answered
"Unable to execute remote query (response code 503) " issue
0
7737
views
1
reply
Latest
3 months ago
by
Ronan Synnott
Not Answered
Where can I download DS-5 hardware firmware??
0
7210
views
1
reply
Latest
3 months ago
by
Ronan Synnott
Not Answered
Getting errors after including arm_math.h
0
stm32 h7
Keil
Digital Signal Processor (DSP)
STM32
27070
views
9
replies
Latest
4 months ago
by
roger-liu
<
>
View all questions in Arm Development Studio forum