c - ARM Cortex-M3 startup file -

c - ARM Cortex-M3 startup file -

i modifying startup file arm cortex-m3 microcontroller. works fine far, have question regarding need of using assembler code perform zero-filling of bss block.

by default reset interrupt in startup file looks follows:

// 0 fill bss segment. __asm( " ldr r0, =_bss\n" " ldr r1, =_ebss\n" " mov r2, #0\n" " .thumb_func\n" " zero_loop:\n" " cmp r0, r1\n" " lt\n" " strlt r2, [r0], #4\n" " blt zero_loop" );

using code works expected. if alter previous code next stops working:

// 0 fill bss segment. for(pui32dest = &_bss; pui32dest < &_ebss; ) { *pui32dest++ = 0; }

in principle both codes should same (fill bss zeros), sec 1 not work reason fail understand. belive .thumb_func directive must play role here, not familiar arm assembler. ideas or directions help me understanding? thanks!

edit: way, code initialize info segment (e.g. re-create flash ram) follows , works fine.

// re-create info segment initializers flash sram. pui32src = &_etext; for(pui32dest = &_data; pui32dest < &_edata; ) { *pui32dest++ = *pui32src++; }

edit: added dissasembled code both functions.

assembly first looks like:

2003bc: 4806 ldr r0, [pc, #24] ; (2003d8 <zero_loop+0x14>) 2003be: 4907 ldr r1, [pc, #28] ; (2003dc <zero_loop+0x18>) 2003c0: f04f 0200 mov.w r2, #0 002003c4 <zero_loop>: 2003c4: 4288 cmp r0, r1 2003c6: bfb8 lt 2003c8: f840 2b04 strlt.w r2, [r0], #4 2003cc: dbfa blt.n 2003c4 <zero_loop>

assembly sec looks like:

2003bc: f645 5318 movw r3, #23832 ; 0x5d18 2003c0: f2c2 0300 movt r3, #8192 ; 0x2000 2003c4: 9300 str r3, [sp, #0] 2003c6: e004 b.n 2003d2 <resetisr+0x6e> 2003c8: 9b00 ldr r3, [sp, #0] 2003ca: 1d1a adds r2, r3, #4 2003cc: 9200 str r2, [sp, #0] 2003ce: 2200 movs r2, #0 2003d0: 601a str r2, [r3, #0] 2003d2: 9a00 ldr r2, [sp, #0] 2003d4: f644 033c movw r3, #18492 ; 0x483c 2003d8: f2c2 0300 movt r3, #8192 ; 0x2000 2003dc: 429a cmp r2, r3 2003de: d3f3 bcc.n 2003c8 <resetisr+0x64>

if initial stack in .bss section suggested, can see disassembly why c code fails - it's loading current pointer stack, saving incremented pointer stack, zeroing location, reloading incremented pointer next iteration. if 0 contents of stack while using them, bad things happen.

in case, turning on optimisation might prepare (a smart compiler should generate pretty much same assembly code if tries). more generally, though, it's safer consider sticking assembly code when doing things done @ level below c runtime environment - bootstrapping c environment c code expects environment exist risky @ best, since can hope code doesn't effort utilize that's not yet set up.

after quick around (i'm not overly familiar specifics of cortex-m development), seems alternative/additional solution might adjusting linker script move stack somewhere else.

c assembly arm startup cortex-m3