EmbeddedRelated.com
Forums
Memfault Beyond the Launch

Getting started with IAR+MCB2130?

Started by larwe June 12, 2010
I'm trying to get up and running on the MCB2130 using IAR Kickstart to
build and FlashMagic to load the code.

Do I need to write my own startup code for this configuration? Since I
don't have a JTAG adapter that's compatible with IAR, I have to build
a flash-resident app and serial-load it, but of course I'm operating
100% blind. For test purposes I just copied some stuff out of blinky.c
and changed the IO names to match what's in the IAR headers, as below.

I can load and verify code OK, but the 8 LEDs remain stuck on even
when I detach the serial port. I did check in the .map file and it put
intvec @ 0 and _main() at 0x1c4, so it seems to be sane - it seems
like it should Just Work, but doesn't.

  IO1DIR = 0x00FF0000;                     /* P1.16..23 defined as
Outputs  */

  while (1) {                              /* Loop forever */
    for (n = 0x00010000; n <= 0x00800000; n <<= 1) {
      /* Blink LED 0, 1, 2, 3, 4, 5, 6, 7 */
      IO1SET = n;                          /* Turn on LED */
      delay();                             /* Delay */
      IO1CLR = 0x00FF0000;                 /* Turn off LEDs */
    }
  }

larwe wrote:

> I'm trying to get up and running on the MCB2130 using IAR Kickstart to > build and FlashMagic to load the code. > > Do I need to write my own startup code for this configuration? Since I > don't have a JTAG adapter that's compatible with IAR, I have to build > a flash-resident app and serial-load it, but of course I'm operating > 100% blind. For test purposes I just copied some stuff out of blinky.c > and changed the IO names to match what's in the IAR headers, as below. > > I can load and verify code OK, but the 8 LEDs remain stuck on even > when I detach the serial port. I did check in the .map file and it put > intvec @ 0 and _main() at 0x1c4, so it seems to be sane - it seems > like it should Just Work, but doesn't. > > IO1DIR = 0x00FF0000; /* P1.16..23 defined as > Outputs */ > > while (1) { /* Loop forever */ > for (n = 0x00010000; n <= 0x00800000; n <<= 1) { > /* Blink LED 0, 1, 2, 3, 4, 5, 6, 7 */ > IO1SET = n; /* Turn on LED */ > delay(); /* Delay */ > IO1CLR = 0x00FF0000; /* Turn off LEDs */ > } > }
...and how big a delay were you hoping for? You sometimes have to think about indicator persistence of luminance. Changing LED's ON to OFF and back again at a high rate will make them seem like they are always on. You may want a much bigger delay. -- ******************************************************************** Paul E. Bennett...............<email://Paul_E.Bennett@topmail.co.uk> Forth based HIDECS Consultancy Mob: +44 (0)7811-639972 Tel: +44 (0)1235-510979 Going Forth Safely ..... EBA. www.electric-boat-association.org.uk.. ********************************************************************
> You sometimes have to think about indicator persistence of luminance.
I knew I should have posted something about this, but when I say nothing is happening, I mean I scoped the P1.x pins that drive the LEDs and they are not changing state. Also I wrote a version that just turns on two LEDs and halts, and it still doesn't do anything. The code doesn't appear to be running. I loaded someone else's precompiled hex file for something and it works, so it's a compile/link problem on my end.
In article <65e6619d-1a1c-4e46-855a-
02216d5d6147@x27g2000yqb.googlegroups.com>, zwsdotcom@gmail.com says...
> I'm trying to get up and running on the MCB2130 using IAR Kickstart to > build and FlashMagic to load the code. > > Do I need to write my own startup code for this configuration? Since I > don't have a JTAG adapter that's compatible with IAR, I have to build > a flash-resident app and serial-load it, but of course I'm operating > 100% blind. For test purposes I just copied some stuff out of blinky.c > and changed the IO names to match what's in the IAR headers, as below. > > I can load and verify code OK, but the 8 LEDs remain stuck on even > when I detach the serial port. I did check in the .map file and it put > intvec @ 0 and _main() at 0x1c4, so it seems to be sane - it seems > like it should Just Work, but doesn't. > > IO1DIR = 0x00FF0000; /* P1.16..23 defined as > Outputs */ > > while (1) { /* Loop forever */ > for (n = 0x00010000; n <= 0x00800000; n <<= 1) { > /* Blink LED 0, 1, 2, 3, 4, 5, 6, 7 */ > IO1SET = n; /* Turn on LED */ > delay(); /* Delay */ > IO1CLR = 0x00FF0000; /* Turn off LEDs */ > } > }
First test I would do is change the order of LED Off and LED On to see if code ever executes.. Second test do more than 9 iterations of the blink loop, change the bit shift to an increment. Change blink delay to inline code of a long delay. Check output to ensure it has not been optimised away. Check initialisation or run time code at start of main as we don't know if you have setup the stack, so the firt call to delay(), the programme goes off into never never land. Normally I would have the reset vector jump to initialisation code which then jumps of calls main() -- Paul Carpenter | paul@pcserviceselectronics.co.uk <http://www.pcserviceselectronics.co.uk/> PC Services <http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font <http://www.gnuh8.org.uk/> GNU H8 - compiler & Renesas H8/H8S/H8 Tiny <http://www.badweb.org.uk/> For those web sites you hate
On Jun 12, 8:08=A0am, Paul Carpenter
> First test I would do is change the order of LED Off and LED On to > see if code ever executes..
Well, see other reply to Paul - I'm pretty sure no code is executing (or at least it isn't getting to main). Since it's burn and pray, I can't tell a whole lot about what's going on.
> Check initialisation or run time code at start of main as we don't > know if you have setup the stack, so the firt call to delay(),
The same thing happens with no call to delay (or any other function call). What I'm really asking here is if I need to write my own startup code - I would assume not, I assume that I have misconfigured something in the IDE.
larwe wrote:

