EmbeddedRelated.com
Forums

IAR EWARM vs NXP ARMs, again

Started by larwe June 29, 2010
> At least I would expect the toolchain to > generate executable code that could be flashed into the device > externally,
project options -> output converter -> generate additional output
 the linker file in the LPC2106 project  is 'LPC2106_JLink.icf'

i will put my invoice in teh post to you.
BTW, why are you using LPC2138 or LPC2106? those parts died out years
ago for new designs

On Jun 30, 11:01=A0am, bigbrownbeastie
<bigbrownbeastiebigbrownf...@googlemail.com> wrote:
> > At least I would expect the toolchain to > > generate executable code that could be flashed into the device > > externally, > > project options -> output converter -> generate additional output
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.
On Jun 30, 11:12=A0am, bigbrownbeastie
<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...
In message <d3484abc-ffd5-44ef-8b8b-2f9f46f6993d@b35g2000yqi.googlegroup
s.com>, bigbrownbeastie <bigbrownbeastiebigbrownface@googlemail.com>
writes
>> At least I would expect the toolchain to >> generate executable code that could be flashed into the device >> externally, > >project options -> output converter -> generate additional output
Some people know so much they don't read manuals....... -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
On Jun 30, 12:29=A0pm, 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, 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.
On Wed, 30 Jun 2010 07:56:49 -0700 (PDT), bigbrownbeastie
<bigbrownbeastiebigbrownface@googlemail.com> wrote:

>Hi, i am using v5.50 and flash loader is selected automatically, but >linker is not. Don&#4294967295;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.
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!
On Wed, 30 Jun 2010 08:12:54 -0700 (PDT), bigbrownbeastie
<bigbrownbeastiebigbrownface@googlemail.com> wrote:

>BTW, why are you using LPC2138 or LPC2106? those parts died out years >ago for new designs
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.
On Wed, 30 Jun 2010 04:42:38 -0700 (PDT), larwe <zwsdotcom@gmail.com> wrote:

>On Jun 30, 4:25&#4294967295;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