Content originally posted in LPCWare by jonper on Mon Apr 07 11:20:51 MST 2014
Testing with LPCXpresso 7.1.1 and LPCOpen 2.09 on a Keil MCB4357 with LPC-Link2:
New Project... > LPC4x > LPC43xx (Cortex-M4 basic) > LPCOpen - C Project > ... will create a project and src folder with a cr_startup_lpc43xx.c file very similar to its counterpart in the LCPOpen distribution software archives.
The wizard also creates a sysinit.c in the same src folder, but that file omits twenty lines of VTOR and FPU initialization code present in the sysinit.c that accompanies the distribution software examples.
The wizard also populates the Properties > C/C+ build > Settings > Symbols box with __USE_LPCOPEN amongst other defines.
The combination of a defined __USE_LPCOPEN conditionally excluding cr_startup_lpc43xx.c's VTOR/FPU initialization code, along with the sysinit.c missing VTOR/FPU initialization code means that these registers never get initialized.
The VTOR net effect is a big fat nothing for the majority of apps which build at their default boot location. The problem gets inadvertently covered up by the shadow ram, which also defaults to the encompassing the boot location and giving it an alternate presence at location zero; just like the default VTORs offset register. So, troubles only follow if the application loads elsewhere or if the shadow pointer gets to moved away from the boot location.
From minimal testing, the FPU net effect with Redlib, nohost, SoftABI, and DEBUGOUT("sqrt(%u) = %f\r\n", i, sqrt(i)); added to the simple main() is a hard fault.
Adding back the twenty lines of VTOR and FPU initialization code from a LPCOpen examples to the wizards sysinit.c sends out the integer and float values, and allows the base load address to depart from the norm. That is an easy enough manual workaround, but it would be kindness to new users to just have them automatically work as expected from the get-go.
