CodeWarrior V6.3 with utasker1.4

[s2c97]

First and foremost I did search in the forum for this kind of topic and could not find any similar information.  So if I overlooked please feed me to the right link.

Question 1:  
Will I encounter any issues if I try to compile code of the latest uTaskerV1.4_M5223X with the CodeWarrior v6.3 Build 14 version?

Question 2:
If yes is there any workaround?  Or I will have to upgrade to CodeWarrior v7.0 in order to compile successfully?

The reason for these questions is because I've been encountering link errors that I will address in another post depending on the answers I will receive for the above.

kind regards,
s2c97

[mark]

Hi

It is quite a while since CW6.3 was used for the project but there is no reason why it shouldn't work.

You may find that some assembler code will not compile since 6.3 may not have supported it:

byte_rev:                                                                // {4} sub routine for reversing bytes in a long word
_byte_rev:
    byterev.l d0
    rts

This can however be removed since it is used USB and can also be solved by using a macro (see M5223X.c):

#define fnLE_add(x) ((x >> 24) | ((x >> & 0x0000ff00) | ((x << & 0x00ff0000) | ((x << 24) & 0xff000000)) // {88}

CW6.3 will probably try to convert the CW7.X project back to its format. As long as it manages this it should be OK. If it doesn't, it may need to be helped - in the worst case setting up a new project; a bit of work but not a great deal.

There should however be no reason why CW6.3 will not be able to work with the project - any issues are solvable.

Regards

Mark

[s2c97]

Ok, that's what I thought as well with CW6.3.  CodeWarrior v6.3 seems to be able to handle the back conversion from v7.0 of the project.  But I keep getting the same link errors and I do not know where it comes from (please see attached).

[mark]

Hi

These linker errors are coming from the file uTaskerBootLoader.c. This file is from the "Bare-minimum" boot loader project and not the main project - I think that you need to compile the main project (to allow SW upload via web server rather than just have the boot loader part which copies uploaded code to the application space).

Assuming the project is the boot loader one it means that the the file M5223X_boot.c is either not being included, or else the project has lost a pre-processor define (_M5223X in this case).

Check in the target setting -> language settings -> C/C++ pre-processor. The following should be there - if not copy it back and it should then be better:

#if !__option(precompile)
#include "mwerks.h" /* was "Prefix file" */
#endif
#define _M5223X
#define _CODE_WARRIOR
#define _CODE_WARRIOR_CF

The define _M5223X will enable all Coldfire related code
_CODE_WARRIOR enables a few adjustments for the compiler (eg. for pragmas)
_CODE_WARRIOR_CF controls some Codewarrior Coldfire specific stuff, such as packing control

Regards

Mark

P.S. Try also with the uTaskerV1.4 project because that is probably the only that you will finally need

[s2c97]

Actually I am trying just to get the bare minimum boot loader code project compiled.  Since I am interested to port the bootloader code to my project.  The main goal is I want to copy uploaded code to the application part.

regards,
s2c97

[s2c97]

I downloaded the CodeWarrior V7.2 free evaluation software and tried compiling the bootloader code.  And everything compiled successfully.  So this proves that I am fighting some differences between CW v6.3 and CW v7.2.  Too bad that Freescale is charging me $500 to upgrade from v6.3 to v7.2.

[mark]

Hi

Did the pre-processor defines not help? Originally the uTasker projects were developed using CW6.3 so it should be possible to use that version (although maybe with a couple of changes for project compatibility).

The boot loader is only about 2k in size so the free version (limited to 128k) should also be OK too.

Regards

Mark

[s2c97]

The pre-processor defines that I have are exactly the same.  What I did I made sure that between CW6.3 and CW7.2 I had all of the same settings and using the same files.  And now I get these link errors (see attached).

you mentioned that:

The boot loader is only about 2k in size so the free version (limited to 128k) should also be OK too.

Are you suggesting that I develop my bootcode with the free version of CW7.2 and keep on developing my custom application code project on CW6.3 since we already have a license for it?  Hmmm I like the idea 

regards,
s2c97

[mark]

Hi

These linker errors are new to me. It looks as though it is complaining about not being able to reference some addresses due to the range not being represented by a 16 bit value (+/-32k). However the code which is trying to reference, for example, _VECTOR_TABLE (at address 0x00000000), is at about 0x500 - this doesn't make much sense...

Regards

Mark

[s2c97]

Mark, I found the issue! 

I overlooked one parameter setting in CWv6.3 that was different from CWv7.2 setting in my project.  Under "[Project] Settings -> Code Generation -> ColdFire Processor", I had under the "Use .sdata/.sbss for:" window the "All data" selected.  Once I selected "All data smaller than 0 bytes"  the linker errors went away.  See attached for the settings that was causing errors.

I don't know if any of this makes sense to you or not.  If yes explanation would be appreciated.

kind regards,
romeo

[mark]

Hi Romeo

I can't explain this, I can only make some observations.

1) This looks to be setting all data to the .sdata and .sbss sections. (I think initialised variables and zeroed variables)
2) In the linker script file these sections are defined. The CW linker scripts are very similar to GCC linker scripts where there will be a data area and a bss area in RAM - I don't actually known what the difference is between .bss and -sbss (for example) (maybe static RAM rather than dynamic RAM (?) and so such variables could be accessed faster in a system with different medium)
3) The data size to be set to these area can be controlled - presumably there may be some sort of advantage in having small data blocks in this area
4) Since .bss and -sbss are in fact in the same memory areas in our case I wouldn't expect any difference but obviously there is.
5) By not putting any data to these sections (nothing is 0 in size so nothing goes there) all goes to the same area (.data and -.bss) and the problem (whatever it was) doesn't occur.

Regards

Mark