[POLL] Necessity of Debug Port for Code Development - Page 1
Forum section: electronics / general

author: testmode
author_rank: Regular Contributor
timestamp: October 08, 2016, 02:12:04 am
content: Would like to get the opinion and experience around here on this. How important do you think is debug port access (i.e. SWD, JTAG, etc) for code development nowadays? Say, on a project with an embedded Cortex-M3 processor and about medium complexity (~128kB max code size), running on RTOS for multitasking. Has anyone here fully worked on similar projects without it? Not considering financial or business factors, will you accept/work on a commercial microcontroller project without debugging support? I know it will be very subjective but in your opinion/experience, how much extra effort will you need to work on a project without debug support as compared to one with it?

author: Rerouter
author_rank: Super Contributor
timestamp: October 08, 2016, 02:28:56 am
content: The ability to spot errors in a medium size code base comes down to your style, your primary methods for approaching a problem, and if anyone ever has to reveiw it, your documentation in code comments,So far I have never had to use debugging, but I can understand its value in the rare cases where something is acting weird and nothing makes sense. Or in applications where you need to use the hardware very close to its limits.If I left the safe areas of static memory allocation then I could see its value being much higher, but so far I am trying to live a Happy life with deterministic code.

author: legacy
author_rank: Super Contributor
timestamp: October 08, 2016, 10:02:33 am
content: I vote "it's nice to have but I would be fine even without it"

author: legacy
author_rank: Super Contributor
timestamp: October 08, 2016, 10:06:38 am
content: oh, in certain of my job's tasks, I should vote"Must have - can't *conclude my taskstherefore I can't make my employer happy*without it!"

author: JPortici
author_rank: Super Contributor
timestamp: October 08, 2016, 10:25:48 am
content: if you think you can do real embedded work with only a printf over uart you better go back and stick with arduino.debugging isn't just data-loggingsingle instruction stepping, checking on any register at any given time, testing software routines and such... it is imperative to me, during developement.must have a way to do it somehow. see post belowthough i can live with compatible parts with no debug for production (like pic16f1503 and pic16f1823. the absence of debug in the 1503 makes it 25% cheaper, which is great in a 3€ BOM)

author: westfw
author_rank: Super Contributor
timestamp: October 08, 2016, 10:27:10 am
content: It depends on what you'd have "instead."An actual debug port (JTAG, SWD, etc) is nice. If you don't have that, you probably really want to have some serial port for "print" statements and software-level debugging. If you don't have that, having a "bigger" version of the chip that does have something might do. If THAT doesn't exist, how about one of those old-time and expensive emulator pods? No? Static clocking and some sort of HALT pin?

author: nctnico
author_rank: Super Contributor
timestamp: October 08, 2016, 10:31:28 am
content: Define debug port...I have a serial port on all my microcontroller projects/products. It allows to update the firmware and do diagnostics/verification during development and when the product is installed in the field. For the latter it helps a lot that a service engineer can use simple hardware (USB to UART dongle) and a terminal emulator to query the device and record logs.

author: Kalvin
author_rank: Super Contributor
timestamp: October 08, 2016, 11:07:13 am
content: For me the minimal requirements for debugging an embedded design are:- A way to download the compiled binary into the device.- A serial output (one GPIO pin) for printf() purposes.- A simple logic analyzer and an oscilloscope.Anything less is just waste of time. With a few more GPIOs available the debugging becomes a bit easier. The SPI port can also be used as a fast serial port.If the design is very complex and running on a totally new hardware, a on-chip debugger may become very useful in order to access the registers inside the chip in order to get the chip configured properly. The on-chip debugger may be also quite useful when benchmarking different algorithms on the target hardware, as you can typically download the code, start execution and perform some instruction cycle etc. timing analysis quite easily. However, after the device is up and running the system can use printf() or wiggle the GPIOs, for example), I will not use the on-chip debugger for other than downloading the code.If the target system is hard real-time, the on-chip debugger may be totally useless (other than downloading the binary) as you typically cannot stop the code execution without affecting the running system in order to read the variable values anyway: You need to go back to wiggling the GPIOs. The GPIOs are useful even in interrupt service routines where the printf() cannot be used.If the design is a total mess, the on-chip debugger may or may not help to solve the problems. When the design is clean, simple and properly designed, there is no actual need for on-chip debugger in the first place because you can use GPIOs and printf() for debugging purposes.The on-chip debugger is not and will never be a substitute for a good design and good thinking.

author: Kalvin
author_rank: Super Contributor
timestamp: October 08, 2016, 11:14:22 am
content: You should also consider using a version control system (For example, Git and others) routinely. It is very useful tool when trying to track down those nasty bugs that have crept into the design.

