It looks like a problem with the linker script. Puzzling out what the error message means, it looks like it faulted trying to do a word access to memory at 0x810000A. After compiling it myself and having objdump do a disassembly, that seems to support my initial conclusion, and the offending code seems to be part of crt0:
Code: 00300018 <dataDone>:
300018: d2 13 mov.l 300068 <v_ram_ebss>,r2 ! 810000e
30001a: d3 12 mov.l 300064 <v_ram_bbss>,r3 ! 810000a <_bbss>
30001c: e1 00 mov #0,r1
0030001e <bssLoop>:
30001e: 32 32 cmp/hs r3,r2
300020: 8b 01 bf 300026 <bssDone>
300022: af fc bra 30001e <bssLoop>
300024: 22 16 mov.l r1,@-r2
Note the word access to 810000a.
I think setting some section alignment in the linker script should fix it:
Code: SECTIONS
{
/* Code, in ROM */
.text : {
*(.pretext) /* init stuff */
*(.text)
*(.text.*)
} > rom
/* Read-only data, in ROM */
.rodata ALIGN(4): {
*(.rodata)
*(.rodata.*)
} > rom
/* RW initialized data, VMA in RAM but LMA in ROM */
.data ALIGN(4): {
_bdata = . ;
*(.data)
*(.data.*);
_edata = . ;
} >ram AT>rom
/* Uninitialized data (fill with 0), in RAM */
.bss ALIGN(4): {
_bbss = . ;
*(.bss) *(COMMON);
_ebss = . ;
} >ram
}
I'd guess you uncovered this problem partially by chance and partially through your zealous use of shorts. Compare to Kerm, whose code seems to mostly use ints instead, which are 32 bits wide on SH targets and hence will have no alignment issues. Your shorts open up the possibility of such unaligned accesses moreso.
This brings up that I had at some point hoped to optimize the crt0 routines a little more to handle such unaligned cases, but at this point I think having smaller initialization code is preferable to having it be slightly faster.