SIMPLE ARM LANGUAGE, keep the answers simple please
AREA one, CODE
ENTRY
LDR r0, =STRING1
LDR r1, =STRING2
LDR r3, =STRING3
`loop1` LDRB r4, [r0], #1
STRB r4, [r3], #1
CMP r0, #0x00
BNE loop1
loop2 LDRB r4, [r1], #1
STRB r4, [r3], #1
CMP r1, #0x00
BNE loop2
LDRB r4, #0x00
STRB r4, [r3]
ALIGN
STRING1 DCB "This is a test string1" ;String1
EoS1 DCB 0x00 ;end of string1
STRING2 DCB "This is a test string2" ;String
EoS2 DCB 0x00 ;end of string2
STRING3 space 0xFF
END
Im trying to concatenate STRING1 and STRING2 and store result in STRING3 and also append NULL End Of String 0x00
Is this correct?
you are getting 'NO write permission' because you must set the Memory Map in the Debug Tab of the Kiel simulator to Read/Write/Execute permission
Related
The question is to store 12 to R1 and 27 to R2 then subtract R2 with R1 and store the result into the memory address 0x4000. Lastly, store R1 into 0x4004 and R2 into 0x4008 , but I got Invalid immediate Operand Value on MOV R5, #0x4004 and R6, #0x4008.
MOV R2, #27
SUB R3, R2, R1
MOV R4, #0x4000
STR R3, [R4]
MOV R5, #0x4004
MOV R6, #0x4008
STR R1, [R5]
STR R2, [R6]
MOV R2, #27
SUB R3, R2, R1
MOV R4, #0x4000
STR R3, [R4, #0]
STR R1, [R4, #4]
STR R2, [R4, #8]
According to this tutorial, it looks like intermediate values in 32-bit ARM are restricted to "neat" numbers which can be represented as a byte value shifted by some even integer. A quick check of 0x4000 yields 0b100000000000000 which is could be represented by 0x1 shifted left 0d14 times. Your values 0x4004 and 0x4008 don't seem to fall under this category: 0x4004 is 0b100000000000100 and 0x4008 is 0b100000000001000.
Since those specific values seem important, you could try adding to the value in R4 and saving those values to R5 and R6.
MOV R2, #27
SUB R3, R2, R1
MOV R4, #0x4000
STR R3, [R4]
ADD R5, R4, #0x4
ADD R6, R4, #0x8
STR R1, [R5]
STR R2, [R6]
If you'd like more information, you can check out ARM's own documentation on immediate values here. Just make sure to check that the version of the ISA you're using is the same as the one in the documentation. In the future, try to give as much detail as possible about your environment, since there are many versions of the ARM ISA (for example, the 16-bit thumb version is very different compared to the 32 or 64 bit versions).
Having trouble printing any number past 10 in my LC3 program to multiply 2 input numbers to get a area. It works for any numbers below 10 so I know my multiplication is right. The problem is it produces weird symbols or nonsense anywhere higher then 10. So confused why. Here is my code:
.ORIG x3000
AND R3, R3, #0
AND R4, R4, #0
LD R5, INVERSE_ASCII_OFFSET
LD R6, DECIMAL_OFFSET
;---------------------
;receiving length
LEA R0, PROMPT1 ;load the address of the 'PROMPT1' message string
PUTS ;Prints PROMPT1
GETC ;get length
ADD R1, R0, #0
ADD R1, R1, R5
;receving width
LEA R0, PROMPT2 ;load the address of the 'PROMPT2' message string
PUTS ;Prints PROMPT2
GETC ;get width
ADD R2, R0, #0
ADD R2, R2, R5
;----------------------
;MULTIPLICATION to find AREA
ADD R4, R2, #0
FINDAREA:
ADD R3, R3, R1
ADD R4, R4, #-1
BRp FINDAREA
LEA R0, PROMPT3
PUTS
ADD R0, R3, R6
OUT
HALT
PROMPT1 .STRINGZ "ENTER LENGTH OF THE RECTANGLE:"
PROMPT2 .STRINGZ "ENTER WIDTH OF THE RECTANGLE:"
PROMPT3 .STRINGZ "AREA OF THE RECTANGLE:"
INVERSE_ASCII_OFFSET .fill xFFD0
DECIMAL_OFFSET .fill #48
.END```
I'm running some tests on a Cortex-R5 (Ultrascale MpSoC). It basically generates 2 random numbers with a hardware module and compares them at the end to ensure they're not 0, nor the same values.
uint32_t status;
const uint8_t zeros[32] = {0};
uint8_t bytes1[32] = {0};
uint8_t bytes2[32] = {0};
// (generate random numbers and put them in bytes1)
// (generate random numbers and put them in bytes2)
printf("memcmp 0\n");
status = !memcmp(bytes1, bytes2, 32);
printf("memcmp 1\n");
status |= !memcmp(bytes1, zeros, 32);
printf("memcmp 2\n");
status |= !memcmp(bytes2, zeros, 32);
Some tests are running fine. Some executions are stalled after printing "memcmp 0" (when it freezes, it's always at the first memcmp)...
I have tried several things:
When I print the values in bytes1 and 2, they are indeed random numbers not equal to 0 and not equal with each other.
Moving the memcmp at different places, or switching the memcmp's. It's always the first one which freezes.
Replacing memcmp with a custom function to do comparison => it never freezes.
The memcmp function is used at other places of the code and it freezes nowhere else. Perhaps the difference is that the random check is the only place where the memcmp expects different values (at other places it's to ensure a function produces expected output).
I couldn't find the definition of memcmp... I don't know where to look. The only thing I could find is the assembly code, but it'd be difficult to attach a debugger to know exactly which instruction can't complete.
000064d0 <memcmp>:
64d0: 2a03 cmp r2, #3
64d2: b470 push {r4, r5, r6}
64d4: d912 bls.n 64fc <memcmp+0x2c>
64d6: ea40 0501 orr.w r5, r0, r1
64da: 4604 mov r4, r0
64dc: 07ad lsls r5, r5, #30
64de: 460b mov r3, r1
64e0: d120 bne.n 6524 <memcmp+0x54>
64e2: 681d ldr r5, [r3, #0]
64e4: 4619 mov r1, r3
64e6: 6826 ldr r6, [r4, #0]
64e8: 4620 mov r0, r4
64ea: 3304 adds r3, #4
64ec: 3404 adds r4, #4
64ee: 42ae cmp r6, r5
64f0: d118 bne.n 6524 <memcmp+0x54>
64f2: 3a04 subs r2, #4
64f4: 4620 mov r0, r4
64f6: 2a03 cmp r2, #3
64f8: 4619 mov r1, r3
64fa: d8f2 bhi.n 64e2 <memcmp+0x12>
64fc: 1e54 subs r4, r2, #1
64fe: b172 cbz r2, 651e <memcmp+0x4e>
6500: 7802 ldrb r2, [r0, #0]
6502: 780b ldrb r3, [r1, #0]
6504: 429a cmp r2, r3
6506: bf08 it eq
6508: 1864 addeq r4, r4, r1
650a: d006 beq.n 651a <memcmp+0x4a>
650c: e00c b.n 6528 <memcmp+0x58>
650e: f810 2f01 ldrb.w r2, [r0, #1]!
6512: f811 3f01 ldrb.w r3, [r1, #1]!
6516: 429a cmp r2, r3
6518: d106 bne.n 6528 <memcmp+0x58>
651a: 42a1 cmp r1, r4
651c: d1f7 bne.n 650e <memcmp+0x3e>
651e: 2000 movs r0, #0
6520: bc70 pop {r4, r5, r6}
6522: 4770 bx lr
6524: 1e54 subs r4, r2, #1
6526: e7eb b.n 6500 <memcmp+0x30>
6528: 1ad0 subs r0, r2, r3
652a: bc70 pop {r4, r5, r6}
652c: 4770 bx lr
652e: bf00 nop
Where can I see the source code of memcmp for cortex R5? FYI, the used compiler is armr5-none-eabi-gcc.
Any idea what could cause a CPU stall with this function?
Thank you
everyone, I am a beginner of embedded system programming, my first led test program for my board, which is mini2440, was written in assembly language as .S file:
.text
.global _start
_start:
bl disable_watch_dog
ldr r0, =0x56000010
mov r1, #0x15400
str r1, [r0]
ldr r0, =0x56000018
mov r1, #0x0
str r1, [r0]
ldr r0, =0x56000014
MAIN_LOOP:
mov r1, #0x0
str r1, [r0]
mov r2, #0x50000
bl delay
mov r1, #0x1e0
str r1, [r0]
mov r2, #0x50000
bl delay
b MAIN_LOOP
disable_watch_dog:
ldr r0, =0x53000000
mov r1, #0x0
str r1, [r0]
mov pc, r14
delay:
sub r2, r2, #0x1
cmp r2, #0x0
bne delay
mov pc, lr
After the compiling I got .bin file from this program and I wrote it to the band flash of mini2440 with opened:
telnet localhost 4444
halt
init_2440
nand erase 0 0x0 0x100000
nand write 0 /home/led/led.bin 0
reset
I did not see any error or warning from the terminal but the board just has no reaction, all the leds were dark. I appreciate it if anyone could explain me about this.
Thanks
I'm still learning ARM and I couldn't understand what this function is supposed to do.
Can you guys help me out explaining how it works?
.text:0006379C EXPORT _nativeD2AB
.text:0006379C _nativeD2AB
.text:0006379C var_28 = -0x28
.text:0006379C
.text:0006379C STMFD SP!, {R4-R11,LR}
.text:000637A0 SUB SP, SP, #0x3A4
.text:000637A4 STMFA SP, {R0-R3}
.text:000637A8 LDR R0, =(_GLOBAL_OFFSET_ - 0x637B8)
.text:000637AC LDR R1, =(__stack_chk - 0x134EAC)
.text:000637B0 ADD R0, PC, R0 ; _GLOBAL_OFFSET_
.text:000637B4 LDR R0, [R1,R0] ; __stack_chk
.text:000637B8 LDR R0, [R0]
.text:000637BC STR R0, [SP,#0x3C8+var_28]
.text:000637C0 MOV R0, #1
.text:000637C4 ADR R1, sub_637D0
.text:000637C8 MUL R0, R1, R0
.text:000637CC MOV PC, R0
.text:000637CC ; End of function _nativeD2AB
.
.got:00134EAC _GLOBAL_OFFSET_TABLE_ DCD 0
.
.got:00134B0C AREA .got, DATA
.got:00134B0C __stack_chk DCD __stack_chkA
.
Found the rest of the function. If I understood some of it correctly, it seems to be scrambling the data, though that may be just a wild guess:
.text:000637D0 sub_637D0
.text:000637D0 MOV R0, #1
.text:000637D4 ADR R1, sub_637E0
.text:000637D8 MUL R0, R1, R0
.text:000637DC MOV PC, R0
.text:000637DC ; End of function sub_637D0
.text:000637E0 sub_637E0
.text:000637E0
.text:000637E0 arg_14 = 0x14
.text:000637E0
.text:000637E0 STR R2, [SP,#arg_14]
.text:000637E4 MOV R0, #1
.text:000637E8 ADR R1, loc_637F4
.text:000637EC MUL R0, R1, R0
.text:000637F0 MOV PC, R0
.text:000637F0 ; End of function sub_637E0
.text:000637F4 loc_637F4
.text:000637F4 STR R2, [SP,#0x28]
.text:000637F8 STR R0, [SP,#0x18]
.text:000637FC MOV R1, #2
.text:00063800 STR R2, [SP,#0x1C]
.text:00063804 STR R0, [SP,#0x20]
.text:00063808 STR R0, [SP,#0x24]
The function has several parts:
Store registers to the stacj and reserve space (Strangely, not restored)
Load to R0 the address of GLOBAL_OFFSET (Once added with PC), to actually access __stack_chk (When added to GLOBAL_OFFSET). This is done in a very strange way.
Load the data at __stack_chk and store it in the stack
Load to R0 the value of sub_637D0, by doing a multiplication by 1. This is the value returned by the function.
So in my opinion, this does not seem to do anything useful...