Running assembler functions from SRAM ends up on HardFault_Handler()

[lpcware]

Content originally posted in LPCWare by jookie on Wed Jun 13 08:40:33 MST 2012
Hello,

I'm trying to make my assembler functions run from SRAM of my LPC1343. As shown in other examples I tried to use the ram_func() like this:

declaration:
void ram_func();

definition:
__attribute__ ((__section__(".data.ramfunc")))
void ram_func() {
  __asm volatile ("nop\n\t" );
}

usage:
ram_func();

...and everything goes well. Now I try to do something similar with my assembler function written in separate .s file.

declaration:

extern void DataAsInput();

in .s file:

.section .data.ramfunc

 .syntax unified
 .cpu cortex-m3
 .thumb
 .align4
 .globalDataAsInput
 .thumb_func

DataAsInput:
push{r3, r4, lr}

ldrr3, = PIO2_DIR
movr4, # ACSI_DATA_IN
str.wr4, [r3]

 pop{r3, r4, lr}

 bxlr

...and I call it like this:
DataAsInput();

- this crashes on the first instruction (push {...}) -- ends up on void [B]HardFault_Handler(void)[/B]. When I let it run from the flash (that means I don't put there the '.section .data.ramfunc' line), everything runs well. From the .map file I see that both functions (ram_func() and DataAsInput()) are located in SRAM:

 .data.ramfunc  0x10000000      0x320 ./src/bridge.o
...
                0x10000060                DataAsInput
...
 .data.ramfunc  0x10000320       0x18 ./src/main.o
                0x10000320                ram_func
                0x10000338                . = ALIGN (0x4)
                0x10000338                _edata = .

...but there seems to be something wrong anyway. I'm trying to locate my assembler functions in SRAM due to performance, and having it all in __asm volatile ("..."); is bit annoying. So, where's the catch?

Miro

[lpcware]

Content originally posted in LPCWare by jookie on Thu Jun 14 00:26:36 MST 2012
CodeRedSupport, thank you, that totally helped! For the future cases, is there a way to tell if this sort of thing is happening in debugger (the ARM vs. Thumb-2 stuff)?

Btw. - my performace issue was due forgetting to set the system clock to 72 MHz :)

Miro

[lpcware]

Content originally posted in LPCWare by CodeRedSupport on Wed Jun 13 12:43:21 MST 2012
Try changing your section statement to:

.section .data.ramfunc,"ax",%progbits

Without this, your function is being treated as a data label, which causes it to not get the bottom bit of its address to be set. This causes the linker to try to treat the function call as a Thumb to ARM interworking call and use a BLX instruction. Changing to ARM state like this causes a hard fault on Cortex-M parts (as ARM state doesn't actually exist).

Regards,
CodeRedSupport.