Changes when moving from Rowley crossworks V1.x to V2.x or V3.x

[mhoneywill]

Hi Mark,

I know this part of the forum has not seen any updates in ages, and will be of interest to people supporting legacy product, as we are.

We have some old Luminary projects that we are transitioning from V1.7 to V3.5 of rowley, and I wanted to document the process for others, hence me asking questions in the forum.

In the Luminary uTasker library you have the following comments in a text file

1) Install the Texas Instruments Stellaris CPU Support Package.

Open the hzp file. To do this you can right click on the solution node in the project explorer and select "Edit Solution As Text".

2) replace all occurences of Luminary_LM3S with LM3S
This is because Rowley have changed the installation directory of the support package

3) remove c_user_include_directories="$(SamplesDir)/Luminary_Stellaris_Driver_Library" linker_additional_files="$(SamplesDir)/Luminary_Stellaris_Driver_Library/lib/libdriver.a"

4) Ensure that the correct target is selected in target properties - Crossworks 2.0 includes support for the newer Tempest devices, such as LM3S9B90

Can you please explain what line 2) achieves I know it works but I'm not sure why its removed and what replaces it

We have also found that an additional step is necessary, when we were compiling the project it was not linking correctly. I mentioned this to you Mark and that we were getting the following error messages.

I get the following error message
 

Code: [Select]

1> C:/Program Files/Rowley Associates Limited/CrossWorks for ARM 3.5/gcc/arm-none-eabi/bin/ld: error: .vectors is too large to fit in FLASH memory segment
1> C:/Program Files/Rowley Associates Limited/CrossWorks for ARM 3.5/gcc/arm-none-eabi/bin/ld: error: .init is too large to fit in FLASH memory segment
Build failed
 
You mentioned that these were due to ASSERTS in the utasker supplied loader files see the lines below, and I had to comment out these lines. I'm still not sure what the problem is here but at least its compiling and linking.

Code: [Select]

  . = ASSERT(__vectors_end__ >= __FLASH_segment_start__ && __vectors_end__ <= (__FLASH_segment_start__ + 0x00040000) , "error: .vectors is too large to fit in FLASH memory segment");

  . = ASSERT(__init_end__ >= __FLASH_segment_start__ && __init_end__ <= (__FLASH_segment_start__ + 0x00040000) , "error: .init is too large to fit in FLASH memory segment");

I'll update this post with other comments as I get the projects ported

[mark]

Hi Martin

2) It is a long time ago and I don't remember the exact details but after upgrading Crossworks it would no longer link due to the fact that some Luminary Micro libraries (supplied with Crossworks and used by the compiler) were no longer found.
The reason was that the package used by Crossworks (installed as a plug-in for the processor family) was no longer at the same directory location as before. The project file contains some paths used by the linker and these were no longer valid and so the linker would error.
I think that I asked Rowley Associates and they suggested editing the project file rather than needing to rebuild the project.

3) (possibly) I also needed to remove a library entry when using a Crossworks 3.0 version and learned that it was due to the fact that the original library had been removed from the environment and integrated into a standard one.

Assert:
I don't understand the assert case since the assert was not 'firing' before but started 'firing' in a newer Crossworks release, although nothing else has changed.
In fact it looks more like the assert is 'incorrectly' firing since the check looks fine to me (it is saying that a data area of 0 size doesn't fit into the available RAM ())
The reason for the assert was simply to check that there was enough space in specific areas for the generated data, whereby it is usually easier to have the linker informing of something that may be critical than finding the cause only after debugging unexpected behavior.
The check is however not very important since I wouldn't expect it to fail unless one were to do something "extremely" wrong with the start-up code, so removing a troublesome check that looks to be incorrectly 'firing' is not a problem.

Regards

Mark