Yahoo Groups archive
Thread
2005-12-16 by varuzhandanielyan
Maybe very silly question, but... Can I use P1.24-P1.31 pins in my design as IO, if I plan to debug the soft using JTAG, particularly ULINK. Technical data references, experience, opinions? Great thanks. Varuzhan
2005-12-16 by Tom Walsh
varuzhandanielyan wrote:
>Maybe very silly question, but...
>Can I use P1.24-P1.31 pins in my design as
>IO, if I plan to debug the soft using JTAG,
>particularly ULINK.
>Technical data references, experience, opinions?
>
>
>
I do. The LPC2106 has a secondary JTAG port, you just need to turn it
on.. You must download the first Flash image without JTAG, but after
that it works fine: flash new program, debug, etc.
This is the code sequence in the first few bytes of my crt0.S:
================ begin ====================
_start:
start:
_mainCRTStartup:
// Initialize Interrupt System
// - Set stack location for each mode
// - Leave in System Mode with Interrupts Disabled
// -----------------------------------------------
;
ldr r0, JTAG2
ldr r1, PINSELREG
str r0, [r1] // activate secondary JTAG port.
;
mov r3, #65536
startdelay:
subs r3, r3, #1
bne startdelay // give debugger time to catch us.
;
=============== snip ======================
With JTAG2 & PINSELREG as:
================= begin ===================
JTAG2:
.word 0x55400000
PINSELREG:
.word 0xe002c004
================== snip ===================
The short delay loop lets the JTAG unit "catch up" and stop the
processor early in the boot process. Otherwise, I've run into problems
where the processor will run into a brick wall (bad code) before the
JTAG can catch it out of reset.
TomW
--
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------2005-12-16 by varuzhandanielyan
Ok, the code example is fine, but what about the hardware connections of the pins? Varuzhan --- In lpc2000@yahoogroups.com, Tom Walsh <tom@o...> wrote:
> > varuzhandanielyan wrote: > > >Maybe very silly question, but... > >Can I use P1.24-P1.31 pins in my design as > >IO, if I plan to debug the soft using JTAG, > >particularly ULINK. > >Technical data references, experience, opinions? > > > > > > > I do. The LPC2106 has a secondary JTAG port, you just need to turn it > on.. You must download the first Flash image without JTAG, but after > that it works fine: flash new program, debug, etc. > > This is the code sequence in the first few bytes of my crt0.S: > > ================ begin ==================== > _start: > start: > _mainCRTStartup: > > // Initialize Interrupt System > // - Set stack location for each mode > // - Leave in System Mode with Interrupts Disabled > // ----------------------------------------------- > ; > ldr r0, JTAG2 > ldr r1, PINSELREG > str r0, [r1] // activate secondary JTAG port. > ; > mov r3, #65536 > startdelay: > subs r3, r3, #1 > bne startdelay // give debugger time to catch us. > ; > > =============== snip ====================== > > With JTAG2 & PINSELREG as: > > ================= begin =================== > JTAG2: > .word 0x55400000 > PINSELREG: > .word 0xe002c004 > ================== snip =================== > > > The short delay loop lets the JTAG unit "catch up" and stop the > processor early in the boot process. Otherwise, I've run into problems > where the processor will run into a brick wall (bad code) before the > JTAG can catch it out of reset. > > > TomW > > > -- > Tom Walsh - WN3L - Embedded Systems Consultant > http://openhardware.net, http://cyberiansoftware.com > "Windows? No thanks, I have work to do..." > ---------------------------------------------------- >
2005-12-16 by seangra
What about for the LPC213x and LPC214x series? I think they only have 1 JTAG port, right? --- In lpc2000@yahoogroups.com, Tom Walsh <tom@o...> wrote: > > varuzhandanielyan wrote: > > >Maybe very silly question, but... > >Can I use P1.24-P1.31 pins in my design as > >IO, if I plan to debug the soft using JTAG, > >particularly ULINK. > >Technical data references, experience, opinions? > > > > > > > I do. The LPC2106 has a secondary JTAG port, you just need to turn it > on.. You must download the first Flash image without JTAG, but after > that it works fine: flash new program, debug, etc. > > This is the code sequence in the first few bytes of my crt0.S: > > ================ begin ==================== > _start: > start: > _mainCRTStartup: > > // Initialize Interrupt System > // - Set stack location for each mode > // - Leave in System Mode with Interrupts Disabled > // ----------------------------------------------- > ; > ldr r0, JTAG2 > ldr r1, PINSELREG > str r0, [r1] // activate secondary JTAG port. > ; > mov r3, #65536 > startdelay: > subs r3, r3, #1 > bne startdelay // give debugger time to catch us. > ; > > =============== snip ====================== > > With JTAG2 & PINSELREG as: > > ================= begin =================== > JTAG2: > .word 0x55400000 > PINSELREG: > .word 0xe002c004 > ================== snip =================== > > > The short delay loop lets the JTAG unit "catch up" and stop the > processor early in the boot process. Otherwise, I've run into problems > where the processor will run into a brick wall (bad code) before the
> JTAG can catch it out of reset. > > > TomW > > > -- > Tom Walsh - WN3L - Embedded Systems Consultant > http://openhardware.net, http://cyberiansoftware.com > "Windows? No thanks, I have work to do..." > ---------------------------------------------------- >
2005-12-17 by varuzhandanielyan
I am asking mainly just about LPC213x and LPC214x series. Realy they have too few pins for such a powerful processor. So each pin is a very valuable resource and it is pity to lost it only for debug purposes. By the way I would be happy to see a 100-pin version of this series with more IO pins, especially with PWM not shared with interfaces. Anyway, I am still waiting for discussion about P1.24-P1.31 pins usage. Varuzhan --- In lpc2000@yahoogroups.com, "seangra" <embeddedrelated@w...> wrote:
> > > What about for the LPC213x and LPC214x series? I think they only > have 1 JTAG port, right? > > --- In lpc2000@yahoogroups.com, Tom Walsh <tom@o...> wrote: > > > > varuzhandanielyan wrote: > > > > >Maybe very silly question, but... > > >Can I use P1.24-P1.31 pins in my design as > > >IO, if I plan to debug the soft using JTAG, > > >particularly ULINK. > > >Technical data references, experience, opinions? > > > > > > > > > > > I do. The LPC2106 has a secondary JTAG port, you just need to > turn it > > on.. You must download the first Flash image without JTAG, but > after > > that it works fine: flash new program, debug, etc. > > > > This is the code sequence in the first few bytes of my crt0.S: > > > > ================ begin ==================== > > _start: > > start: > > _mainCRTStartup: > > > > // Initialize Interrupt System > > // - Set stack location for each mode > > // - Leave in System Mode with Interrupts Disabled > > // ----------------------------------------------- > > ; > > ldr r0, JTAG2 > > ldr r1, PINSELREG > > str r0, [r1] // activate secondary JTAG port. > > ; > > mov r3, #65536 > > startdelay: > > subs r3, r3, #1 > > bne startdelay // give debugger time to catch us. > > ; > > > > =============== snip ====================== > > > > With JTAG2 & PINSELREG as: > > > > ================= begin =================== > > JTAG2: > > .word 0x55400000 > > PINSELREG: > > .word 0xe002c004 > > ================== snip =================== > > > > > > The short delay loop lets the JTAG unit "catch up" and stop the > > processor early in the boot process. Otherwise, I've run into > problems > > where the processor will run into a brick wall (bad code) before > the > > JTAG can catch it out of reset. > > > > > > TomW > > > > > > -- > > Tom Walsh - WN3L - Embedded Systems Consultant > > http://openhardware.net, http://cyberiansoftware.com > > "Windows? No thanks, I have work to do..." > > ---------------------------------------------------- > > >
2005-12-17 by Tom Walsh
varuzhandanielyan wrote: >I am asking mainly just about LPC213x and LPC214x series. >Realy they have too few pins for such a powerful processor. >So each pin is a very valuable resource and it is pity to >lost it only for debug purposes. >By the way I would be happy to see a 100-pin version of this >series with more IO pins, especially with PWM not shared with interfaces. >Anyway, I am still waiting for discussion about P1.24-P1.31 >pins usage. > > > Well, you could read the Philips manual for the LPC213x family.. Or, you could get an modestly priced evaluation board to try out. Both ways, you will find that you "could" discard JTAG and use those pins for I/O. Realistically, I don't think that you would want to consider doing that as how would you develop code??? Although, you could use those pins for simple, less critical functions like: blinkings LEDs, or something like that. Why not, instead, be looking into I2C port expanders, or SPI devices, to get more I/O ? --OR-- Maybe look at other ARM processors from Samsung, Hitachi, Motorola, Cirrus Logic, SGS-Thompson, ..... ? Use the right tool for the right job.. (or chip ;)) Regards, TomW >Varuzhan > >--- In lpc2000@yahoogroups.com, "seangra" <embeddedrelated@w...> wrote: > > >>What about for the LPC213x and LPC214x series? I think they only >>have 1 JTAG port, right? >> >>--- In lpc2000@yahoogroups.com, Tom Walsh <tom@o...> wrote: >> >> >>>varuzhandanielyan wrote: >>> >>> >>> >>>>Maybe very silly question, but... >>>>Can I use P1.24-P1.31 pins in my design as >>>>IO, if I plan to debug the soft using JTAG, >>>>particularly ULINK. >>>>Technical data references, experience, opinions? >>>> >>>> >>>> >>>> >>>> >>>I do. The LPC2106 has a secondary JTAG port, you just need to >>> >>> >>turn it >> >> >>>on.. You must download the first Flash image without JTAG, but >>> >>> >>after >> >> >>>that it works fine: flash new program, debug, etc. >>> >>>This is the code sequence in the first few bytes of my crt0.S: >>> >>>================ begin ==================== >>>_start: >>>start: >>>_mainCRTStartup: >>> >>>// Initialize Interrupt System >>>// - Set stack location for each mode >>>// - Leave in System Mode with Interrupts Disabled >>>// ----------------------------------------------- >>>; >>> ldr r0, JTAG2 >>> ldr r1, PINSELREG >>> str r0, [r1] // activate secondary JTAG port. >>>; >>> mov r3, #65536 >>>startdelay: >>> subs r3, r3, #1 >>> bne startdelay // give debugger time to catch us. >>>; >>> >>>=============== snip ====================== >>> >>>With JTAG2 & PINSELREG as: >>> >>>================= begin =================== >>>JTAG2: >>> .word 0x55400000 >>>PINSELREG: >>> .word 0xe002c004 >>>================== snip =================== >>> >>> >>>The short delay loop lets the JTAG unit "catch up" and stop the >>>processor early in the boot process. Otherwise, I've run into >>> >>> >>problems >> >> >>>where the processor will run into a brick wall (bad code) before >>> >>> >>the >> >> >>>JTAG can catch it out of reset. >>> >>> >>>TomW >>> >>> >>>-- >>>Tom Walsh - WN3L - Embedded Systems Consultant >>>http://openhardware.net, http://cyberiansoftware.com >>>"Windows? No thanks, I have work to do..." >>>---------------------------------------------------- >>> >>> >>> > > > > > > > > >Yahoo! Groups Links > > > > > > > > > -- Tom Walsh - WN3L - Embedded Systems Consultant http://openhardware.net, http://cyberiansoftware.com "Windows? No thanks, I have work to do..." ----------------------------------------------------
2005-12-18 by Robert Adsett
At 10:52 AM 12/17/05 -0500, Tom Walsh wrote: >Well, you could read the Philips manual for the LPC213x family.. Or, >you could get an modestly priced evaluation board to try out. Both >ways, you will find that you "could" discard JTAG and use those pins for >I/O. Realistically, I don't think that you would want to consider doing >that as how would you develop code??? Wimp :) It is, of course, quite feasible to develop without using a JTAG. Indeed on some micros with little or nor ICE or on chip debug support it's necessary. There's a lot to be said for observing the behaviour of the device in question and determining from that what must be happening internally. Add a few pins to toggle to indicate code paths and timings and a serial I/O port for data dumps and you cover a lot of ground, some of which cannot be covered very effectively with JTAG. Of course there are situations where JTAG or a real ICE is very nearly essential. In fact I'm not yet convinced that JTAG is a complete replacement for a proper ICE since I have yet to run into a situation on a JTAG equipped micro that demanded the full capabilities of an ICE. Serial downloads do work quite well and since JTAG takes up so many general purpose I/O pins I can see why someone would want to dispense with it, especially on the lower pin count devices. A lot of products really don't have room for a 144 pin package especially just to add a debugging interface. Robert " 'Freedom' has no meaning of itself. There are always restrictions, be they legal, genetic, or physical. If you don't believe me, try to chew a radio signal. " -- Kelvin Throop, III http://www.aeolusdevelopment.com/
2005-12-18 by rtstofer
I had to kiss off JTAG for my LPC2106 project for two reasons: I didn't have enough pins even with I2C bus I/O ports and, frankly, OCDRemote doesn't work often enough to put up with the aggravation. Everything came out ok. Actually, it may have been faster to use puts () and such because I didn't have to learn how to use the debugger. I have done without JTAG for 30 years, I guess I can struggle through. Richard
2005-12-18 by Tom Walsh
Robert Adsett wrote: >At 10:52 AM 12/17/05 -0500, Tom Walsh wrote: > > >>Well, you could read the Philips manual for the LPC213x family.. Or, >>you could get an modestly priced evaluation board to try out. Both >>ways, you will find that you "could" discard JTAG and use those pins for >>I/O. Realistically, I don't think that you would want to consider doing >>that as how would you develop code??? >> >> > >Wimp :) > >It is, of course, quite feasible to develop without using a JTAG. Indeed >on some micros with little or nor ICE or on chip debug support it's necessary. > >There's a lot to be said for observing the behaviour of the device in >question and determining from that what must be happening internally. Add >a few pins to toggle to indicate code paths and timings and a serial I/O >port for data dumps and you cover a lot of ground, some of which cannot be >covered very effectively with JTAG. > > > Been there and done that, no thank you! ;-) I've been supporting a product for the past 12 years which was 8051 based and I did all my debug from an EPROM emulater, single LED, and secondary serial port. Eventually I figure out how to put a 4bit LCD on for the really tough problems. I've had experience with debugging 80188 from a pod (ICE), that was better, but the freakin' POD would be difficult to get working sometimes: bad connections, bad Windows driver, sick Windows install, [...]. This project, I chose a processor with built in debug capabilities (JTAG) and spent some real money and get an Abatron BDI2000 pod. Then spent time learning about Insight. GNU gdb I'm familiar with as I've run Linux for many years. I won't part with my JTAG! I just love how it works, it so reliable and stable. I've chained the JTAG lines of the two processors together and can debug them both with a single pod and two instances of Insight. No thank you, I'll keep my JTAG! It's too painfull to do it the "other way"! :-) >Of course there are situations where JTAG or a real ICE is very nearly >essential. In fact I'm not yet convinced that JTAG is a complete >replacement for a proper ICE since I have yet to run into a situation on a >JTAG equipped micro that demanded the full capabilities of an ICE. > >Serial downloads do work quite well and since JTAG takes up so many general >purpose I/O pins I can see why someone would want to dispense with it, >especially on the lower pin count devices. A lot of products really don't >have room for a 144 pin package especially just to add a debugging interface. > > > When I needed more I/O on the LPC2138 / LPC2106 board, I looked to the SPI bus. There are three MAX3100 UARTs and a NLSF595 LED driver on SPI0 of the LPC2106 processor. SPI works really well. The only thing I do wish for is an offering from Philips for a 48 / 64 pin LPC2000 package with something like 32K of Flash and 256K of SRAM. I've some ideas of what I could do with that: Add an SD card to the SPI, then load programs into the SRAM to run them from there... I do like the self-contained aspect of the LPC2000 parts, that is their best feature. Regards, TomW -- Tom Walsh - WN3L - Embedded Systems Consultant http://openhardware.net, http://cyberiansoftware.com "Windows? No thanks, I have work to do..." ----------------------------------------------------
2005-12-18 by Tom Walsh
rtstofer wrote: >I had to kiss off JTAG for my LPC2106 project for two reasons: I >didn't have enough pins even with I2C bus I/O ports and, frankly, >OCDRemote doesn't work often enough to put up with the aggravation. > > > It's the wigglers. From my experience with them, they can be really tempermental. I found that if I plugged the wiggler directly into the printer port, then kept the wire length down to 10 inches, then it wasn't too bad. You have to spend some serious time with an oscilloscope fine tuning the electronics of the interface, caps + resistors + inductors on the signal lines. But, they still can be a PITA. The electronics of them is so simple that there isn't any signal conditioning of the JTAG signals. It is so easy to pump an extra bit due to noise, or have a TDI/TDO signal skewed in phase relation with the TCLK. I've been there. I don't have deep pockets being a self employed consultant, however, the $2700 expense of a BDI2000 has been well worth the investment. If you are serious about your software / hardware development, I highly recommend that you get yourself one. This is truely a case of "you get what you pay for" when selecting a JTAG solution! IMHO, wigglers are toys that get your feet wet, they are good for doing simple tasks like programming Flash or checking out new hardware. They are an inexpensive solution for a Test Department that needs to find a short / open / bad chip on a PCB, or download a small boot loader. However, I don't need a wiggler to fail me when I'm deep into tracing into a problem with software! Today, the rate at which I'm now able to do code development is truly amazing! I'm about 2/3 done with the initial software release, currently, the LPC2106 binary image is 45K and the LPC2138 is 154K. This is all in the past 5 weeks! Admittedly, a significant amount of the code for the LPC2138 has been from the old product and the RDCF2 filesystem... The LPC2000 series is truely liberating to work with after so many years of 8051 coding! It's tough to implement high-level ideas into a processor that struggles to overcome the 64K limitation, which keeping within the power budget. The LPC2000 parts offer huge amounts of codespace at a reduced power consumption. Hard to argue against that! My development setup is: GNU gcc-3.4.3, bintools-2.15, newlib-1.13, Insight-6.1, and an Abatron BDI2000. All but the BDI2000 cost me nothing but time to setup. GNU gcc emits some really tight code when -O2 is turned on, but is nearly impossible to debug. The BDI2000 doesn't care whether I debug from Flash or RAM, it just plain works and is entirely transparent to Insight. I program the LPC2000 devices via the BDI2000 using a telnet session I keep open for that purpose. When I need to see / set raw RAM data / LPC2000 registers, I find it most convenient to do this from within the telnet session and use the BDI2000 for this. JTAG is now the most reliable part of my development cycle. There seems to be a lot of interest on this list at developing an open source wiggler gdb tcp server. Something to replace the OCDaemon. While I find that an intriguing idea with a lot of merit, the weakest point is still the wiggler electronics and that of the parallel port electronics. The parallel port of a computer is a relatively low-speed device, it is not required of it to run megabits of data down to a printer. Therefore, IMO, the chipsets used for a parallel port are garbage-variety electronics. What I do think that could be done is an open-source JTAG pod. Start out with something like a Revely RMS101 (http://www.revely.com/RMS101/AboutRMS101.htm) board, or other low cost ARM board which has an ethernet. Develop the electronics necessary to provide good signal conditioning to the Device Under Test's JTAG port. Then using that board, build up an open-source jtag solution. While this would cost more than $10 for the electronics, I feel that it would be far superior to a wiggler, but still at a fraction of the cost of a commercial JTAG unit? Software of this caliber would then not be limited to just one board electronics, others may decide (maybe SparkFun?) to further streamline the electronics and offer it at an even lower cost? Regards, TomW -- Tom Walsh - WN3L - Embedded Systems Consultant http://openhardware.net, http://cyberiansoftware.com "Windows? No thanks, I have work to do..." ----------------------------------------------------
2005-12-18 by Dominic Rath
On Sunday 18 December 2005 14:00, Tom Walsh wrote: > There seems to be a lot of interest on this list at developing an open > source wiggler gdb tcp server. Something to replace the OCDaemon. > While I find that an intriguing idea with a lot of merit, the weakest > point is still the wiggler electronics and that of the parallel port > electronics. The parallel port of a computer is a relatively low-speed > device, it is not required of it to run megabits of data down to a > printer. Therefore, IMO, the chipsets used for a parallel port are > garbage-variety electronics. My project has been designed from ground up to be able to support different JTAG interfaces. Currently, it supports Wigglers, the FTDI FT2232C and a new configuration for the Amontec Chameleon Dongle (not yet released, but works really fine - ARM7TDMI RAM download at 60-70kByte/s). I've never used a real wiggler or a homemade one, so I don't know about the problems with these, but the Amontec Chameleon works just fine. It has a true IEEE1284 transceiver on the PC side (guess that guarantees good signal integrity over a long cable length) and a Xilinx CoolRunner CPLD (3.3/5V tolerant IO), and I've never had any problems with signal integrity at up to 16 MHz JTAG clock (that's for the new config, Wiggler wont go beyond 500kHz). The parallelport is just not designed to do bitbanging - you can transfer 500-1000 kByte/s using EPP accesses, at a latency of 1-2us. > What I do think that could be done is an open-source JTAG pod. Start > out with something like a Revely RMS101 > (http://www.revely.com/RMS101/AboutRMS101.htm) board, or other low cost > ARM board which has an ethernet. Develop the electronics necessary to > provide good signal conditioning to the Device Under Test's JTAG port. > Then using that board, build up an open-source jtag solution. While > this would cost more than $10 for the electronics, I feel that it would > be far superior to a wiggler, but still at a fraction of the cost of a > commercial JTAG unit? Software of this caliber would then not be > limited to just one board electronics, others may decide (maybe > SparkFun?) to further streamline the electronics and offer it at an even > lower cost? The software part is mostly independent from the underlying JTAG interface - all the tricky logic can be implemented equally well for a wiggler and a much smarter (and more expensive) device. This would give users the freedom to choose between hobbyist quality at a few $, or some more money for a thoroughly designed interface offering high TCK and a failure-proof electrical interface - both offering the same functionality. Personally, I'd favor a FPGA based solution, using USB 2.0. Such a setup would allow very high speed at low cost while still offering more flexibility than a uC based solution with an Ethernet interface. Regards, Dominic Rath
2005-12-18 by Craig Schlenter
On 18 Dec 2005, at 2:12 PM, Tom Walsh wrote: > Been there and done that, no thank you! ;-) I've been supporting a > product for the past 12 years which was 8051 based and I did all my > debug from an EPROM emulater, single LED, and secondary serial port. > Eventually I figure out how to put a 4bit LCD on for the really tough > problems. I find that some engineers with "cool debug environments" tend to spend too much time single stepping code to "make it work" rather than writing decent code up-front. When someone knows up-front that their debug facilities will be non-existent it makes them think a bit harder about the design and be more careful when they code. It also encourages the creation of built-in debug and/or logging facilities in the software which can be rather valuable in the field. While I value the productivity benefits that come from using a JTAG to debug problems, I try to encourage my colleagues not to use it unless they _really_ have to. But debuggers are a bit of a religious issue ... it's vi versus emacs all over again :) --Craig
2005-12-18 by Tom Walsh
Dominic Rath wrote: >My project has been designed from ground up to be able to support different >JTAG interfaces. Currently, it supports Wigglers, the FTDI FT2232C and a new >configuration for the Amontec Chameleon Dongle (not yet released, but works >really fine - ARM7TDMI RAM download at 60-70kByte/s). I've never used a real >wiggler or a homemade one, so I don't know about the problems with these, but >the Amontec Chameleon works just fine. It has a true IEEE1284 transceiver on >the PC side (guess that guarantees good signal integrity over a long cable >length) and a Xilinx CoolRunner CPLD (3.3/5V tolerant IO), and I've never had >any problems with signal integrity at up to 16 MHz JTAG clock (that's for the >new config, Wiggler wont go beyond 500kHz). > > > Thank you for that information, that may be useful to pass along to my customer as they may wish to do something with JTAG. >The software part is mostly independent from the underlying JTAG interface - >all the tricky logic can be implemented equally well for a wiggler and a much >smarter (and more expensive) device. This would give users the freedom to >choose between hobbyist quality at a few $, or some more money for a >thoroughly designed interface offering high TCK and a failure-proof >electrical interface - both offering the same functionality. > >Personally, I'd favor a FPGA based solution, using USB 2.0. Such a setup would >allow very high speed at low cost while still offering more flexibility than >a uC based solution with an Ethernet interface. > > > Well, the only concern would be portability. From what I find with USB is that it can be very operating system centric. I would, and have, favored ethernet because it is platform agnostic. I tire of having to look at USB compatibility lists when considering to purchase that latest USB goodie. So many of them are built with very little attention to running on anything other than Windows. You can hide a lot of non-standard behavior, or make up for a complete disregard for standards, in a driver. e.g. "when all else fails, make a driver for it". Regards, TomW >Regards, > >Dominic Rath > > > > >Yahoo! Groups Links > > > > > > > > -- Tom Walsh - WN3L - Embedded Systems Consultant http://openhardware.net, http://cyberiansoftware.com "Windows? No thanks, I have work to do..." ----------------------------------------------------
2005-12-18 by Rob Jansen
Tom Walsh wrote:
> It's the wigglers. From my experience with them, they can be really
> tempermental. I found that if I plugged the wiggler directly into the
> printer port, then kept the wire length down to 10 inches, then it
> wasn't too bad. You have to spend some serious time with an
> oscilloscope fine tuning the electronics of the interface, caps +
> resistors + inductors on the signal lines. But, they still can be a
> PITA. The electronics of them is so simple that there isn't any signal
> conditioning of the JTAG signals.
Due to the fact that most controller boards have the JTAG lines to the
outside world without any ESD/EMC protection you may even damage your
board. I know for sure I damaged some AVR and PIC boards that I had
connected to the PC in this way ...
> IMHO, wigglers are toys that get your feet wet,
Home built wigglers have a fairly good price/quality ratio: Low price and
low quality. For the 'professional' wigglers the ratio gets worse ...
> There seems to be a lot of interest on this list at developing an open
> source wiggler gdb tcp server. Something to replace the OCDaemon.
> While I find that an intriguing idea with a lot of merit, the weakest
> point is still the wiggler electronics and that of the parallel port
> electronics.
No wiggler type of stuff please.
> What I do think that could be done is an open-source JTAG pod. Start
> out with something like a Revely RMS101
That's the way to go. I started my lpc21xx development with
http://www.embeddedartists.com/products/boards/lpc2138_100eth.php, a 100
Mbit ethernet board which is now being used to develop a JTAG pod.
Embedded Artists are regularly asking me on my progress - they really love
to create a board with JTAG signalling connection with JTAG software on it
...
> Then using that board, build up an open-source jtag solution. While
> this would cost more than $10 for the electronics, I feel that it would
> be far superior to a wiggler, but still at a fraction of the cost of a
> commercial JTAG unit? Software of this caliber would then not be
> limited to just one board electronics, others may decide (maybe
> SparkFun?) to further streamline the electronics and offer it at an even
> lower cost?
Let them all have the fun; Embedded Artists, SparkFun, Olimex - let them
create an (ethernet based) jtag pod that all use the same code-base.
Dominic favors a USB2.0 / FPGA solution. That's just using a different
JTAG interface style and a different front-end to the debugger. These are
not the most difficult parts to do - the nice stuff is in controlling the
Embedded ICE and the attached ARM core.
That't why all these commercial debuggers are so expensive. They need to
support all the different ARM cores and debuggers.
If I have to start a list of requirements for an open source JTAG debugger
this would start with:
* compilable using different GCC installations, not depending on specific OS
* must run on PC targets and embedded (ARM) processors
* support different JTAG back-ends:
- home built wiggler style interfaces (PC target)
- USB based FTDI (FT2232) style interface (PC target)
- USB based microcontroller interface (e.g. lpc2148)
- Network based microcontroller interface (EmbeddedArtists, SparkFun, ...)
* support different debugger front-ends:
- GDB stub
- terminal type command level debugger
- ARM RDI (Remote Debugger Interface), connects to gdb or commercial.
* Anyone providing hardware for the open source JTAG pod must provide a
way to perform software update (in case of use of microcontroller)
* license must allow commercial hardware providers to include this software
(in compiled form) with the hardware, provided that all source code is
delivered with it.
* license should allow commercial vendors to add specific fron/back-ends
to allow integration with commercial debuggers or their own
JTAG hardware
- must include binary or source for the front/back-end to allow customer
to rebuild complete program.
Last three bullets is just my mind running away with me ...
I think that by making this open for commercial vendors with their own
hardware or debuggers there is possibly a very large installed base.
Regards,
Rob2005-12-18 by Rob Jansen
Craig Schlenter wrote: > I find that some engineers with "cool debug environments" tend to spend > too much time single stepping code to "make it work" rather than writing > decent code up-front. That "cool debug environment" just makes sure I can spend my time on finding and fixing bugs instead of figuring out how to use the debug environment... I have used printf/LED toggle kind of debugging environments, gdb (command line), insight (graphical) and ADS/RealView debuggers for ARM. Currently I use the RealView debugger, I will not tell you that I make more bugs than before (or less) but for sure I am now spending less time to track then down. > But debuggers are a bit of a religious issue ... it's vi versus emacs > all over again :) Nothing religious about debuggers with me ... still use gdb at home. But I hate to program in LISP :o) Rob
2005-12-18 by Robert Adsett
At 07:12 AM 12/18/05 -0500, Tom Walsh wrote: >I've had experience with debugging 80188 from a pod (ICE), that was >better, but the freakin' POD would be difficult to get working >sometimes: bad connections, bad Windows driver, sick Windows install, [...]. > >This project, I chose a processor with built in debug capabilities >(JTAG) and spent some real money and get an Abatron BDI2000 pod. Then >spent time learning about Insight. GNU gdb I'm familiar with as I've >run Linux for many years. > >I won't part with my JTAG! I just love how it works, it so reliable and >stable. I've chained the JTAG lines of the two processors together and >can debug them both with a single pod and two instances of Insight. No >thank you, I'll keep my JTAG! It's too painfull to do it the "other >way"! :-) I don't think I disagree with you here. JTAG is certainly useful and a lot less cumbersome that an ICE pod. Especially if the pod consists of a multi cm high tower that has to be soldered to a 144 pin QFP outline. Been there done that. It's just you seemed to imply you couldn't develop without JTAG. Not wanting to or being more efficient with JTAG is another question entirely. There are times I find a simple print much faster and just as illuminating. That may be as much a matter of familiarity as any real productivity difference. Certainly walking through the inner workings of a routine is much easier and faster with JTAG. > >Of course there are situations where JTAG or a real ICE is very nearly > >essential. In fact I'm not yet convinced that JTAG is a complete > >replacement for a proper ICE since I have yet to run into a situation on a > >JTAG equipped micro that demanded the full capabilities of an ICE. And this is where something else is needed. I haven't seen any way to deal with timing issues with JTAG, for that the most effective way seems to be pin toggling. Then there are those problems that you cannot stop the microprocessor since to do so will necessarily result in invalid results in the best case and blown hardware or worse in other cases. There are a number of problems that the only effective way I've found to deal with is to provide a data log that is later downloaded to a PC for analysis at a safe or convenient point. > >Serial downloads do work quite well and since JTAG takes up so many general > >purpose I/O pins I can see why someone would want to dispense with it, > >especially on the lower pin count devices. A lot of products really don't > >have room for a 144 pin package especially just to add a debugging > interface. > > > > > > >When I needed more I/O on the LPC2138 / LPC2106 board, I looked to the >SPI bus. There are three MAX3100 UARTs and a NLSF595 LED driver on >SPI0 of the LPC2106 processor. SPI works really well. A good choice, but there are those applications that can't deal with the time overhead. There are others where Those In Charge (TM) are not willing to tolerate the extra piece cost of the expansion chip even if it might save them money overall by reducing the development effort and time. >I do like the self-contained aspect of the LPC2000 parts, that is their >best feature. Absolutely one of their best features. I'm not arguing against the use of JTAG, only that in some circumstances it either cannot handle the problem or that other circumstances may force you to work without it. I am a little worried that the presence of JTAG has meant that there is no real ICE for the ARMs so that the most powerful tool in the development arsenal is going to be missing when a really intractable problem appears. I expect ETM would cover most of the remaining territory but a lot of the new parts don't have that support and of course it takes away even more pins. Robert " 'Freedom' has no meaning of itself. There are always restrictions, be they legal, genetic, or physical. If you don't believe me, try to chew a radio signal. " -- Kelvin Throop, III http://www.aeolusdevelopment.com/
2005-12-18 by Robert Adsett
At 08:00 AM 12/18/05 -0500, Tom Walsh wrote: >What I do think that could be done is an open-source JTAG pod. Start >out with something like a Revely RMS101 >(http://www.revely.com/RMS101/AboutRMS101.htm) board, or other low cost >ARM board which has an ethernet. Develop the electronics necessary to >provide good signal conditioning to the Device Under Test's JTAG port. >Then using that board, build up an open-source jtag solution. While >this would cost more than $10 for the electronics, I feel that it would >be far superior to a wiggler, but still at a fraction of the cost of a >commercial JTAG unit? Software of this caliber would then not be >limited to just one board electronics, others may decide (maybe >SparkFun?) to further streamline the electronics and offer it at an even >lower cost? An ethernet based JTAG dongle. I LIKE that idea. That is on my list of desired tools. It does seem that it should be possible to produce one for not much more than a USB based version. Robert " 'Freedom' has no meaning of itself. There are always restrictions, be they legal, genetic, or physical. If you don't believe me, try to chew a radio signal. " -- Kelvin Throop, III http://www.aeolusdevelopment.com/
2005-12-18 by seangra
On the note of needing the extra I/O pins, if you really need them why not just throw on an 74LVC343 or something similar? You can effectively get 7 additional digital I/O pins, with enough current to source LEDs if need be. I've added a few to my design for anything that is not performance critical, and it works great. This way I leave the JTAG pins for their useful purpose :) Alternatively if the $0.25 for the latch is too much then you can add a latch as a replacement for the jtag pins for debugging purposes only, and for production you can remove the latch and change the control to the JTAG pins instead. For simple "fool-proof" things like LEDs or peripheral chip selects this can work quite well.
2005-12-19 by Rob Jansen
Robert Adsett wrote: > And this is where something else is needed. I haven't seen any way to > deal > >with timing issues with JTAG, for that the most effective way seems to be >pin toggling. Then there are those problems that you cannot stop the >microprocessor since to do so will necessarily result in invalid results in >the best case and blown hardware or worse in other cases. There are a >number of problems that the only effective way I've found to deal with is >to provide a data log that is later downloaded to a PC for analysis at a >safe or convenient point. > > Data log ... especially usefull todiscover these nice interrupt related bugs ... But for timingrelated stuff there are the ETM/ETB that can be part of the ARM core. The lpc3000 contains an ETM, worked great for my timing issues on a 926EJ-S. >I'm not arguing against the use of JTAG, only that in some circumstances it >either cannot handle the problem or that other circumstances may force you >to work without it. > >I am a little worried that the presence of JTAG has meant that there is no >real ICE for the ARMs so that the most powerful tool in the development >arsenal is going to be missing when a really intractable problem >appears. I expect ETM would cover most of the remaining territory but a >lot of the new parts don't have that support and of course it takes away >even more pins. > > For embedded processors real In Circuit Emulators are almost not feasible, you needto rely on stuff like ETM of ETB. Problem is support by JTAG debugger pods. Either not available or expensive ... I have also not seen ARM7 with ETM yet (have not looked for it though) and I think the ARM9 is the first with ETM or ETB. Rob
2005-12-21 by Robert Adsett
At 07:50 AM 12/19/05 +0100, Rob Jansen wrote: >Robert Adsett wrote: > > And this is where something else is needed. I haven't seen any way to > > deal > > > >with timing issues with JTAG, for that the most effective way seems to be > >pin toggling. Then there are those problems that you cannot stop the > >microprocessor since to do so will necessarily result in invalid results in > >the best case and blown hardware or worse in other cases. There are a > >number of problems that the only effective way I've found to deal with is > >to provide a data log that is later downloaded to a PC for analysis at a > >safe or convenient point. > > > > >Data log ... especially usefull todiscover these nice interrupt related >bugs ... >But for timingrelated stuff there are the ETM/ETB that can be part of >the ARM core. >The lpc3000 contains an ETM, worked great for my timing issues on a >926EJ-S. I've always used a scope for timing. I can't imagine even a full ICE being particularly helpful there. Much less ETM. Maybe we are talking about different things? > >I am a little worried that the presence of JTAG has meant that there is no > >real ICE for the ARMs so that the most powerful tool in the development > >arsenal is going to be missing when a really intractable problem > >appears. I expect ETM would cover most of the remaining territory but a > >lot of the new parts don't have that support and of course it takes away > >even more pins. >For embedded processors real In Circuit Emulators are almost not >feasible, you needto rely on stuff I've worked on several embedded processors with ICE support. Indeed my experience is that they are far more common in the embedded than in the non-embedded world. Most non-embedded developers get by with a hosted debugger as their most powerful tool. >like ETM of ETB. >Problem is support by JTAG debugger pods. Either not available or >expensive ... >I have also not seen ARM7 with ETM yet (have not looked for it though) The LPC2104/5/6 have ETM. Philips dropped support for it on most (all?) later variants. Robert " 'Freedom' has no meaning of itself. There are always restrictions, be they legal, genetic, or physical. If you don't believe me, try to chew a radio signal. " -- Kelvin Throop, III http://www.aeolusdevelopment.com/
2005-12-21 by philips_apps
Hi Robert, what makes you think that Philips dropped the ETM? Of all currently available LPC2000 devices only the smallest LPC2101/02/03 do not have ETM. Not too many customers are using it though because is does cost 10 additional pins on top of the JTAG pins. Robert > The LPC2104/5/6 have ETM. Philips dropped support for it on most (all?) > later variants. > > Robert > > " 'Freedom' has no meaning of itself. There are always restrictions, be > they legal, genetic, or physical. If you don't believe me, try to chew a
> radio signal. " -- Kelvin Throop, III > http://www.aeolusdevelopment.com/ >
2005-12-22 by Robert Adsett
At 05:22 AM 12/21/05 +0000, philips_apps wrote: >what makes you think that Philips dropped the ETM? Of all currently >available LPC2000 devices only the smallest LPC2101/02/03 do not have >ETM. Not too many customers are using it though because is does cost >10 additional pins on top of the JTAG pins. Oops, sorry Robert I could have sworn I'd seen datasheets w/o ETM on them. My apologies. Robert " 'Freedom' has no meaning of itself. There are always restrictions, be they legal, genetic, or physical. If you don't believe me, try to chew a radio signal. " -- Kelvin Throop, III http://www.aeolusdevelopment.com/