On Sat, 12 Jun 2010 08:06:13 -0700 (PDT), larwe <zwsdotcom@gmail.com>
wrote:
>On Jun 12, 10:57�am, Mel <mwil...@the-wire.com> wrote:
>
>> A Macgraigor Wiggler clone is easy to build, and Olimex advertises an even
>
>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 :(
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.
--
Rich Webb Norfolk, VA
Reply by Paul E. Bennett●June 13, 20102010-06-13
larwe wrote:
>
>> 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.
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.
--
********************************************************************
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..
********************************************************************
Reply by larwe●June 13, 20102010-06-13
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.
Reply by An Schwob in the USA●June 12, 20102010-06-12
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
Reply by larwe●June 12, 20102010-06-12
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.
Reply by larwe●June 12, 20102010-06-12
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 :(
Reply by Mel●June 12, 20102010-06-12
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.
Reply by larwe●June 12, 20102010-06-12
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.
Reply by Paul Carpenter●June 12, 20102010-06-12
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
Reply by larwe●June 12, 20102010-06-12
> 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.