I'm attempting to port an application from Microchip's MPLAB-X to Keil MDK and am seeing a couple of issues I'm hoping someone else has come across and has answers to. The target device is a Microchip ATSAME51J20A Cortex-M4F, and I'm using Keil MDK Essentials V 5.43.0.0.
The first issue appears to be associated with the DFP. If I use the latest version of the Microchip::SAME51_DFP (3.8.253) the compilation fails with 'unexpected token in argument list' errors. Examining the .s file shows that it appears to be a 'C' file, rather than assembler. Rolling back the device DFP to 3.7.242 allows the application to build as expected (the .s file appears to be assembler as expected.
However.... When I run the code the processor hits a hard break with the NOCP error flag set. This suggests that the FPU isn't being detected for some reason. Setting the Floating Point Hardware option to Not Used avoids the issue, but presumably disables the FPU.
Keil and Microchip both claim the problem isn't theirs, so I'd appreciate any guidance from the forum. (cross-posted to microchip support forum
1) traditionally assembly code is typically used in the startup file. Since different assemblers use different assembly syntaxes, e.g. armasm in Arm compiler v5.x uses arm assembly syntax, while armclang in Arm compiler v6.x and gcc uses GNU Assembler syntax. Thus, in order for startup code to be as much compiler toolchain agnostic as possible, it is actually recommended now e.g. in CMSIS v6.x to use C code as startup code:https://arm-software.github.io/CMSIS_6/latest/Core/startup_c_pg.htmlThe reason why the startup_xxx.s in the latest Microchip::SAME51_DFP 3.8.253 cannot be built by Arm compiler v5.x or Arm compiler v6.x is due to a mistake Microchip has made. As you can see from the Microchip.SAME51_DFP.pdsc (just open it in your text editor), when other compiler toolchain is selected, startup_xxx.c is used as startup code. Only when arm compiler toolchain e.g. armcc is selected, startup_xxx.s is used as startup code. As you can see from the content of these startup_xxx.s file, they are simply c code. Thus, what Microchip should correct in their latest DFP pack is to rename all startup_xxx.s under the armcc subfolder to startup_xxx.c and rename them in the corresponding line in Microchip.SAME51_DFP.pdsc too. For example rename the line 2065 of Microchip.SAME51_DFP.pdsc into
name="armcc/armcc/startup_same51j19a.c"
The reason why in microchip IDE your project works with the startup code from the latest DFP pack is simply because in microchip IDE a different compiler toolchain is used, very likely it is gcc.On the other hand, the startup code startup_xxx.s under armcc subfolder of the latest DFP pack are also buggy. For example, the line 197 of startup_same51j19a.s should be modified to
.pfnSVCall_Handler = (void*) SVCall_Handler,
2) The reason for the FPU issue is because again in Microchip DFP, the FPU initialization doesn't exist in their system_xxx.c startup code. Usually, FPU initialization is a part of the system_xxx.c startup code so that FPU will be properly initialized at very beginning of main() before any FPU operation is done.If you compare the system_same51.c from our own Keil::SAME51_DFP 1.0.3 pack (although deprecated) with the system_xxx.c files from the Microchip DFP, you can see the following FPU initialization is totally missing in their SystemInit():
#if __FPU_USED /* Enable FPU */ SCB->CPACR |= (0xFu << 20); __DSB(); __ISB(); #endif
Thus, please contact Microchip for all these issues in their DFP pack.