1

I am writing a program that will make some lights blink. The user will enter the delay time between the lights toggling and the sequence of lights.. So for example the user will enter "string_test 500000 123456". The delay between will be 500000 i think its less than milli seconds as 500000 is pretty fast. The number 123456 will be the LED number. So 1-2-3 etc.. When I run my code through the debugger, everything works as it should except I get stuck on BEQ.. If I run my code normally, only the first light turns on and off and then ends the the program. I still have to clean the code up, change the delay to something more user friendly and so on, but what I need help is why it is not branching at beq when r6 is 0?I have attached my Assembly code because I am getting values from the user no problem and I can cycle through the LEDs without an issue in debugger as well, which leads me to believe is something on the assembly side. There are other functions in the ASM file as well, could this be a problem? I am using a STM32 board in ARM assembly.

@@ Function Header Block
    .align  2              @ Code alignment - 2^n alignment (n=2)
                            @ This causes the assembler to use 8 byte alignment

    .syntax unified         @ Sets the instruction set to the new unified ARM + THUMB
                            @ instructions. The default is divided (separate instruction sets)

    .global string_test

    .code   16              @ 16bit THUMB code (BOTH .code and .thumb_func are required)
    .thumb_func             @ Specifies that the following symbol is the name of a THUMB
                            @ encoded function. Necessary for interlinking between ARM and THUMB code.`enter code here`

    .type   string_test, %function   @ Declares that the symbol is a function (not strictly required)

@ Function Declaration : int string_test(int delay,char *p, int count)
@
@ Input: r0, r1 , r2 (i.e. r0 holds the delay, r1 holds the lights, r2 holds the number of elements in the array(COUNT))
@ Returns: r0
@ 

@ Here is the actual function
string_test:

    push { r0, r1, r4-r7, lr}   @push the registers I am using to the stack
    mov r5, r0  @Move the delay size into r5
    mov r6, r2  @Move the array size into r6

loop:

    ldrb r7, [r1]
    mov r8, r1
    sub r7, #48

    mov r0, r7                  @move the value in r7 to r0 so BSP_LED_Toggle can use it 
    bl   BSP_LED_Toggle

    bl busy_delay

    mov r0, r7                  @move the value in r7 to r0 so BSP_LED_Toggle can use it 
    bl   BSP_LED_Toggle

    bl busy_delay
    mov r1, r8
    add r1, #1

    sub r6, #1
    cmp r6, #0

    beq endLoop

    b loop

endLoop:

    pop { r0, r1, r4-r7, lr}   @pop the registers I am using to the stack
    bx lr

I also noticed that the BEQ is trying to use the xPSR register

glts
  • 21,808
  • 12
  • 73
  • 94
AK47
  • 11
  • 3
  • 1
    What do you mean "except I get stuck on BEQ" in the debugger? You're single-stepping with a next-instruction debugger command, right? Your wall of text doesn't make much of a [mcve], it's hard to understand what happens when you run it. – Peter Cordes Jul 02 '18 at 23:43
  • (And BTW, you should use `subs r6, #1` / `bne loop` and remove the unconditional `b`. See [Why are loops always compiled into "do...while" style (tail jump)?](https://stackoverflow.com/q/47783926).) Also, you normally don't need to save/restore `r0..r3` in functions: they're call-clobbered in the usual ARM calling convention. – Peter Cordes Jul 02 '18 at 23:44
  • @PeterCordes I am stepping using "next", and it just gets stuck there when I get to the beq line when the cmp equals 0. Otherwise it will just move onto the next line without a problem. Basically it is not branching when it equals 0 – AK47 Jul 03 '18 at 15:33
  • UPDATE I figured it out, my busy delay function was messing with register 5 – AK47 Jul 03 '18 at 16:39

0 Answers0