[BUG] Initialize Entry for S32K144EVB

I'm assuming this gets loaded into address 0? The ELF header lists 0 as the entrypoint, at least. It looks like there's a valid Cortex-M IVT there, with the stack pointer starting at 0x20002000 and the entrypoint at 0x11d, with a lot of uninitialized vectors:

(gdb) p/x *(unsigned int)0@32
$3 = {0x20002000, 0x11d, 0xd9, 0x4f9, 0xd9, 0xd9, 0xd9, 0xd9, 0xd9, 0xd9, 0xd9, 0x99, 0xd9, 0xd9, 0xd9, 0x81, 0xb580e7fe, 0xf000466f,
  0xe7fef801, 0x466fb580, 0xfafaf000, 0xfac8f000, 0x4080e8bd, 0xbadcf000, 0xaf02b5d0, 0xf0004604, 0xb108fb0c, 0xbdd06820, 0x211c4802,
  0xfbf6f000, 0xbf00defe, 0x142c}
(gdb)

That's looking good! You can see the systick handler at 0x81 and the svc handler at 0x99. So we know that's correct.

In looking at the ELF header, it looks like the .relocate section genuinely is empty:

$ arm-none-eabi-readelf.exe -S C:\Users\Sean\Desktop\s32k144evaluationkit.elf
There are 23 section headers, starting at offset 0x1e932c:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .stack            NOBITS          20000000 000134 002000 00  WA  0   0  1
  [ 2] .text             PROGBITS        00000000 000140 0028f0 00 AXM  0   0 16
  [ 3] .ARM.exidx        ARM_EXIDX       000028f0 002a30 000010 00  AL  2   0  4
  [ 4] .storage          PROGBITS        00002900 002a40 000700 00   A  0   0  1
  [ 5] .apps             PROGBITS        00004000 003140 000004 00   A  0   0  1
  [ 6] .relocate         PROGBITS        20002000 003144 000000 00   A  0   0  1
  [ 7] .sram             NOBITS          20002000 003144 00001c 00  WA  0   0  4
  [ 8] .debug_abbrev     PROGBITS        00000000 003144 007802 00      0   0  1
  [ 9] .debug_info       PROGBITS        00000000 00a946 080f74 00      0   0  1
  [10] .debug_aranges    PROGBITS        00000000 08b8ba 0048a0 00      0   0  1
  [11] .debug_str        PROGBITS        00000000 09015a 06fe41 01  MS  0   0  1
  [12] .debug_pubnames   PROGBITS        00000000 0fff9b 02e225 00      0   0  1
  [13] .debug_pubtypes   PROGBITS        00000000 12e1c0 0270a6 00      0   0  1
  [14] .ARM.attributes   ARM_ATTRIBUTES  00000000 155266 000032 00      0   0  1
  [15] .debug_frame      PROGBITS        00000000 155298 00c044 00      0   0  4
  [16] .debug_line       PROGBITS        00000000 1612dc 01eb4e 00      0   0  1
  [17] .debug_loc        PROGBITS        00000000 17fe2a 051650 00      0   0  1
  [18] .debug_ranges     PROGBITS        00000000 1d147a 013c30 00      0   0  1
  [19] .comment          PROGBITS        00000000 1e50aa 000013 01  MS  0   0  1
  [20] .symtab           SYMTAB          00000000 1e50c0 0015d0 10     22 262  4
  [21] .shstrtab         STRTAB          00000000 1e6690 0000f1 00      0   0  1
  [22] .strtab           STRTAB          00000000 1e6781 002ba9 00      0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
  L (link order), O (extra OS processing required), G (group), T (TLS),
  C (compressed), x (unknown), o (OS specific), E (exclude),
  y (purecode), p (processor specific)
$

So it is correct in assuming that the data section is 0 bytes long, because it actually is.

I actually don't see any variables in RAM, so it may very well be that there aren't any, and the relocation section genuinely is 0 bytes long. You might try creating something you know exists, just to see if it becomes nonzero. Try sticking this somewhere in one of your source files and seeing if it doesn't add something to the relocation section:

use core::sync::atomic::AtomicUsize;
#[used]
#[no_mangle]
pub static USED_VARIABLE: AtomicUsize = AtomicUsize::new(0);

As for the breakpoint -- is that what happens when you step one instruction beyond it looks like it's maybe trying to write 0xffffffff to 0xe000e100 which is triggering a HardFault.

Actually, what may be happening is that you're enabling all interrupts, but you've only defined the first 16 vectors -- the following 16 vectors are garbage, and in fact aren't valid thumb addresses since most of them are aligned. The S32K144 looks like it has 122 external interrupts, which you should define.

Here's how the nrf52 does it for 80 interrupts:

https://github.com/Ion-Mobility/tock/blob/4eb00abf683bf615fdbeaf02843d667b88bc394e/chips/nrf52/src/crt1.rs#L62-L68

See if adding that doesn't fix things. It may be that an interrupt is firing as soon as you enable the NVIC, which is immediately sending you into the hardfault handler.

Ion-Mobility / tock

[BUG] Initialize Entry for S32K144EVB #5