Important changes to forums and questions
All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.
10 years, 4 months ago.
rtos - offline compile not working and assembler makefile problem
Starting with a basic example rtos program for flashing LEDs, it works fine (of course) with online compile. Then I export for CodeSourcery.
In the makefile AS is defined as arm-none-eabi-as but the makefile uses CFLAGS including numerous gcc options unrecognized by as. When I change the Makefile to instead use arm-none-eabi-gcc for AS it compiles cleanly.
However, the code doesn't work.
I'm happy to help troubleshoot / fix but will need a little help. Perhaps it is time for me to start playing with the debugger I've read about...
I'm compiling on Linux with CodeSourcery gcc 4.7.2 (Sourcery CodeBench Lite) on Linux Mint 14, 3.5.0-17-generic #28-Ubuntu.
Thanks in advance,
Michael
PS: Here's the code I'm using:
three threads, flash leds, works fine with online compile
#include "mbed.h"
#include "rtos.h"
Serial pc(USBTX, USBRX);
DigitalOut led1(LED1);
DigitalOut led2(LED2);
DigitalOut led3(LED3);
void led1_thread(void const *args) {
while (true) {
pc.printf("Hello 1\n");
led1 = !led1;
Thread::wait(700);
}
}
void led2_thread(void const *args) {
while (true) {
fprintf(stdout, "Hello 2\n");
led2 = !led2;
Thread::wait(1000);
}
}
int main() {
pc.baud(115200);
Thread t1(led1_thread);
Thread t2(led2_thread);
while (true) {
fprintf(stdout, "Hello 3\n");
led3 = !led3;
Thread::wait(500);
}
}
I set up a custom hard fault handler. Here's what it reports:
[Hard fault] R0 = 0x0000 R1 = 0x0000 R2 = 0x0000 R3 = 0x100006d0 R12 = 0x0059 LR [R14] = 0x066d subroutine call return address. PC [R15] = 0x066c program counter PSR = 0x61000000 ZC Thread mode thumb HFSR = 0x40000000 FORCED CFSR = 0x00000400 UFSR = 0x0000 BFSR = 0x00 MMFSR = 0x00 BFAR = invalid MMFAR = invalid DFSR = 0x00000008 AFSR = 0x00000000 SCB_SHCSR = 0x00000000
gdb listing, disassembly:
(gdb) list *0x066d
0x66d is in rt_dispatch (mbed-rtos/rtx/rt_Task.c:130).
125 else {
126 /* Check which task continues */
127 if (next_TCB->prio > os_tsk.run->prio) {
128 /* preempt running task */
129 rt_put_rdy_first (os_tsk.run);
130 os_tsk.run->state = READY;
131 rt_switch_req (next_TCB);
132 }
133 else {
134 /* put next task into ready list, no task switch takes place */
and
(gdb) disass 0x066d
Dump of assembler code for function rt_dispatch:
0x0000064c <+0>: push {r4, r5, r6, lr}
0x0000064e <+2>: mov r4, r0
0x00000650 <+4>: cbnz r0, 0x65a <rt_dispatch+14>
0x00000652 <+6>: ldmia.w sp!, {r4, r5, r6, lr}
0x00000656 <+10>: b.w 0x5cc <rt_dispatch>
0x0000065a <+14>: ldr r5, [pc, #44] ; (0x688 <rt_dispatch+60>)
0x0000065c <+16>: ldrb r2, [r4, #2]
0x0000065e <+18>: ldr r0, [r5, #0]
0x00000660 <+20>: movs r6, #1
0x00000662 <+22>: ldrb r3, [r0, #2]
0x00000664 <+24>: cmp r2, r3
0x00000666 <+26>: bls.n 0x678 <rt_dispatch+44>
0x00000668 <+28>: bl 0x89c <rt_put_rdy_first>
0x0000066c <+32>: ldr r3, [r5, #0]
0x0000066e <+34>: strb r6, [r3, #1]
0x00000670 <+36>: movs r3, #2
0x00000672 <+38>: str r4, [r5, #4]
0x00000674 <+40>: strb r3, [r4, #1]
0x00000676 <+42>: pop {r4, r5, r6, pc}
0x00000678 <+44>: ldr r0, [pc, #16] ; (0x68c <rt_dispatch+64>)
0x0000067a <+46>: mov r1, r4
0x0000067c <+48>: strb r6, [r4, #1]
0x0000067e <+50>: ldmia.w sp!, {r4, r5, r6, lr}
0x00000682 <+54>: b.w 0x848 <rt_put_prio>
0x00000686 <+58>: nop
0x00000688 <+60>: lsls r4, r5, #26
0x0000068a <+62>: asrs r0, r0, #32
0x0000068c <+64>: lsls r0, r2, #27
0x0000068e <+66>: asrs r0, r0, #32
End of assembler dump.
So I gather there is some issue at ...
<<code>> 0x0000066c <+32>: ldr r3, [r5, #0]<</code>>
1 Answer
10 years, 4 months ago.
oops. I should've commented on the comment/answer above. Nevermind...
What's your target? Can you include those errors?
posted by Martin Kojtal 22 Dec 2013Target is mbed LPC1768.
Here's the error:
AS is defined to use arm-none-eabi-as
And as is set up to use CC_FLAGS, but my version doesn't recognize CFLAGS like -Os and -ffunction-sections and whatnot.
Updated with some additional debugging information collected so far.
posted by Michael Shimniok 05 Jan 2014