From: larwe on 12 Jun 2010 04:34 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 */ } }
From: Paul E. Bennett on 12 Jun 2010 05:04 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(a)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.. ********************************************************************
From: larwe on 12 Jun 2010 07:37 > 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.
From: Paul Carpenter on 12 Jun 2010 08:08 In article <65e6619d-1a1c-4e46-855a- 02216d5d6147(a)x27g2000yqb.googlegroups.com>, zwsdotcom(a)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(a)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
From: larwe on 12 Jun 2010 09:18 On Jun 12, 8:08 am, 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.
|
Next
|
Last
Pages: 1 2 3 Prev: PCB prototyping / copper metallization Next: linux toosl for PIC32MX development |