CW10 Including external files in .lcf, can't find file

[FridgeFreezer]

I've just (against my will) converted to CW10 from CW7.2, I've imported my old project which went as smoothly as falling off a sharp rocky cliff into a pit of spikes, and now have a glitch I can't fix.

In my old project I INCLUDEd a binary file (bootloader.bin) in the linker command file thus:

  .bootcode: {   ___Boot_START   = .;  INCLUDE bootloader_r04.bin  . = ALIGN (0x4);  ___Boot_END     =.;  } > bootcode  // Store in bootcode

 But when I try to build my project I get the following error:

Linker command file error at line 42 File not found: bootloader.bin

Which I can't seem to fix.

The bootloader is in {project}/Bootloader/ but if I put that in the .LCF (INCLUDE "Bootloader/bootloader.bin") it still isn't happy and reports:

Linker command file error at line 42 Expecting: identifier

The path "{Project}/Bootloader" is in the project settings, as is "{Project}\Bootloader" what with the buggy project settings window never actually deleting paths.

Any ideas appreciated! .

[TugboatCaptain]

Did anybody solve this?  Problem still exists in CW10.3 on Kinetis with Freescale tools.

Simple to repeat, just create a new project and add "include bootloader.bin" to any section.  Then add the bootloader.bin file to the project via right click, add files... (file contents does not matter).  On build you get this error:

>Linker command file error at line 24

>File not found: bootloader.bin

I have put the file in nearly every referenced directory of the project and it can never find it.

[trytohelp]

Hi,

So to resume the situation you add include boolarder.bin in the linker file.

When you build the project you get an error saying the .bin file was not found.

the last version is CW for MCU V10.4 released 2 months ago.

Based on this version I've created an example for MK21DN512 device.

I've create an empty file named test.bin which is included in the lcf file:

.app_text: {

ALIGNALL(4);
    * (.init)
    * (.text)
    INCLUDE test.bin
  .= ALIGN(0x8) ;
} > m_text

The test.bin file is located under the project folder: \Project_Settings\Linker_Files\test.bin

When I build it I got an error saying test.bin not found.

To solve it I added the path in the project settings.

Open the Project Properties and go to:

      C/C++ Build ¦ Settings ¦ ARM Linker ¦ Input

Add a new Additional Libraries and select the test.bin file.

Now I can build the project without problem.

Attached you will find the project example I've created.

Hope this will help you.

Regards

Pascal

[TugboatCaptain]

Thanks Pascal, answer is exactly right, the key was to add the bin file to

C/C++ Build ¦ Settings ¦ ARM Linker ¦ Input | Additional Libraries

This works in CW10.3 too.

I had also asked this as a new thread:

Include binary (.bin) file via LCF, cannot find file (CW10.3, Kinetis, Freescale toolchain)

and neglected to come back and update it here.

[radikgradinarsk]

Try to reference file path i Linker->Input->Library Search Paths, this solved my problem which was similar to yours during migration to CW10.

[FridgeFreezer]

I still haven't got this working, it's driving me crazy, does anyone have *any* ideas at all?

I've tried adding the bootloader file/path to the linker paths, copying the file to the same folder as the .LCF, using quotes, full paths, etc. and nothing is working.

[BlackNight]

Hello,

looks like the linker only takes a file as argument (not with a path).

So here is how a similar case worked for me:

a) have it like

  INCLUDE bootloader_r04.bin

b) Go to the project settings, Tab Tool Settings > ColdFire Linker > Input

  and add the path where your .bin file is to the Library Search Paths.

Hope this helps,

BK

[FridgeFreezer]

Thanks BlackNight - it's changed the problem so I'll count that as progress!

Embedded Coldfire Linker has stopped workingProblem signature:  Problem Event Name:    APPCRASH  Application Name:    mwldmcf.exe  Application Version:    6.0.0.3011  Application Timestamp:    4e3c1384  Fault Module Name:    mwldmcf.exe  Fault Module Version:    6.0.0.3011  Fault Module Timestamp:    4e3c1384  Exception Code:    c0000005  Exception Offset:    000048a2  OS Version:    6.1.7601.2.1.0.256.48  Locale ID:    2057  Additional Information 1:    0a9e  Additional Information 2:    0a9e372d3b4ad19135b953a78882e789  Additional Information 3:    0a9e  Additional Information 4:    0a9e372d3b4ad19135b953a78882e789

 

Now all I need to do is get CW10.2 to recognise my license so I can try THAT and see if it's any more stable!

[FridgeFreezer]

Well, with big thanks to Jim T, I now have a working copy of 10.2... which still crashes

I have pared the project down to almost nothing and it compiles fine when I comment out the "INCLUDE" line in the LCF, and then crashes and burns when I uncomment it.

Time to raise a support ticket I think.

[FridgeFreezer]

Well I've found the answer and it's another Freescale f***kup quite frankly

The exchange with Freescale support went as follows:

[you] need to tell the linker the path where *.bin is located.Please go to menu Project > Properties > C/C++ Build > Settings > ColdFire Linker > Input and add the path where your bootloader .bin is located.

 OK, that makes sense but I've done that and it crashes, so onto the next step...

Please notice that CodeWarrior need .rbin files in order to understand them. Not .bin.

 Um. What??? But you just said use .bin... WTF...

What the ffffffff is an .rbin file and where is this mentioned? Any why does Cw10 CRASH when given a perfectly valid .bin file as used by previous versions of CW?

OK, maybe I've been an idiot and missed something obvious - time to RTFM...

Nope, OK, let's see what the manual says about including binary files...

So the manual tells you to do something that CANNOT WORK and will CRASH the IDE - oh happy day!