author: legacy
author_rank: Super Contributor
timestamp: October 08, 2016, 11:20:27 am
content: Quote from: nctnico on October 08, 2016, 10:31:28 amwell, those things like NOICE, or Talkersor those things like GDB-talker (gdb-stub? kgdb?)they all speak a protocol on the serial portthey run in privileged space (if available, hc11 doesn't have it)on platforms where there is no hardware debug-engine supportNOICE runs on 6809, 68hc11, and ARMit's a commercial application, very usefuland it's worth the money in my opinionanyhow, things like dynamic coverage requirea serious hw debugger with a large bandwidth

author: dannyf
author_rank: Super Contributor
timestamp: October 08, 2016, 11:27:16 am
content: the right answer is "all of the above": people have debug'd embedded code successively without hardware debuggers for decades and can continue to do so. however, everything else being equal, it is valuable to have that capability. But for not a must-have.Quoteyes.

author: nctnico
author_rank: Super Contributor
timestamp: October 08, 2016, 01:05:56 pm
content: Quote from: testmode on October 08, 2016, 02:12:04 amIn my experience hardware debuggers are clumsy and error prone to setup. A JTAG/SWD dongle often has flying wires or a ribbon cable. If you switch something on on your desk the JTAG interface can get enough spikes to get upset. You also have to realise that most microcontrollers cannot offer anywhere near the debugging capabilities you have on a PC. All in all debugging software on a microcontroller is to be avoided. What has worked best for me in the past >20 years is to write, debug and test software on a PC and then move it to the microcontroller. In the microcontroller it is handy to have facilities which collect statistics (number of interrupts, data transmitted, errors, etc) and which can do some testing (switch outputs on/off) and show the status. What is left for in-microcontroller debugging are the parts which interact with hardware. For testing/verifying the hardware layer test commands over a serial port (which can be scripted from a PC!) and an oscilloscope/logic analyser are good tools.I guess the trick is to catch errors (bugs, buffer overflows, dangling pointers, etc) before they get into the microcontroller. With hardware in the loop and a slow CPU core it can take days before a bug surfaces. On a PC you can pull test data through the algorithm in seconds and know exactly what goes wrong before lunch.

author: Jeroen3
author_rank: Super Contributor
timestamp: October 08, 2016, 01:17:17 pm
content: A hardware debug, with breakpoints and run/stop, is used only during device driver stage.After that, you write software that gathers valuable information for the developer. And stream them out over any interface. When possible, I make sure to have at least 1 uart TX available.For a live stream of variables. Since a trace capable debugger for arm is expensive.

author: testmode
author_rank: Regular Contributor
timestamp: October 08, 2016, 05:45:05 pm
content: Quote from: JPortici on October 08, 2016, 10:25:48 amAgree on this. This also makes it easier to inspect/visualize memory usage and alignments especially if the code has a bunch of structs and misaligned register allocations. I believe it is also particularly useful for new/learning developers to be able to step thru and find their way thru the loops-and-hoops of the code. It can be argued that all of this are still possible to do thru alternate ways like serial ports, toggling of GPIOs, etc, but it is a lot more efficient with a "real" debugger (an engineer's time is valuable too!).

author: testmode
author_rank: Regular Contributor
timestamp: October 08, 2016, 05:47:49 pm
content: Quote from: westfw on October 08, 2016, 10:27:10 amRunning thru FPGA with the debug option enabled in the Cortex design integration is an option that we've used too. Although this can be really tricky when working with mixed-signal custom ASICs as the models of the analog blocks rarely work in a "realistic" way as their real-word counterparts.

author: testmode
author_rank: Regular Contributor
timestamp: October 08, 2016, 05:50:09 pm
content: Quote from: nctnico on October 08, 2016, 10:31:28 amIn this context, I am specifically referring to the debug port as a means to step thru code, view memory, variables, and registers in "real-time", and maybe all the way to having trace capabilities as this option can sometimes be intentionally taken out in the design of the chip itself, mainly with the intention to save cost.We also normally have serial port and in-system programming capabilities on all of our systems as this is a must in the field for the same reasons as you have mentioned.

author: testmode
author_rank: Regular Contributor
timestamp: October 08, 2016, 05:52:30 pm
content: Quote from: dannyf on October 08, 2016, 11:27:16 amTrue that engineers will *always* find a way to solve a problem (and often the more challenging it is, the more driven we are). However, I feel that nowadays, the software side of the system is becoming more important and oftentimes, it can be THE factor than can make or break a project. Having a "real" debug port to give you a deeper insight and more efficient way of analyzing the code and solving problems can be a big advantage especially for industries where speed of execution is key.

author: testmode
author_rank: Regular Contributor
timestamp: October 08, 2016, 05:55:53 pm
content: Quote from: nctnico on October 08, 2016, 01:05:56 pmAgree and this is also one of the pains that we usually encounter. But this mostly happens only during the initial setup (and by initial I mean the very first time that we setup the system). Once it is up and running and all connections are clean and stable, we rarely encounter recurring problems on the debug interface on a day-to-day basis.Quote from: nctnico on October 08, 2016, 01:05:56 pmFirst statement, I agree. But as for the second one, I think it's difficult to make a general statement for it and I guess it could largely depend on the project. For instance in our case, I couldn't see a primary reason why we would avoid debugging on the chip itself if it is available as it makes for a more efficient approach than any other debug option (i.e. serial printfs or toggling GPIOs).Quote from: nctnico on October 08, 2016, 01:05:56 pmInteresting approach. I will definitely keep this in mind and see if it can be applicable to our projects!By the way, don't you think it's a bit of an extra effort to adapt the code to run on PC then move it to the micro? I presume you have to make some build-specific options and/or directives to make it work in both conditions. But then again, it has worked for you for so many years so I guess the answer to that is the effort is eventually worth it.

author: testmode
author_rank: Regular Contributor
timestamp: October 08, 2016, 05:57:52 pm
content: Quote from: Jeroen3 on October 08, 2016, 01:17:17 pmTrue. This is actually one of the counter-argument we have on this same debate at work. Debuggers are usually only extensively used during the driver development stage. After that, it just sits on the desk gathering dust. In addition, you could still technically manage to develop the driver code even without a debugger with just a bit more effort. But then, when that nasty stubborn hard fault comes (or any software bug in a similar degree for that matter), the debugger will save a ton of the engineer's time!For me, a debugger is one of those tools that only sees action once in a while but when it does, there is no better substitute for it. I guess this is why ARM is charging an arm-and-a-leg for trace-capable debugger as it can easily pay for itself when the time comes that you need it (assuming the project is financially worth it as well).

author: nctnico
author_rank: Super Contributor
timestamp: October 08, 2016, 06:02:05 pm
content: Quote from: testmode on October 08, 2016, 05:55:53 pmUsing GCC and Eclipse solve the problems introduced by compiler specific C extensions. GCC is GCC whether you compile for a PC or microcontroller. I often have the microcontroller project(s) and PC support/testing project(s) living in the same Eclipse workspace so 'switching' between them and comparing code/results is easy. It is all joined together in one world.

author: Karel
author_rank: Super Contributor
timestamp: October 08, 2016, 07:04:30 pm
content: I never use any kind of debugger. I just use a serial port to print some debug messages and I use one or more gpio pins to check algorithms and interrupt routines.

author: nctnico
author_rank: Super Contributor
timestamp: October 08, 2016, 07:28:55 pm
content: Quote from: testmode on October 08, 2016, 05:57:52 pmFortunately ARM cores have a fault handler. I always have a routine attached to that which dumps a (short) stack trace onto the serial port with dedicated UART routines. This trace usually has some clear pointers to the offending routine and associated variables. Additionally I have a lot of index and pointer checking in my code to compartmentalise bugs (actually I try hard to minimise/eliminate the use of pointers). Using a bad index or NULL pointer causes the rest of the program to refuse the input and not to work. That is much easier to debug than a program which crashes randomly.

author: dannyf
author_rank: Super Contributor
timestamp: October 08, 2016, 10:52:10 pm
content: QuoteThat's the correct view, assuming that your bugs don't come from software / hardware,The toughest bugs are those that come from compilers, poorly written code that interacts with others unexpected, or hardware. There is no way that you can test your code against all applications. So no matter how modular your code is, there is a risk that when integrated with other fine working pieces, the combination may stop working.a hardware debugger comes handy in those cases.But like anything else, the most useful debuggers are the human brains, functional ones only. So hardware debuggres are a nice to have, not a must have. The thing between your ears is the only must-have in debugging.

author: testmode
author_rank: Regular Contributor
timestamp: October 09, 2016, 06:29:48 am
content: Quote from: dannyf on October 08, 2016, 10:52:10 pm"..., functional ones only" - this cracked me up!Too much of this >can probably lead to that haha...now, this is a case where even the most capable debuggers will never be enough to solve!

author: testmode
author_rank: Regular Contributor
timestamp: October 09, 2016, 06:31:37 am
content: Quote from: nctnico on October 08, 2016, 07:28:55 pmYup, I use this approach too. But the fault handler can only do so much, plus you will actually have to write it as well - maybe it can start as a generic dump of the core registers, stack, etc but for really stubborn faults like those ones that actually originate not from the point of the fault but somewhere else deep within the call stack, having a debugger on hand will help save a lot of time - just plug in, set a breakpoint on the fault handler (or the fault line if it is already known), execute, wait for the hard fault and voila, the actual state of the hardware is all in your hands from the call stack down to the actual memory state.The depth of information and ease of access to it that only a debugger can provide is what makes it an essential tool.Quote from: nctnico on October 08, 2016, 07:28:55 pmPointers can be evil but they are a necessary evil in C. A couple of particular cases in mind where I'd rather use pointers are: passing a pointer to struct as an argument to a function rather than a bunch of args; and pass-and-modify a "local" variable on to other functions rather than using a global var (which I would rather avoid than pointers). I think the negative connotation for pointers stems from the fact that they can be very hard to keep track from within our head when visualizing code (especially if the code was written by someone else) and this is another reason where the debugger's ability to step thru code and allow us to view the actual memory in real-time also comes in very handy.

author: Karel
author_rank: Super Contributor
timestamp: October 09, 2016, 10:04:49 am
content: Quote from: testmode on October 09, 2016, 06:31:37 amI don't agree. Pointers are a feature of C that allows one to write efficient programs.Ofcourse, C does require an experienced programmer who knows what he is doing.Saying that pointers are evil is like saying that surgeons with a scalpel are evil becausescalpels can be dangerous.

author: donotdespisethesnake
author_rank: Super Contributor
timestamp: October 09, 2016, 10:25:18 am
content: Pointers are just addresses. Addresses are required by the CPU. So all C is doing is "allowing" you to access the bare metal easily, but it is not adding much in the case of pointers. The pointer type is easily overridden. C is basically a souped-up assembler.QuoteYeah, that is exactly why they are evil, 90% of C programmers are inexperienced and don't know what they are doing! Seriously, I had a colleague trying to compare strings with "==". I tried to explain pointers to him, I am not sure he understood at all.Obviously nothing is inherent evil. A better analogy: "pointers are like giving C4 to kids to play with on July 4".

author: Karel
author_rank: Super Contributor
timestamp: October 09, 2016, 10:37:28 am
content: Quote from: donotdespisethesnake on October 09, 2016, 10:25:18 amBut those programmers are not writing any important or security related software, so, who cares?Pointers are not evil. People can be evil. Programmers can be evil. Pointers are not. They have a purpose and they are not going away.

author: legacy
author_rank: Super Contributor
timestamp: October 09, 2016, 11:21:06 am
content: Quote from: nctnico on October 08, 2016, 06:02:05 pmcorrectQuote from: nctnico on October 08, 2016, 06:02:05 pmwell, I don't agree

author: legacy
author_rank: Super Contributor
timestamp: October 09, 2016, 11:22:33 am
content: Quote from: testmode on October 09, 2016, 06:31:37 amexactly what I meant when I quoted out dynamic coverage need

author: nctnico
author_rank: Super Contributor
timestamp: October 09, 2016, 11:40:23 am
content: Quote from: Karel on October 09, 2016, 10:04:49 amEfficient comes at the cost of not being able to trap an error. All in all efficient and robust just don't go well together and with software getting more complex and CPUs getting faster robust is becoming way more important than efficient. Instead of pointers I prefer to use getters/setters and an index to an array with structs. Maybe it is not efficient but checking the index for a valid value is pretty easy. If you adopt robust programming methods you are much less likely to need a debugger to chase elusive bugs.

author: legacy
author_rank: Super Contributor
timestamp: October 09, 2016, 11:42:28 am
content: Quote from: donotdespisethesnake on October 09, 2016, 10:25:18 amof course they are, frankly, the problem is when people does messes withpointer arithmeticin first place it's makes the code "less-readable" (completely unreadable?), also ... sometimes the behavior might depend on the C implementation (it's a defect of the C language itself), therefore you'd better avoid to mess with pointers, which is also best practice because it makes the source more easy to be understood for those who happen to read the code without being involved in the development (e.g. QA dudes, and testing dudes)

author: legacy
author_rank: Super Contributor
timestamp: October 09, 2016, 11:46:48 am
content: Quote from: nctnico on October 09, 2016, 11:40:23 amthose who need to pass the CodePurify andCantataall agree with youbecause we need to stub, therefore getters/setters are exactly the best way

author: legacy
author_rank: Super Contributor
timestamp: October 09, 2016, 12:07:50 pm
content: some codes do not stay alone, they are part of a life-cyclewhose first steps aredesign (here, dudes use AADL, things likeStood)constraintslow level requirementshigh level requirementsinterfaceserror propagation, in normal and abnormal conditionexpected behavior, for normal and abnormal conditionimplementation (here you write ADA, C and assembly code)test plan (here you use Microsoft Office, you write a document about your testing activity, it must be approved)test report (here you use debuggers, and tools likeCantatato test your code accruing to the test plan)(simplified line, there more points)you have to test your code and provide documentswhich demonstrate you have carefully respectedall the constraints and requirementsQA dudes will reserve to accept or reject your workand you can't commit it without their approbationthe logical consequence is: you don't abuse of pointers and other thingsbecause if you do so ... well it will take more difficult to have the plan acceptedand tests passed, in short it won't be payed

author: legacy
author_rank: Super Contributor
timestamp: October 09, 2016, 12:34:09 pm
content: just a question: has anyone here happened to develop his or her own debuggerfor his her own softcore? I am curioushere it's an old project I am carrying on when the weather is terrible(like today, the whole plan for this weekend is gone)

author: Kalvin
author_rank: Super Contributor
timestamp: October 09, 2016, 12:38:36 pm
content: Quote from: legacy on October 09, 2016, 12:34:09 pmYou can make a simple GDB-stub inside your embedded microcontroller which can be used with the GDB debugger:http://www1.cs.columbia.edu/~sedwards/classes/2002/w4995-02/tan-final.pdfHere is a GDB-stub implemented for the Arduino:http://www.codeproject.com/Articles/1037057/Debugger-for-ArduinoHere is yet another simple debugger idea:http://pygmy.utoh.org/3ins4th.htmlIt doesn't have to Forth as any other simple command interface will do.

author: legacy
author_rank: Super Contributor
timestamp: October 09, 2016, 01:49:48 pm
content: so,gcc even compiles for the toasters, and gdb even debugs stones,and putting gdb in your target is like a piece of cake- yes, all true(sarcasm), but I am more happy without any GNU pride in my gears

author: Kalvin
author_rank: Super Contributor
timestamp: October 09, 2016, 02:06:21 pm
content: *removed my comment as obsolete as legacy edited his own comment above.*

author: westfw
author_rank: Super Contributor
timestamp: October 10, 2016, 04:29:27 am
content: Quote from: legacy onTodayat 05:34:09 AMNo, but it's interesting to look at historical and current designs.Back in the z80/1802 days, you could use external logic to start a DMA cycle, which caused the cpu to relinquish the bus. Then you could have debug circuits manage the bus instead, and they could go around and look at the contents of memory, relatively unimpeded (this was pre-DRAM, too.) IIRC, interrupts worked by having the interrupt controller jam an instruction onto the databus, rather than having the CPU access memory. Usually one would insert a RST instruction or a CALL, but at least theoretically you could throw an "out DEBUGPORT, REG" on there, and examine the registers. (Huh. I don't know of any z80 debug tools that actually DID that sort of thing, but it seems it should have been possible. And perhaps useful. I wasn't debugging Z80s at the time.)In (more) modern times, there is the Atmel AVR "debugwire" protocol, which is undocumented, but from reverse engineering (http://www.ruemohr.org/docs/debugwire.html)seems to have been implemented along similar lines - many of the debug commands are implemented as "load an instruction onto the instruction bus, and have the results sent to the debugwire hardware (which spits it out.) This seems like a pretty powerful concept - use the CPU itself to do most of the work. Add a few address comparators for break and watchpoints, and you've got yourself the basics...

author: technix
author_rank: Super Contributor
timestamp: October 10, 2016, 12:57:02 pm
content: I absolutely depend on the debug port even later in the development cycle, as I depend very heavily on tracing to debug the code. When something is not working right, I throw a breakpoint into the code, and trace the code through the portion that gives me issues, monitoring the registers and variables very closely.My code scarcely, if ever, generate any debug output. Most of the time if there is no real use of a serial port I won't even initialize it.

author: jaromir
author_rank: Unknown
timestamp: October 11, 2016, 05:33:37 pm
content: Quote from: legacy on October 09, 2016, 12:34:09 pmI developed debugger for (not soft-core) 8-bit microcontroller, does it count? I used debugger a lot while developing the debugger, to keep on topic.

author: ehughes
author_rank: Frequent Contributor
timestamp: October 12, 2016, 02:13:08 am
content: Not providing SWD, JTAG, etc. access on board reeks of someone who was little experience producing hardware on a large scale.... The only folks who think that is OK are the Arduino, MBED and kitchen table programmers.Debugging with LED blinks and printfs when out of style in the 90's. Honestly, being in the industry before hardware debuggers are around, they save a bunch of time. Not that those other methods are not useful but being able to directly inspect memory during operation allows for much quicker debug of complicated problems. Kinda like debugging a PLL problem on a batch of buggy 1000 NXP ICs after the software guys said that everything is working fine. The JTAG port is an insurance policy to get some visibility when everything else is hosed. LEnginering time is very expensive. Software is the most expensive commodity on the planet. Any tool that can save time (adding the JTAG port) pays dividends long after the PCB design is done. Don't let an arrogant software guy fool you into thinking all they need are there bootstraps....That being said.... A project that can't afford the debug tools probably can't afford the software developer either. The latter is much more expensive. If this small cost is holding up the project, that project is doomed. Walk fast in the opposite direction as you want no part of it.

author: nctnico
author_rank: Super Contributor
timestamp: October 12, 2016, 08:06:18 am
content: Quote from: ehughes on October 12, 2016, 02:13:08 amWho said you can't view the memory over a serial port? Try looking at the contents of an SPI flash or I2C eeprom over JTAG...

author: technix
author_rank: Super Contributor
timestamp: October 12, 2016, 10:43:00 am
content: Quote from: nctnico on October 12, 2016, 08:06:18 amThen try to figure out why the UART itself is giving you problems.

author: Psi
author_rank: Super Contributor
timestamp: October 12, 2016, 11:10:55 am
content: You NEED some sort of debug method for your own sanity. Weather this is JTAG or a flashing LED on GPIO doesn't matter that much.You can do a lot of debugging with just an LED on GPIO and a scope on that.I'm a fan of having a software serial port running at almost CPU speed to dump out whats happening in real time (function enter/exit and what's inside key variables). Then log this and watch/view in realtime or after the fact.

author: nctnico
author_rank: Super Contributor
timestamp: October 12, 2016, 11:27:47 am
content: Quote from: technix on October 12, 2016, 10:43:00 amIf you can't get a UART going (even without interrupts) then you have bigger problems outside the microcontroller

author: rsjsouza
author_rank: Super Contributor
timestamp: October 12, 2016, 11:59:18 am
content: Quote from: nctnico on October 12, 2016, 11:27:47 amI have seen many different cases that demanded either higher level debugging approach (via printf/UART/Ethernet/USB messaging) or algorithm debugging (using a PC instead of an embedded system). When dealing with a High Level OS (Linux, ONX, any RTOS) you end up using the OS debugging mechanism.However, I've also seen many scenarios where either the debug port (UART/Ethernet/USB) or one of the device's core simply went caput for many reasons - cache alignment/coherency problems, DMA priority deadlocks, inter-core memory transactions that go rogue... These are very difficult to reproduce in a PC and the JTAG (in some cases even a trace analyzer) is your last line of defense to track down the issue. I have seen PCB board revisions being scraped as they did not provision for JTAG and were having glitches or complete lockup errors.Another scenario I consider JTAG as really king: new board bringup, especially with big-honking multi-asymmetric core devices.

author: mac.6
author_rank: Regular Contributor
timestamp: October 12, 2016, 12:32:02 pm
content: JTAG/ETM/SWD are invaluable tools. It's not just trace but when you need to debug by looking at registers/memory/pointers, set simple or complex data breakpoints then a serial port is not enough.I even use less and less serial printf since I use j-link and their RTT/systemview, less intrusive, faster (depend on j-link) and more convenient.Today jtag/swd probes are so cheap that remove or not providing access to it on a design is just dumb (minus final production design where you can just remove direct access)

author: Bruce Abbott
author_rank: Frequent Contributor
timestamp: October 12, 2016, 01:02:40 pm
content: Quote from: mac.6 on October 12, 2016, 12:32:02 pmButwhydo you need to do that?

author: Jeroen3
author_rank: Super Contributor
timestamp: October 12, 2016, 02:08:01 pm
content: If you are not able to simulate your code. And don't have black belt pointer kung fu, you need to debug some software units by looking at pointers and registers. It's inevitable.

author: technix
author_rank: Super Contributor
timestamp: October 12, 2016, 02:20:10 pm
content: Quote from: Jeroen3 on October 12, 2016, 02:08:01 pmEven if you have a simulator and black belt pointer kung fu you still need it from here to there, as even the best of masters can slip up occasionally. Simulators may not represent the actual hardware to the trueth, and if you have hardware attached on the external memory bus good luck finding a simulator that is capable of simulating everything.

author: testmode
author_rank: Regular Contributor
timestamp: October 12, 2016, 03:33:47 pm
content: Quote from: technix on October 12, 2016, 02:20:10 pmAlso, good luck trying to simulate problems caused by design marginality and/or process variations. End-users and embedded developers may not actually encounter this, but for test engineers developing codes that are actually meant to test the chips themselves, having access to a debugger could mean the difference between figuring out the problem on a late Friday night* or if without, spending the entire weekend at worktoggling GPIOs, wrestling serial IOs or what not and yet still come up with merely at best an "intelligent hypothesis" by Monday morning. I'll say it again: debuggers are essential and nothing could come close to what it can do when you need one.(*It is true that the hardest of problems will eventually find its way to pop-up on a Friday whether you like it or not.)

author: obiwanjacobi
author_rank: Super Contributor
timestamp: October 12, 2016, 03:46:08 pm
content: And I thought using serial for debug log output was a bad practice...If you unit test your components and work with proven libraries, you should not have to debug very much. But if you need to debug you better get all the information there is...Using an extra hardware pin (or two) on the device hooked up to a scope/logic analyzer can also be very informative.Debugging is subject to theHeisenberg uncertainty principle: you influence what you measure.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: October 12, 2016, 04:48:41 pm
content: Add me to the camp that finds a debug port (typically J-TAG) to be essential. With my hobbyist hat on, it's very simple: I just won't use an MCU without a J-TAG port that allows me to set breakpoints and single step code.In my other life as a professional embedded developer, I have considerable say when it comes to choosing an MCU for a product, and will always strongly advocate for one with J-TAG. If I have to, I can work with MCUs that don't have modern debugging capabilities, but I find that it takes me longer to troubleshoot the really difficult issues that sometimes arise.I'm a strong advocate of using proper tools for the job. That means a proper J-TAG adapter along with a debugger that can set breakpoints, step code, and even provide trace data. Sure, a J-TAG device that has trace capability like a Segger J-TRACE is expensive, but my time is even more expensive. If I save five hours of debug time over the lifetime of the tool, I've paid back my investment in it. The same applies to other tools such as oscilloscopes and logic analyzers. In my opinion, these tools are also essential for anyone doing embedded work on a professional level.I've run into lots of people who pride themselves on their ability to debug embedded hardware and software with primitive tools and techniques. If you're a hobbyist with limited funds, then more power to you! If you're a professional, then you're probably taking more time than someone with equal skills and the proper equipment would, and as I've said repeatedly in this forum,time is money.

author: Karel
author_rank: Super Contributor
timestamp: October 12, 2016, 05:11:49 pm
content: Quote from: obiwanjacobi on October 12, 2016, 03:46:08 pmSomebody needs to write those libraries.

author: ehughes
author_rank: Frequent Contributor
timestamp: October 12, 2016, 07:40:48 pm
content: Quote from: nctnico on October 12, 2016, 08:06:18 amYou missed what I wrote. You can certainly looked at things *indirectly* with a serial port, etc (which I do quite often) but you just introduced another layer. Using JTAG or SWD, I can initiate AHB transactions in an ARM CMx device without the CPU being involved. That is about as close as you can get to being able to see what is really going on. Once you can do initiate bus transactions, you can even talk to peripherals at will without relying on the CPU to see what us going on real time. And yes you could even perform SPI transactions to see what is in an EEPROM if the CPU is completely dorked up.The serial port method is OK for certain types of problems (high level inspection, etc) but you are making some big assumptions that the state of your system is sane when you are tracking down the problem. You are simply being dumb if you don't put the SWD/JTAG headers on the board. The debug tools save time and hassle when interacting with complicated hardware. The idea is to have more visibility into the system, not less by limiting yourself to primitive techniques.

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: October 12, 2016, 08:22:29 pm
content: In professional embedded development, on chip debugging support simply is a "must have" since a couple of years (like 15 years or so when you count the very first simple ODS stuff). And it's not only to speed up development or to make it possible to find sporadic bugs, but also for testing and performance evaluation. The usability of simulators is very limited in realtime systems.Don't get me wrong: I started in 1999 with private AVR development at home and had no debugging possibility at all. Also, back then, we mainly used CAN based monitoring software to develop embedded systems at work.We had some HW emulators but they were as unreliable as hell. In some cases we even used (HW) logic analyzers to trigger on certain address accesses on the (external) bus.But this was the 20th century. It was tedious back then but nowadays with embedded flash, sophisticated peripherals, multicore architectures and megabytes of SW, it's simply not feasible anymore. Actually, every time I have to work on a project without full (instruction/data) trace possibilities I feel somewhat crippled.For my private spare time projects, the limited debugging support through JTAG or SWD is OK but developing completely blindfolded like in the 90s is nothing I really want to do anymore if I don't have to. I'd only accept it for a very small PIC or tinyAVR project where pin count matters and the code size is very small anyway.

author: legacy
author_rank: Super Contributor
timestamp: October 12, 2016, 09:35:47 pm
content: Quote from: Sal Ammoniac on October 12, 2016, 04:48:41 pmexactly the point I wrote before, nice to see that someone thinks in the same wayI have two J-trace in my bag, exactly for that reason: my time is even more expensive

author: obiwanjacobi
author_rank: Super Contributor
timestamp: October 13, 2016, 05:22:55 am
content: Quote from: Karel on October 12, 2016, 05:11:49 pmFrom what I've gathered, most people prefer to write their own...

author: mac.6
author_rank: Regular Contributor
timestamp: October 13, 2016, 08:44:58 am
content: Quote from: Bruce Abbott on October 12, 2016, 01:02:40 pmI don't need it everytime, but there is classes of bugs that requires it:- typical heisenbug: a printf or trace make the bug disappear due to timing/scheduling issues- hardware bug or bugs in special domain transition (like switching clocks, going in/out of sleep).- Bugs that happens only in release code, so without trace and with optimization turned on (ie no static variables)- Stack or memory corruptions.Most of these bugs are rarely seen in hobbyist project, but when you work on big projects with tons of third party code and very high complexity you don't want to debug them with your typical printf.J-link trace is not expensive at all, yes it's around 1k$, but ask for a lauterbach ETM quote....

author: Jeroen3
author_rank: Super Contributor
timestamp: October 13, 2016, 09:18:46 am
content: Quote from: mac.6 on October 13, 2016, 08:44:58 amAnd the 5k software license. You also know the debugging has become real when the uTrace adapterhas a heatsink.

author: technix
author_rank: Super Contributor
timestamp: October 13, 2016, 09:53:03 am
content: Quote from: Jeroen3 on October 13, 2016, 09:18:46 amIf you don't mind tinkering a bit you can always drop back to USB Blaster clone + OpenOCD + GDB. USB Blaster clones (the ones using original Altera design only) are really a generic USB to JTAG adapter with absolutely no additional features baked in. It is up to the computer to implement the debug support, which OpenOCD does.

author: legacy
author_rank: Super Contributor
timestamp: October 13, 2016, 03:35:49 pm
content: Quote from: technix on October 13, 2016, 09:53:03 amwell ….

author: technix
author_rank: Super Contributor
timestamp: October 13, 2016, 04:06:09 pm
content: Quote from: legacy on October 13, 2016, 03:35:49 pmIt never hurt to have a backup plan. Before I have acquired the J-Link clone and Atmel ICE that was my way of JTAG debugging pretty much anything. Too bad GDB does not support AVR yet.When you are a startup you have to put a lot of emphasis into the cost of tools. At least my investor won't allow me to drop a lot of cash on advanced tools like J-Trace, so I have to use the tools available within the budget cap of my investor and make it work.The USB Blaster clone + OpenOCD + GDB stack worked well enough for me to get my project kickstarted.

author: legacy
author_rank: Super Contributor
timestamp: October 13, 2016, 04:09:50 pm
content: unusual guessanyone has ever used jbug11 (68hc11) with its talker?Metrowerks CodeWarrior for PlayStation/R5 with Caetla talker?any CodeWarrior/m68k-EZ with MT-ADS-EZ talker?other kind of talker? including your own made talker?- may be? -just for my curiosity

author: Kalvin
author_rank: Super Contributor
timestamp: October 13, 2016, 04:16:03 pm
content: At one point in my life I used the Debug-56K with the DSP56300-series DSP processors very often. That was quite handy!

author: legacy
author_rank: Super Contributor
timestamp: October 13, 2016, 04:22:27 pm
content: Quote from: technix on October 13, 2016, 04:06:09 pminteresting, so you use clones

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: October 13, 2016, 04:55:23 pm
content: Quote from: legacy on October 13, 2016, 04:22:27 pmDo you use the Segger drivers or did you write your own?

author: technix
author_rank: Super Contributor
timestamp: October 13, 2016, 05:14:06 pm
content: Quote from: legacy on October 13, 2016, 04:22:27 pmOnce again, budget cap. Either grab a clone and hope it work; or bust the budget cap, drive the investor out, and shut the startup down, with them have the right to take away whatever they and I have invested. The investors in China are often cheapies and force their ideal onto startups they invest in. I try my best not to be one but I have to stick to el cheapo tools until I can buy back the shares the investors is holding.

author: technix
author_rank: Super Contributor
timestamp: October 13, 2016, 05:35:21 pm
content: Quote from: Sal Ammoniac on October 13, 2016, 04:55:23 pmNeither. Daily driver stack is libusb + OpenOCD. I do have Segger drivers installed (but not enabled by default) so I can update its firmware and troubleshoot on the odd occasions when such an occasions arises.

author: legacy
author_rank: Super Contributor
timestamp: October 13, 2016, 06:23:25 pm
content: Quote from: Sal Ammoniac on October 13, 2016, 04:55:23 pmfor my job I use only professional and original toolswith those clones I always had a lot of problems

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: October 13, 2016, 06:30:01 pm
content: Depends a lot on what you're doing - you may not often need it, but when you do, you really need it - a decent debugger can easily save days of debugging.

author: technix
author_rank: Super Contributor
timestamp: October 13, 2016, 06:53:15 pm
content: Quote from: legacy on October 13, 2016, 06:23:25 pmWith a recent raise to my tool budget cap I did acquire some original tools (PICkit 3, Atmel ICE - I use different platform for different projects, so don't ask me why I have a fairly wide array of tools) but original J-Link is still out of my league. If my current clone failed on me again and I still cannot afford a genuine one I would try to create my own, based on the open source CMSIS-DAP for STM32 design.

author: andyturk
author_rank: Frequent Contributor
timestamp: October 13, 2016, 07:36:03 pm
content: Quote from: mac.6 on October 13, 2016, 08:44:58 amI bought one of Segger's J-Trace Pro for Cortex-M debuggers this year with some consulting $$. For normal use, it works exactly the same as the $60 EDU J-Link (and costs *only* 30x more!).However, I've spent weeks single-stepping code that I didn't have source for to find/fix a bug. Single stepping assembly code isn't a common thing, but it happens from time to time. I was well paid for those weeks, but I'd much rather find the problem quickly with a more powerful tool.I haven't used the J-Trace in anger yet because the projects I've been working on haven't brought out the trace bus. But someday I'll be faced with one of those nasty bugs *and* have the trace bus brought out on the board.

author: mac.6
author_rank: Regular Contributor
timestamp: October 20, 2016, 02:35:36 pm
content: well not exactly like the EDU: first you have trace capabilities and Ozone licence.EDU has a max JTAG speed around 15MHz, SWO sampling 7.5MHz whereas ULTRA and Trace PRO are 50MHz JTAG / 100MHz SWO.This doens't make any differences for basic jtag use, but when you use RTT trace, systemview plugins etc... I can tell you that this make a lot of difference!BTW, onboard J-Link on most dev boards are limited around 1MHz jtag speed. Ok for loading code and basic debugging, but you can't use seriously RTT/systemview without impact.That's why I have an UltraPro+ at work and an EDU at home...

author: legacy
author_rank: Super Contributor
timestamp: October 22, 2016, 11:16:28 am
content: yesterday I modified my debug engine (integrated within my own soft core)in order to support a new kind of test point: cbranch-pointso, now I havebreak point, the PC triggers the eventwatch point, the EA triggers the event (Effective Address used in load/store stage)cbranch point, every conditional branch triggers the eventit's useful for thedynamic coverage

author: technix
author_rank: Super Contributor
timestamp: October 22, 2016, 11:46:42 am
content: Quote from: legacy on October 22, 2016, 11:16:28 amYou might as well extend the cbranch point to a more generic opcode point - whenever a certain opcode is encountered it triggers the event. to break on cbranches just break on the cbranch opcodes.

author: John Coloccia
author_rank: Super Contributor
timestamp: October 22, 2016, 01:07:31 pm
content: I voted for "it's not needed." Honestly, I really just can't remember the last time I used a debugger for anything. Maybe I should have voted for one of the other options because it is very occasionally convenient. I can't actually remember ever working on a system that didn't have SOME access to JTAG, even if the connector was unpopulated and I had to solder wires to get to it. I don't know. If it's no big deal to include one, I don't see why you'd go out of your way to remove it, but if it's causing massive space and cost problems for some reason it would definitely be one of those things I'd consider removing, especially on a more mature project.

author: pelule
author_rank: Frequent Contributor
timestamp: October 22, 2016, 01:12:52 pm
content: I voted "Must have" - simply because thats my resumee out of more than 20 years of embedded development.In the past a very expensive in-circuit emulator was the only way to get a project ready in calculated time.Since the flash based products are in the market the debug port offers a lower cost solution.

author: nctnico
author_rank: Super Contributor
timestamp: October 22, 2016, 01:19:20 pm
content: Reading this thread the necessity of a debug port depends largely on what kind of work you do (low level stuff without any I/O), whether you develop higher level software on the hardware itself or use a PC/simulator and last but not least programming style. Also when it comes to more advanced features (like profiling or 'realtime' debugging) it seems you still have to pay a lot of money for a good debugging environment. OTOH several low cost solutions are available nowadays which wheren't there in the 90's and earlier so setting breakpoints, stepping and watching variables is cheaper than ever nowadays.

author: legacy
author_rank: Super Contributor
timestamp: October 22, 2016, 01:38:49 pm
content: about me, i'd better talk about"instrumentation", refering to an abilitya) to monitor and b) to measurethe level of a product's performancec) to diagnose errors and d) to record traces"traces" are needed when you have to fillsome reports, test reports and coverage reportsyou need to include some file as evidenceI also need to alter the common flowbecause I need to prove and to checkthe the behavior of the programunder "abnormal conditions"therefore I need to break on some pointsand then I need to modify registers/branchesin order to force the code and see ifeverything goes according to requirements

author: John Coloccia
author_rank: Super Contributor
timestamp: October 22, 2016, 02:49:15 pm
content: Quote from: nctnico on October 22, 2016, 01:19:20 pmI think it's more about "programming style" than anything else, and how you're used to working. I think older guys like me (and I'm not that old....42...but old enough) are simply used to working without a good debugger, and you get kind of good at looking at a piece of code and being able to imagine exactly what's going on, what timing issues may exist and things like that, because you just had to be.It's kind of like doing arithmetic in your head. If the work you do requires that you do a lot of calculating, and I have had to do stuff like this from time to time, you just start getting a feel for the numbers involved, you learn tricks etc, and you end up being able to do a lot of stuff in your head much faster than whipping out a calculator. And then you don't do it for a while and it all goes away and you become stupid again.A lot of my early career was stuff like radar processing and robotics. Often times you can't even get to the processor in question, never mind getting some sort of debug setup going, so it's not even really an option, but it's hard to imagine why you would ever not provide that sort of access during development, or at a minimum you should at least have a development board to work on so you can test your code, do you debugging if you have to and then try it on the real thing. This stuff is hard enough as it is so it's kind of dumb to limit your options, even if you don't use them 99% of the time.