IAR and Olimex 2378STK problem

[olimex_man]

Hi.
I´m using EWARM and the Olimex 2378stk. Just tried to compile, but the are many errors, all in the startup.s (bad instruction, expression to complex and some more).
Is there anything to change? Can not find anything about this in the tutorial.
Thanks.
Martin

[mark]

Hi Martin

If you are using the IAR project in Applications\uTaskerV1.3\IAR_LPC23XX (uTaskerV1.3.eww) it should compile without any errors. I test with IAR 4.20A.

Is there possibly an incompatibility with newer (or older) IAR assembler?

Regards

Mark

[olimex_man]

Hi Mark.
My IAR-Version is 5.11, the newest one.
You think that is the problem?

Martin

[mark]

Martin

I am very surprised if assembler code is not compatible between compiler versions but it can not be totally excluded (it may however by a compiler configuration - for example, it is trying to assemble for the wrong ARM type).

Can you check the core variant in the IAR general options- it should be ARM7TDMI.

Then take a look at some assembler code which is delivered with your IAR version to see whether you can see some differences or not.

Regards

Mark

[olimex_man]

The core variant was ARM7TDMI.
I tried it now a home witch an older version of IAR aund it works fine. So its really a problem with the newer version (witch i have at college  ).

One more question:
What changes are needed to configure the whole thing for the olimex 2378 stk? Is it only changing the board in the config.h?
Sorry for so many newbie questions.

Regards
Martin

[mark]

Hi Martin

Yes, the only change required for the Olimex is to set OLIMEX_LPC2378_STK rather than KEIL_MCB2300.

I am glad that the older IAR version compiles correctly, however it is worrying that 5.11 gives the problems. This will have to be solved at some point....

Regards

Mark

[olimex_man]

Thanks for the help.

I changed at college to my Visual Studio and the GNU_stand_alone build. This works very good too.

Regards
Martin

[Thomas]

I took a brief look at the IAR EWARM version 5 a long time ago but went back to using version 4. It seems it is a completely different set of compiler, assembler and linker (and different linker file format) than previous versions. Seemed to be GNU based or compatible..? There is a migration guide on the 5.x CD.

[mark]

Hi All

Thanks Thomas - I didn't realise they had the V5.11 as newest evaluation (although also the V4.42 is still available).
The migration guide is available on the IAR web site at:
ftp://ftp.iar.se/WWWfiles/arm/Guides/omarm_2.pdf

Basically the migration from 4 to 5 versions requires review of assembler code (various changes - things which the new assembler can't do...), C-code (different pragmas, intrinsics, ...), linker (new linker requires new sections rather than segments and new linker script files - totally new...!).

Therefore projects migrating from V4 to V5 require a careful review and test of run-time behaviour - many projects will do best to stick with the V4 due to potential danger of different behaviour as well as the extra work for the transfer.

I will get the V5.11 kick-start to see how much effort is involved. If anyone else has already done some work on this it would be good to share it here so that the same work doesn't have to be performed a multiple number of times. Unfortunately this affects all ARM projects so each one will have to be looked into, not just the LPC project.

Regards

Mark

[mark]

Hi All

Here is a quick update after installing IAR 5.11 and seeing what it did.

1. I could adapt the assembler startup file to be compatible.
2. Since there are no more intrinsic functions to enable and disable interrupts I included these also in this assembler file.
3. The initialisation of variables is handled differently - it is a bit hidden and requires calling ?main from the start up file rather than main. ?main is somewhere in the IAR part, which initialises variables (works a bit differently due to new linker) and then calls main(). This seems to be hidden in object code without any source to study.
4. The linker script was seemingly not a problem to adapt - basically use the examples supplied.
5. My feeling is that generated code size is slightly larger with V5.11 than previous versions.
6. Although I can build, there seems to be one more problem to solve. Does anyone know the equivalent method?

        #pragma segment="DATA_Z"
        #define HEAP_START_ADDRESS __segment_end("DATA_Z")

This retrieves the address of the highest used RAM location so that the uMalloc() can put its dynamic heap on it. Segments no longer exist and so somehow this needs to be found. Tips welcome!!

6.A In fact I have seen that the initialised data are not put on to of the BSS section - therefore what I need is teh address of the last initialised variable in the .data section...

7. I just noticed that the linker puts the stacks at the bottom of RAM rather than at the end. This means that code has only a predefined 1k to work with, even of the rest of the RAM is not used. This will also need to be (somehow) changed.

Regards

Mark