So, for the benefit of any other poor fool trying to make something like this work, here is the difference between .bin and .rbin files and how to make one from the other:

CW can generate both, bin and rbin.The bin file generated by CW includes 2 long words at the beginning of the file. The first indicates the memory offset where the application begins (usually 0x00000000) and the second is the size of the file. Many programmers need this information. This is why CW generates a bin file with this information.rbin file (Raw-Binary) does not include this information. The first long word in this case is the entry point address. (third long word in .bin file). As CW does not need offset address and size it uses rbin.

 You can make an .rbin from a .bin by just deleting the first 8 bytes (2 longwords) from the start of the file.

I have to thank Jim and Carlos for helping me out bigtime and leading me to the answer, but I am really struggling with the urge to visit the Freescale CW10 developers department with a baseball bat and an invoice for wasting countless hours of our billable time on infuriating crap like this. If we could buy an old-fashioned non-eclipse version of CW that ran in Windows7 we'd jump at it, as I'm sure would many others. It wasn't a super-flashy multiple-OS twitter-enabled all-purpose behemoth, it just worked, and that is the number one feature of ANY software.

[jimtrudeau]

Just so everyone else knows, we are actively listening. Based on this item we have a defect opened and under investigation. We definitely understand the frustration. I grabbed the example project out of the service ticket, and have that in the R&D team to replicate the issue for the defect analysis. Forums ARE useful. THANK YOU!

[FridgeFreezer]

I've opened a support ticket for correcting the manual - 1-859913344

Thanks again to Jim and the small band of guerilla resistance working away in the belly of the beast fighting the good fight, I know what a thankless task it can be!

[FridgeFreezer]

Well, I thought I had found the reason for the crashing but it seems I haven't. I suspected that the .bin file crashed the linker because it was 8 bytes too long for the slot, however on investigation that was not the case, the .bin file I'm using is the correct length.

What's more, I am now doubting the output from CW based on the .bin/.rbin file.

Using CW7.2 we have a compiled bootloader.bin file which starts at address 0x0000000 with the data from vectors.s:

0x20010000 (initial SP)

0x00000C70 (initial _asm_startup)

...(rest of vectors.s)

When this file is included in our original project built in CW7.2 the resulting s-record output is:

S3FD000000002001000000000C70....

Which looks to me like the 0x20010000, 0x00000C70 is being written to address 0x00000000 and 0x00000004 respectively.

Perhaps most importantly, neither of these numbers are the length of the .bin file (0x4000) or the address offset (0x00000000) which the explanation above says they should be, and CW7.2 writes this data straight into the .s19.

However, if I include the .rbin file (first 8 bytes of .bin removed) it jumps straight in with line 3 of vectors.s at address 0x00000000.

Which then compiles to the same in the .s19:

S3FD00000000000042C4000042C4....

(0x42C4 is the asm_exception_handler which is not where we want to start at reset!)

Yet the explanation above suggests that we should be producing the same code from a .bin file in CW7 and from an .rbin file in CW10.

So, it looks like there is another discontinuity in CW's behaviour or documentation thereof - possibly with CW7.2 rather than CW10 - that the .bin file generated by CW7 does NOT include the length/offset data.

This brings several issues out:

 - CW10's linker crashes when given the original file renamed ".rbin" despite the fact that it is the correct length and contains only the raw binary data.

- If we delete 8 bytes from the end (all 0xFF's) of the .bin file, the linker then works correctly.

- Because of the way the debugger works it would be very easy to miss the fact that the bootloader code had been broken by this problem

- Although we can "fix" the resulting .s19 with a text editior, it would be nice not to have to.

[FridgeFreezer]

Yep, I'm not going mad, dropping 8 bytes off the end of the .bin to make an .rbin results in this .XMAP output from CW10:

# .abs__UserEntry  00004000 00000004 .abs    UserEntry (main_c.obj)# .abs__UserEntry2  00004004 00000004 .abs    UserEntry2 (main_c.obj)# .ipsbar# .bootcode#>00000000          ___Boot_START (linker command file)# 00000000 00003FF8 (Included file: bootloader_r04_trim.rbin)#>00003FF8          ___Boot_END (linker command file)

# .flash
  00004010 00000096 .text   somefunction    (somecode_c.obj)

Compared to CW7.2:

# .abs__UserEntry  00004000 00000004 .abs    UserEntry (main.c)# .abs__UserEntry2  00004004 00000004 .abs    UserEntry2 (main.c)# .ipsbar# .bootcode#>00000000          ___Boot_START (linker command file)# 00000000 00004000 (Included file: bootloader_r04.bin)#>00004000          ___Boot_END (linker command file)# .flash  00004010 00000000 .text   VECTOR_TABLE (mcf5225x_vectors.s)

[FridgeFreezer]

A slight correction to my previous post: Our .bin file was obtained through https://community.freescale.com/message/59178#59178 which explains the lack of the first 8 bytes. However, that does not change the actual problem that CW10 can't link a valid .bin/.rbin file.

[FridgeFreezer]

Just tried knocking a single byte off the end of the .bin file and it compiles OK, albeit the resulting S-records are not identical to the old version:

The resulting S-record for the last line is:

S31500003FF0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFF00CA

Compared to the original CW7.2 output:

S31500003FF0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFCB

(We allowed a generous amount of space for the bootloader so the top end of the area is filled with 0xFF / blank)

[dataScout]

if using the SREC is a solution for you, you can just update those 2-bytes of the SREC (they should always be FFCB if you have only FF on the 3FF0 line)

[FridgeFreezer]

Very true, but using Notepad to correct a $1000 development suite seems like missing the point a bit