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. 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.
IAR EWARM vs NXP ARMs, again
Started by ●June 29, 2010
Reply by ●June 29, 20102010-06-29
"larwe" <zwsdotcom@gmail.com> wrote in message news:6385b196-7283-4d93-9767-1aca3422f0ce@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
Reply by ●June 30, 20102010-06-30
On 30/06/2010 03:13, larwe wrote:> 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.=20I 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? --=20 Regards, Richard. + http://www.FreeRTOS.org Designed for Microcontrollers. More than 7000 downloads per month. + http://www.SafeRTOS.com Certified by T=DCV as meeting the requirements for safety related systems= =2E
Reply by ●June 30, 20102010-06-30
In message <6385b196-7283-4d93-9767-1aca3422f0ce@r27g2000yqb.googlegroup s.com>, larwe <zwsdotcom@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 /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by ●June 30, 20102010-06-30
On Tue, 29 Jun 2010 19:13:31 -0700 (PDT), larwe <zwsdotcom@gmail.com> wrote:>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. 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.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
Reply by ●June 30, 20102010-06-30
I had a play around with mine and found an example for your olimex 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=92t work for (almost) anyone=92s 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=92t 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.
Reply by ●June 30, 20102010-06-30
On Jun 30, 2:00=A0am, FreeRTOS info <noem...@given.com> wrote:> You don't say which NXP ARM7 you are trying to use though. =A0Take a lookActually 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.
Reply by ●June 30, 20102010-06-30
On Jun 30, 4:25=A0am, Mike Harrison <m...@whitewing.co.uk> wrote:> It definitely does work, but some of the setup is non-obvious and you wil=l 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 =A0- ensure the watchdog is disabled=, ensure 'use flash loader'> is setI don't enable the WDT myself, I didn't see anything in the IDE that might be enabling it either. Flash loader is checked.
Reply by ●June 30, 20102010-06-30
On Jun 30, 4:43=A0am, bigbrownbeastie <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.
Reply by ●June 30, 20102010-06-30
Hi, i am using v5.50 and flash loader is selected automatically, but linker is not. Don=92t 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.