IAR EWARM vs NXP ARMs, again
larwe
with an NXP ARM7, and I'm heading to the conclusion that this
toolchain simply doesn't work with NXP. Here's what happens - it's
really weird, so maybe someone can explain:
- Create an empty C main project (main just returns 0)
- Select the correct chip as target
- Select J-Link as the debugger
- Uncheck the "run to main" box
Starting debug, you can single-step through the startup code until it
jumps to ?main, where it encounters this code:
?main:
00000180 E3A00001 MOV R0, #0x1
00000184 EBFFFFF4 BL ?Veneer (0) for __low_level_init ;
0x15C
00000188 E3500000 CMP R0, #0x0
0000018C 1BFFFFCF BLNE __iar_data_init2 ; 0xD0
__iar_init$$done:
00000190 E3A00000 MOV R0, #0x0
00000194 EBFFFFF3 BL ?Veneer (0) for main ; 0x168
Here's where it gets weird. When you try to step over the BLNE
instruction, the J-Link programming window pops up again, and the
debugger doesn't get to the next instruction - it looks like it's
still running. Hitting the break button shows that the CPU is now
stuck at the abort vector. It never reaches main.
Same behavior, though slightly different code, if ARM mode is selected
rather than Thumb. I've tried this on a Keil MCB2130 (LPC2138) and an
Olimex LPC2106 board, identical results. Does anyone have a clue what
could be causing this?
It's really whacked out. IAR's sales rep has called me several times
asking if I'm going to write a check for $4,000 for a single node
license for this compiler. Quite the comedian.
Chris Burrows
news:6385b196-7283-4d93...@r27g2000yqb.googlegroups.com...
>
> It's really whacked out. IAR's sales rep has called me several times
> asking if I'm going to write a check for $4,000 for a single node
> license for this compiler.
Next time he calls ask him to transfer you to one of their tech experts to
answer your question. You will either get it fixed or you won't hear from
him again ;-)
Alternatively, see if anybody in the LPC2000 Yahoo Tech group can help:
http://tech.groups.yahoo.com/group/lpc2000
Regards,
Chris Burrows
CFB Software
Astrobe: ARM Oberon-07 Development System
http://www.astrobe.com
FreeRTOS info
> I found my J-Link lying around and tried again to get IAR to play nice
> with an NXP ARM7, and I'm heading to the conclusion that this
> toolchain simply doesn't work with NXP.
I can assure you it does - I have used it many many times.
You don't say which NXP ARM7 you are trying to use though. Take a look
in the IAR examples directory to see if there is a sample project for it
- then use that as a base for your project (use the same start up code,
debugger macros, project settings, etc.). Once you have it working you
can remove their demo code, and add in your own.
Are you using an up to date version of IAR?
--
Regards,
Richard.
+ http://www.FreeRTOS.org
Designed for Microcontrollers. More than 7000 downloads per month.
+ http://www.SafeRTOS.com
Certified by TÜV as meeting the requirements for safety related systems.
Chris H
s.com>, larwe <zwsd...@gmail.com> writes
>I found my J-Link lying around and tried again to get IAR to play nice
>with an NXP ARM7, and I'm heading to the conclusion that this
>toolchain simply doesn't work with NXP.
Then you are doing something wrong... thousands of people are
successfully using the Segger J-link and IAR suite on NXP ARM7 parts.
Including NXP.
As I have said before I have noticed that over the years you seem to
have problems with most professional tools companies. As many people are
successfully using the combination you say does not work it seems "the
workman is blaming his tools".
>It's really whacked out. IAR's sales rep has called me several times
>asking if I'm going to write a check for $4,000 for a single node
>license for this compiler. Quite the comedian.
So why is the IAR salesman a "comedian"? it is you who are unable use a
professional development suite as thousands of others clearly can. For
comedian try a mirror.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Mike Harrison
It definitely does work, but some of the setup is non-obvious and you will struggle to get there
from a blank project.
However there are plenty of sample projects in the IAR installation dir, targetted at their
kickstart boards - look at the linker and debugger settings in these.
A couple of quick things from memory - ensure the watchdog is disabled, ensure 'use flash loader'
is set
bigbrownbeastie
board in :
Help -> information Centre
Example Project -> NXP -> LPC2106 -> IAR Kickstart card (same as
olimex)
By the way you have described, you have started an ARM project from
scratch and therefore will have ARM defaults or nothing for linker,
flash loader, debugger setup etc. Since ARM is not so well
standardised these settings won’t work for (almost) anyone’s part.
Since you have not said the linker config file, flash loader setting
or debugger setup macro needed it sounds like you are far from setting
up.
As others pointed out it is worth looking at the examples instead of
trying to build from scratch if you are new to a tool chain/
architecture. It will be like trying to jump in to a single seater
race car for the first time and get angry at it for stalling at the
lights.
As far as I know when you single step to the next statement the
debugger then programs in the next expected address in as a breakpoint
(two hardware breakpoints in ARM7). However for some reason actual
program execution does not reach this point, and this is why it
doesn’t halt (just runs and runs until you hit break and the debugger
reads the PC). This also points to the fact that there is an error
with memory locations....... linker
p.s sales is the most powerful guy in the company as he can call on
any resources that breaks down barriers to potential clients
purchasing. You should just simply send him an email with the issue
and ask to pass it to tech support. I would expect they will help you
get the examples up and running as a first step.
larwe
> You don't say which NXP ARM7 you are trying to use though. Take a look
Actually I did: "Keil MCB2130 (LPC2138) and an Olimex LPC2106"
> Are you using an up to date version of IAR?
Latest version from their website as of two weeks ago.
larwe
> It definitely does work, but some of the setup is non-obvious and you will struggle to get there
> from a blank project.
This is very strange. According to an earlier message from their tech
support, the linker (inter alia) is aware of what specific device
you've picked for the project, and for instance will automatically
generate the correct bootloader checksum for devices that require it.
The impression I got from his email is that it is largely automated
(which is after all the only reason why I use an IDE - to get running
quickly without manually editing linker scripts and learning command
line switches).
Grr. It Just Worked with RiDE... the Raisonance guys seem to be more
on the ball. The only thing about RiDE is that it only works with the
RLink debugger, or you can build and load a hex file with the chip's
bootloader.
The 32K eval version of IAR would have been all I need, and I have the
right JTAG adapter for it already, which is why I'm taking a second
bite at it.
> A couple of quick things from memory - ensure the watchdog is disabled, ensure 'use flash loader'
> is set
I don't enable the WDT myself, I didn't see anything in the IDE that
might be enabling it either. Flash loader is checked.
larwe
<bigbrownbeastiebigbrownf...@googlemail.com> wrote:
> I had a play around with mine and found an example for your olimex
> board in :
Hmm, thanks, I will play with it again tonight.
> By the way you have described, you have started an ARM project from
> scratch and therefore will have ARM defaults or nothing for linker,
Riiight... but I'm still left a bit puzzled. Other IDEs generally use
the device selection and do all the work for you in terms of selecting
the right linker script, crt???.s etc etc. And IAR is clearly doing
SOME of this because for instance it will complain if you build code
that's too big for the chip.
It's not like I have external user-provided flash on this chip - all
its characteristics, memory map, required C startup etc. are known and
if the compiler mfr claims "supports device xxx" I would assume this
means they include the required startup code and linker stuff in the
box. Other vendors do! At least I would expect the toolchain to
generate executable code that could be flashed into the device
externally, even if it can't automatically set up the correct JTAG
debugger parameters.
bigbrownbeastie
linker is not. Don’t see why you do not take the advice from others
here and use the prebuilt example with provided linker file,
flashloader, header files, debugger files etc instead of starting with
a blank project.
EWARM will not complain if the chip is full, the IAR linker will
however complain if you try and fit more code then will fit into
the .ROM region.... two different things.
Just because you are not using external flash does not mean you can
use default 'ARM'. Also you may need to modify the linker file
provided for NXP memory for example place a checksum or boot loader in
specific place etc etc real embedded eng need to understand control of
the linker.
p.s some WDT are enabled by default at start-up, not sure that is the
case for your part but could also cause some issues.
bigbrownbeastie
> generate executable code that could be flashed into the device
> externally,
project options -> output converter -> generate additional output
bigbrownbeastie
i will put my invoice in teh post to you.
bigbrownbeastie
ago for new designs
larwe
I know how to drive EW thus far (I use it in my day job, for both
MSP430 and ARM, though the ARM projects are admittedly pre-existing,
not hand-built)... You missed the earlier thread I posted on this
topic. The .HEX files generated by this only work in the simulator -
they don't work when loaded onto the target part. And no it is not a
RAM vs ROM startup issue, because the code actually looks OK and is
certainly org'd at the correct address (and verifies OK when read back
from the part).
And I am not compiling for "generic ARM", I realize now you are
operating under a misconception there - I am building for the specific
device. As a rule - I think almost universally - the other toolchains
I use will automatically select a workable linker config when the
device is selected. I asked IAR tech support to provide a list of
exactly what needs to be edited to build a config from scratch, but I
am thinking it is unlikely I'll be buying the product, since it is
unnecessarily difficult to use compared to the competitors.
Note; it is *very* rare that I need to tweak linker settings manually.
In fact since I wrote my first book on the topic, I doubt that I have
had to edit a linker script myself except maybe relocating a couple of
sections to match changes in MMU configuration, which doesn't often
happen. What is it you do that needs so much manual poking?
I think in fact on 8-bit/16-bit projects I have *NEVER* needed to edit
any linker settings manually. And never on 32-bit projects that use a
big OS like Linux, either (assuming I already had a working bootloader
from somewhere). Only on some middle-sized 32-bit projects where I
have had to do some poking with the way the OS is set up, and in
academic projects like my first book.
larwe
<bigbrownbeastiebigbrownf...@googlemail.com> wrote:
> BTW, why are you using LPC2138 or LPC2106? those parts died out years
> ago for new designs
I only need to build about 75 pieces of this product. I happen to have
half-reels of both LPC2103 and LPC2131 lying about, and roughly 100pcs
of the surplus cellphone LCDs that will be used with it. So it will
save me about $1000 to use these surplus parts vs buying current-
production chips. For a product I'm giving away free of charge, why
not use what I can get?
(Besides, those chips are still on NXP's active list and per their
rep, will be available for the foreseeable future).
Silk purse, sow's ear...
Chris H
s.com>, bigbrownbeastie <bigbrownbeast...@googlemail.com>
writes
Some people know so much they don't read manuals.......
larwe
> >project options -> output converter -> generate additional output
>
> Some people know so much they don't read manuals.......
If you're going to bitch endlessly that I didn't buy whatever you were
pimping ten years ago, you could at least have the speck of decency
and intelligence it would require to actually READ my postings. Or
maybe you're just a macro that pops up to squawk "FOSS BAD! Braaaark!"
every time you see a post from me, like some kind of demented, dongle-
protected and nodelocked parrot.
Mike Harrison
Be warned that in some cases EWARM does not know the different memory limits for different ARM
variants -not sure if it's just a device config files of a more fundamental issue. I found this when
I changed a project from LPC2136 to 2132 & eventually figured outt that the linker still thought
the part had 32K RAM!
Mike Harrison
Familiarity, existing code base, existing PCBs....
I would dispute 'years ago' - they fixed a silicon bug (timer reset value) in the 213x fairly
recently. Annoyingly it was a bug that just plain didn't need fixing, and the change undoubtedly
caused more problems than leaving it as just documented would have.
Mike Harrison
>On Jun 30, 4:25 am, Mike Harrison <m...@whitewing.co.uk> wrote:
>
>> It definitely does work, but some of the setup is non-obvious and you will struggle to get there
>> from a blank project.
>
>This is very strange. According to an earlier message from their tech
>support, the linker (inter alia) is aware of what specific device
>you've picked for the project, and for instance will automatically
>generate the correct bootloader checksum for devices that require it.
I think this is generated by the flash loader, not the linker. A while ago when I was writing some
IAP code, I had to generate the checksum myself - it was not included in the hex file.
>The impression I got from his email is that it is largely automated
>(which is after all the only reason why I use an IDE - to get running
>quickly without manually editing linker scripts and learning command
>line switches).
>
>Grr. It Just Worked with RiDE... the Raisonance guys seem to be more
>on the ball. The only thing about RiDE is that it only works with the
>RLink debugger, or you can build and load a hex file with the chip's
>bootloader.
>
>The 32K eval version of IAR would have been all I need, and I have the
>right JTAG adapter for it already, which is why I'm taking a second
>bite at it.
Stick with it - once you get familiar with setting it up right it is a very nice IDE, and there are
free versions for a number of processor families including AVR and MSP430
larwe
> >This is very strange. According to an earlier message from their tech
> >support, the linker (inter alia) is aware of what specific device
> >you've picked for the project, and for instance will automatically
> >generate the correct bootloader checksum for devices that require it.
>
> I think this is generated by the flash loader, not the linker. A while ago when I was writing some
> IAP code, I had to generate the checksum myself - it was not included in the hex file.
According to tech support, it is the linker and it is automatic as
long as you don't remove or change the label for the appropriate
vector. But that might be a recent innovation.
> Stick with it - once you get familiar with setting it up right it is a very nice IDE, and there are
> free versions for a number of processor families including AVR and MSP430
I actually use it (although an older version) extensively at work for
ARM7 projects. We've moved away from IAR for MSP430 - Rowley is
better, not to mention cheaper. I do use the Kickstart version for
some of my home MSP430 projects; since they upped the code size from
2K to (?)8K, it's become really useful for a wide range of projects.
For AVR, I use WinAVR at home and Rowley at work. I don't work with
PIC if I can avoid it, but when I do, I'm either using raw asm or
CCS's compiler.
The thing is, those work projects were all old (>10 years, some of
them) projects that have been rolled into progressively newer and
newer compilers. They've been on EWARM for a long time already and all
the magical build steps are set up (some of them being seriously
magical).
Chris H
.com>, larwe <zwsd...@gmail.com> writes
>On Jun 30, 12:29�pm, Chris H <ch...@phaedsys.org> wrote:
>
>> >project options -> output converter -> generate additional output
>>
>> Some people know so much they don't read manuals.......
>
>If you're going to bitch endlessly that I didn't buy whatever you were
>pimping ten years ago,
I wasn't selling
>you could at least have the speck of decency
>and intelligence it would require to actually READ my postings. Or
>maybe you're just a macro that pops up to squawk "FOSS BAD! Braaaark!"
>every time you see a post from me, like some kind of demented, dongle-
>protected and nodelocked parrot.
It is you than does knee jerk reactions. Time after time after time....
Hans-Bernhard Bröker
> It is you than does knee jerk reactions. Time after time after time....
That's rich, coming from you of all people.
You don't get to make that particular accusation stick until you manage
_not_ to throw in you standard reaction as soon as anyone dares to as
much as mention any open-source tool. You're by far the most reliable
knee-jerker around here, and I'm sure you know that.