Linux+FreeRTOS early bootstrapping problems

Discussion created by lpcware Employee on Jun 15, 2016
Latest reply on Jun 15, 2016 by lpcware
Content originally posted in LPCWare by omegahacker on Sat May 10 18:14:43 MST 2014
Disclaimer: I'm just getting started on ARM finally, but I'm intimately familiar with bare-metal MCU development otherwise, specifically on AVR Xmega.

My end goal is to get a FreeRTOS build running on the M0 under the control of a ucLinux kernel on the M4.  I'm using Emcraft's BSP, which gets me to the point of being able to compile code and run it over NFS, no problems there so far.

At this point I'm just trying to get *anything* running on the M0.  I've written a trivial test program:

#include "lpc43xx.h"

void main() __attribute__ ((naked));
void main() {
  LPC_SCU->SFSPE_5 = 4;
  LPC_GPIO_PORT->DIR[7] |= (1<<5);
  while (1) ;

I compile and generate a *raw* binary image with:

arm-uclinuxeabi-gcc -O0 -I. -mcpu=cortex-m0 -mthumb -c test.c -o test.o
arm-uclinuxeabi-objcopy -O binary test.o test.bin

This results in the following assembly:

00000000 <main>:
   0:   4a06            ldr     r2, [pc, #24]   ; (1c <main+0x1c>)
   2:   4b07            ldr     r3, [pc, #28]   ; (20 <main+0x20>)
   4:   2104            movs    r1, #4
   6:   50d1            str     r1, [r2, r3]
   8:   4a06            ldr     r2, [pc, #24]   ; (24 <main+0x24>)
   a:   4906            ldr     r1, [pc, #24]   ; (24 <main+0x24>)
   c:   4b06            ldr     r3, [pc, #24]   ; (28 <main+0x28>)
   e:   58c9            ldr     r1, [r1, r3]
  10:   2320            movs    r3, #32
  12:   4319            orrs    r1, r3
  14:   4b04            ldr     r3, [pc, #16]   ; (28 <main+0x28>)
  16:   50d1            str     r1, [r2, r3]
  18:   e7f2            b.n     0 <main>
  1a:   46c0            nop                     ; (mov r8, r8)
  1c:   40086000        .word   0x40086000
  20:   00000714        .word   0x00000714
  24:   400f4000        .word   0x400f4000
  28:   0000201c        .word   0x0000201c

I've confirmed that the .bin file does indeed have those exact bytes in it.

In order to start up M0, I chose 0x10080000 as the memory I want it to run out of, and proceed to load that binary file:

  uint8_t *region = 0x10080000;
  fd = open("test.bin",O_RDONLY);

I set LPC_CREG->M0APPMEMMAP to 0x10080000, then clear the M0APP_RST bit in LPC_RGU->RESET_CTRL1.  This *should* start up the M0 and then exit the program, while the M0 will light an LED on the board and spin forevermore.

Unfortunately, all it ends up doing is freezing the entire board.  I don't have JTAG hooked up yet because I have to find an openocd configuration that will do the trick.

Any hints on what's going wrong here?  I've looked at several dualcore examples from NXP and Keil etc, and I'm doing exactly the same as they are, except I'm doing it from within a compiled linux "application".  I have yet to see any hint that there's a reason why that shouldn't work, but like I said I'm new to the ARM stuff.