2106 | ADC | ARM7 | Atmel | Bootloader | CAN | CrossStudio | CrossWorks | DDS | ECos | Ethernet | ETM | FIFO | FLASH | FPGA | GCC | GDB | GNU | GNUARM | GPIO | I2C | IAP | IAR | JTAG | Kickstart | LCD | Linux | LPC | LPC-E2294 | LPC2000 | LPC2100 | LPC2104 | Lpc2106 | Lpc210x | LPC2114 | LPC2119 | LPC2124 | LPC2129 | Lpc2138 | LPC213x | LPC21xx | LPC2210 | LPC2212 | LPC2214 | LPC2292 | LPC2294 | LPC2xxx | LPC3128 | MCB2100 | Olimex | Philips | PWM | Rowley | RTC | RTOS | SPI | SSP | UART | UART0 | UART1 | ULINK | USB | Watchdog | Wiggler

I have had a multitude of connection problems with newer IAR Kickstart boards. The connection is lost requiring a power cycle. I have also noticed that I have had ZERO problems with the older IAR Kickstart board. The older boards were four layer, the newer two. The older board uses a different RS232 driver than the new. I have replaced the driver (ST) on the new board with a Maxim device and ALL my connection problems have gone away. FYI (Your mileage may vary) Richard

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In , "Richard" <richas@y...> wrote: > > I have had a multitude of connection problems with newer IAR Kickstart > boards. The connection is lost requiring a power cycle. I have also > noticed that I have had ZERO problems with the older IAR Kickstart > board. The older boards were four layer, the newer two. The older > board uses a different RS232 driver than the new. I have replaced the > driver (ST) on the new board with a Maxim device and ALL my connection > problems have gone away. Hi, can you be more specific - what connection problems you have had with Kickstart boards? What baudrate? etc? Tsvetan --- PCB prototypes for $26 at http://run.to/pcb (http://www.olimex.com/pcb) PCB any volume assembly (http://www.olimex.com/pcb/protoa.html) Development boards for ARM, AVR, PIC, and MSP430 (http://www.olimex.com/dev)

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

The connection would time out on all operations besides read part ID at all baud rates. Swapping out the driver fixed all problems. This scenario repeated itself on two different boards. Richard -- In , "tsvetanusunov" <tusunov@m...> wrote: > > --- In , "Richard" <richas@y...> wrote: > > > > I have had a multitude of connection problems with newer IAR > Kickstart > > boards. The connection is lost requiring a power cycle. I have > also > > noticed that I have had ZERO problems with the older IAR Kickstart > > board. The older boards were four layer, the newer two. The older > > board uses a different RS232 driver than the new. I have replaced > the > > driver (ST) on the new board with a Maxim device and ALL my > connection > > problems have gone away. > > Hi, > > can you be more specific - what connection problems you have had with > Kickstart boards? > What baudrate? etc? > > Tsvetan > --- > PCB prototypes for $26 at http://run.to/pcb > (http://www.olimex.com/pcb) > PCB any volume assembly (http://www.olimex.com/pcb/protoa.html) > Development boards for ARM, AVR, PIC, and MSP430 > (http://www.olimex.com/dev)

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Hi, Tools used: GNU gdb 5.3 (insight) LPC2106 board running ARM remote GDB stubs (over UART) Short description: When I try to set a breakpoint at a thumb C-function starting at address 0x40000278, GDB debugger (insight) sends a (GDB protocol) command to write 0xbebe (Instruction which would generate a Undef exception) at 0x40000282 & not at 0x40000278. Which is actually the function’s exit & not the entry. Detailed description: I issue the following commands on the GDB’s console $ target /dev/com1 $ load $ b APP_vMain $ c And GDB log file reads as follows <Just the important lines are included here>: c b APP_vMain w $m40000278,2#60 r +$00b5#f7 w +$m4000027a,2#89 r +$0248#ce w +$m4000027c,2#8b r +$00f0#f6 w +$m4000027e,2#8d r +$02fb#2a w +$m40000280,2#59 r +$01bc#26 w + c c w $Z0,40000282,2#a4 r +$#00 w +$m40000282,2#5b r +$0047#cb w +$M40000282,2:bebe#03 r +$OK#9a w +$Hc0#db Clipping from the image disassembly around APP_vMain() function: 40000274: 4000fc00 andmi pc, r0, r0, lsl #24 40000278 <APP_vMain>: 40000278: b500 push {lr} 4000027a: 4802 ldr r0, [pc, #8] (40000284 <.text+0x184>) 4000027c: fb02f000 bl 40000884 <CONSOL_SendString> 40000280: bc01 pop {r0} 40000282: 4700 bx r0 40000284: 0ff0 lsr r0, r6, #31 40000286: 4000 and r0, r0 GDB reads the 1st 5 instructions staring 0x40000274 (APP_vMain) & finally sets the Break (Undef) instruction at the 6th instruction. Why? Please help me understand the issue behind this. Thanks, -Mike. __________________________________________________ ">http://mail.yahoo.com

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )