commit d4dc126b04af5e3c5167a57a6ae83cbc74804f98
author Brian Silverman <bsilver16384@gmail.com> Sun Sep 23 16:50:34 2018 -0700
committer Brian Silverman <bsilver16384@gmail.com> Sat Oct 27 16:37:02 2018 -0700
tree 4d7639994eb6ec79f5e8b417fb0c860486b7113d
parent 4787a6e480b5ec297ac81986cac42c3deac74998

Sanify the MCU linker scripts

We now have SRAM_L and SRAM_U split apart. Otherwise, it's just a matter
of time before the linker splits something across them which the
compiler tries accessing with ldrd or something and causes mysterious
problems at runtime.

Also, the new arrangement has the stack grow off the end of RAM, so
instead of clobbering the heap you'll just get a hard fault if you
overflow the stack.

Change-Id: I3c18ac665b48ddc0456e0a1ef34213dcac8e9c85

tools/cpp/CROSSTOOL

diff --git a/tools/cpp/CROSSTOOL b/tools/cpp/CROSSTOOL
index 0b1223e..c015eaa 100644
--- a/tools/cpp/CROSSTOOL
+++ b/tools/cpp/CROSSTOOL
@@ -910,7 +910,8 @@
   linker_flag: "-lstdc++_nano"
   linker_flag: "-lm"
   linker_flag: "-lc_nano"
-  linker_flag: "-Tmotors/core/kinetis_192k.ld"
+  linker_flag: "-Tmotors/core/kinetis_512_256.ld"
+  linker_flag: "-Tmotors/core/kinetis_sections.ld"
   objcopy_embed_flag: "-I"
   objcopy_embed_flag: "binary"
   compilation_mode_flags {
@@ -1112,7 +1113,8 @@
   linker_flag: "-lstdc++_nano"
   linker_flag: "-lm"
   linker_flag: "-lc_nano"
-  linker_flag: "-Tmotors/core/kinetis_128k.ld"
+  linker_flag: "-Tmotors/core/kinetis_512_128.ld"
+  linker_flag: "-Tmotors/core/kinetis_sections.ld"
   objcopy_embed_flag: "-I"
   objcopy_embed_flag: "binary"
   compilation_mode_flags {