> I'm trying to get up and running on the MCB2130 using IAR Kickstart to > build and FlashMagic to load the code. > > Do I need to write my own startup code for this configuration? Since I > don't have a JTAG adapter that's compatible with IAR, I have to build > a flash-resident app and serial-load it, but of course I'm operating > 100% blind. For test purposes I just copied some stuff out of blinky.c > and changed the IO names to match what's in the IAR headers, as below.
A Macgraigor Wiggler clone is easy to build, and Olimex advertises an even simpler parallel-port/JTAG adapter that they claim works with some flavour of IAR kickstart. If one of these worked, you could have JTAG. Of course it's time and effort wasted if they turned out not to work with your particular software. Good Luck, Mel.
On Jun 12, 10:57=A0am, Mel <mwil...@the-wire.com> wrote:

> A Macgraigor Wiggler clone is easy to build, and Olimex advertises an eve=
n I own a real one bought many years ago, but have no PCs with parallel ports any more. And for that matter no desktop PCs - I work from laptops. I've stepped through the code in the simulator and it all appears to be sane - it's definitely running out of flash area, and everything seems to be inited properly. It just doesn't work on the target. Googling has yielded me other people with the same exact problem, but no solutions :(
On Jun 12, 4:34=A0am, larwe <zwsdot...@gmail.com> wrote:
> I'm trying to get up and running on the MCB2130 using IAR Kickstart to > build and FlashMagic to load the code.
Followup: It's something to do with the IAR startup or configuration code (or the way it generates a HEX file). I switched to the free version of the Raisonance IDE with their gcc flavor and all is well. And I'm actually better off, since the free RiDE is only limited in debug space, not compile+link space. Since I'm debugging the old-fashioned way anyhow, I'm not really limited at all. Damned if I can work out what was bad about the IAR code though. I even poked through the memory dump in Flash Magic and it all looked good to me.
On Jun 12, 8:33=A0am, larwe <zwsdot...@gmail.com> wrote:
> On Jun 12, 4:34=A0am, larwe <zwsdot...@gmail.com> wrote: > > > I'm trying to get up and running on the MCB2130 using IAR Kickstart to > > build and FlashMagic to load the code. > > Followup: It's something to do with the IAR startup or configuration > code (or the way it generates a HEX file). > > I switched to the free version of the Raisonance IDE with their gcc > flavor and all is well. And I'm actually better off, since the free > RiDE is only limited in debug space, not compile+link space. Since I'm > debugging the old-fashioned way anyhow, I'm not really limited at all. > > Damned if I can work out what was bad about the IAR code though. I > even poked through the memory dump in Flash Magic and it all looked > good to me.
Hi, if you are still interested in a low cost and really good USB->JTAG debugger for non-commercial use, check out the Segger EDU version. Works with GNU and cost is about $60. Would be interested to get your feedback how you'd compare EWARM from IAR to RIDE7 from Raisonance. In the professional full-featured version the IAR tool is 4-times more expensive. Assuming the only constraint to budget is common sense, would you go for the GNU based RLink PRO from Raisonance with full debug or with the propriety compiler based EWARM and why? Just very curious. An Schwob p.s. I used both and am opinionated about the choice but would like to solicit your input
On Jun 12, 8:31=A0pm, An Schwob in the USA <schwo...@aol.com> wrote:

> > I switched to the free version of the Raisonance IDE with their gcc > > > Damned if I can work out what was bad about the IAR code though. I > > if you are still interested in a low cost and really good USB->JTAG > debugger for non-commercial use, check out the Segger EDU version. > Works with GNU and cost is about $60.
The "not for profit" restriction is not acceptable to me, though. If I go gcc, I think I'd rather go to one of Olimex's OpenOCD-compatible things for about the same price: http://www.sparkfun.com/commerce/product_i= nfo.php?products_id=3D8278 One way or another I'll get real hardware shortly; I was really just trying to make use of a spare weekend and I was in a catch-22 - I have an old Wiggler I can't use for hardware reasons, and a Keil uLink plus a couple of Rowley CrossConnects that I can't use for software reasons.
> Would be interested to get your feedback how you'd compare EWARM from > IAR to RIDE7 from Raisonance. In the professional full-featured
As yet, not enough data for a fair comparison. I use EWARM extensively with Atmel ARM7s at work(*), which is why I reached for it to use at home; I figured it would be my fastest path to working code. It is very puzzling why I couldn't get it to work. One EWARM feature that makes our life a lot easier is the ThreadX awareness. Not sure if RIDE offers that. I used RIDE with the STM32 Circle platform a while ago, but not in a "gotta get code out the door to put food on the table" sort of situation. And right now since I'm in burn-and-pray mode, I'm not really using it except as a convenient frontend that sets up the build environment and linker scripts, etc. for gcc. In fact that's exactly the reason I was looking for an off the shelf solution - I didn't want to have to write startup code and set the whole environment up from scratch. If I had downloaded a generic gcc distro, I would have had to seek out sample projects for the chip I'm using. Easier to get an IDE with support for a zillion chips built in. The downside to using RIDE et al is that they're "wrapped" gcc distros. Meaning if I want to upgrade components of them with the latest, I might not be able to. (*) Despite transferring to the marketing job. Still cleaning up old projects.

Memfault Beyond the Launch