Getting started with IAR+MCB2130?

...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.

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.

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()

On Jun 12, 8:08=A0am, Paul Carpenter

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.

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.

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.

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 :(

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

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:

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.

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.

Apologies. I should have looked at OP details before responding where I would have realised you would have already made those checks. I guess that there may be some subtle settings in the compiler, linker, loader series that need to be right for you to get working code across. I'll leave it to the others more knowledgable about the products to assist you further.

I was skipping this thread since I didn't recognize what an "MCB2130" processor was -- should have keyed on the 2130 piece!

One thing to look at is whether the loader you're using correctly sets the pseudo-vector at 0x00000014 to be the two's complement of the checksum of the actual interrupt vectors.

In the LPCs, the bootloader always runs and always checks that the sum of the whole vector block is zero before it jumps to user code. It may be that your toolchain is relying on the burner to handle setting the correct value at 0x00000014 on the fly but your serial burner is expecting it to already be set in the hex file.