Author Topic: frdm k64f compilation with CW10.6SE  (Read 3072 times)

Offline Bernhard

  • Newbie
  • *
  • Posts: 1
    • View Profile
frdm k64f compilation with CW10.6SE
« on: July 10, 2014, 03:47:53 PM »
Hi Mark,

thanks a lot, the simulator works. :)

I tried to compile the project utaskerKinetisV1.4.7:utaskerV1.4_FLASH with CW10.6 after importation, but after "rebuild all" I got two errors like below:
Description    Resource    Path    Location    Type
C:\Users\ESTEBA~1.MAF\AppData\Local\Temp\ccHWj4NA.s lo register required -- `ldr pc,[r0,#4]'    uTaskerKinetisV1.4.7        line 13398, external location: C:\Users\ESTEBA~1.MAF\AppData\Local\Temp\ccHWj4NA.s    C/C++ Problem

I don't know how to solve these errors.


Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3188
    • View Profile
    • uTasker
Re: frdm k64f compilation with CW10.6SE
« Reply #1 on: July 10, 2014, 04:41:16 PM »

When building for the K64 you need to set the Cortex-m4 compiler setting (rather than Cortex-m0/m0+).
You can see how to do this in the CW10.x video: (go to time 5:40).
When doing this also verify that the correct linker script file is set. For the K64 you can use K_1M_256.ld

Note that these two settings must always match the processor used:
- for K series devices chose m4, for KL and KE series devices chose m0/m0+ (some IDE versions show just m0 so either m0 or m0+ is correct)
- the linker script is set according to the device and its memory size (Flash/SRAM), eg.
K_256_16.ld is for any K series part with 256k Flash and 16k SRAM
KL_32_4 is for any KL series part with 32k Flash and 4k SRAM
KE_64_4.ld is for any KE series part with 64k Flash and 4k SRAM

In fact KL and KE linker scripts are identical inside but this avoids possible confusion. K and KL/KE linker scripts are not compatible because the parts have different SRAM memory address start/end locations.

When building an application to work with a boot loader chose the same name but with *_BM.ld (eg. K_1M_256_BM.ld for the K64).



P.S. It is in fact fortunate that the code generates an error when building with the false setting (since it wouldn't run). This is because there are a few lines of target-dependet assembler code that use instructions only available for each Cortex type, which then catches the mistake.