[POLL] Necessity of Debug Port for Code Development

[Karel]

Pointers can be evil but they are a necessary evil in C.

I 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 because
scalpels can be dangerous.

[donotdespisethesnake]

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.

C does require an experienced programmer who knows what he is doing

Yeah, 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".

[Karel]

Yeah, that is exactly why they are evil, 90% of C programmers are inexperienced and don't know what they are doing!

But 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.

[legacy]

I presume you have to make some build-specific options and/or directives to make it work in both conditions

correct

GCC is GCC whether you compile for a PC or micro controller

well, I don't agree

[legacy]

The depth of information and ease of access to it that only a debugger can provide is what makes it an essential tool

exactly what I meant when I quoted out dynamic coverage need

[nctnico]

Pointers can be evil but they are a necessary evil in C.

I don't agree. Pointers are a feature of C that allows one to write efficient programs.

Efficient 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.

[legacy]

Pointers are just addresses

of course they are, frankly, the problem is when people does messes with pointer arithmetic

in 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)

[legacy]

Instead of pointers I prefer to use getters/setters and an index to an array with structs

those who need to pass the CodePurify and Cantata all agree with you
because we need to stub, therefore getters/setters are exactly the best way

[legacy]

some codes do not stay alone, they are part of a life-cycle
whose first steps are

• design (here, dudes use AADL, things like Stood)
  
  • constraints
  • low level requirements
  • high level requirements
  • interfaces
  • error propagation, in normal and abnormal condition
  • expected behavior, for normal and abnormal condition
• implementation (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 like Cantata to test your code accruing to the test plan)

(simplified line, there more points)

you have to test your code and provide documents
which demonstrate you have carefully respected
all the constraints and requirements

QA dudes will reserve to accept or reject your work
and you can't commit it without their approbation

the logical consequence is: you don't abuse of pointers and other things
because if you do so ... well  it will take more difficult to have the plan accepted
and tests passed, in short it won't be payed

[legacy]

just a question: has anyone here happened to develop his or her own debugger
for his her own softcore? I am curious 
here it's an old project I am carrying on when the weather is terrible
(like today, the whole plan for this weekend is gone )

[Kalvin]

just a question: has anyone here happened to develop his or her own debugger
for his her own softcore? I am curious 
here it's an old project I am carrying on when the weather is terrible
(like today, the whole plan for this weekend is gone )

You 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.pdf
Here is a GDB-stub implemented for the Arduino:
http://www.codeproject.com/Articles/1037057/Debugger-for-Arduino

Here is yet another simple debugger idea:
http://pygmy.utoh.org/3ins4th.html
It doesn't have to Forth as any other simple command interface will do.

[legacy]

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

[Kalvin]

*removed my comment as obsolete as legacy edited his own comment above.*

[westfw]

Quote from: legacy on Today at 05:34:09 AM

just a question: has anyone here happened to develop his or her own debugger for his her own softcore? I am curious 

No, 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...

[technix]

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.

[jaromir]

just a question: has anyone here happened to develop his or her own debugger
for his her own softcore?

I 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.

[ehughes]

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.  L

Enginering 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.

[nctnico]

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.

Who 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...

[technix]

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.

Who 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...

Then try to figure out why the UART itself is giving you problems.

[Psi]

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.

[nctnico]

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.

Who 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...

Then try to figure out why the UART itself is giving you problems.

If you can't get a UART going (even without interrupts) then you have bigger problems outside the microcontroller 

[rsjsouza]

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.

Who 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...

Then try to figure out why the UART itself is giving you problems.

If you can't get a UART going (even without interrupts) then you have bigger problems outside the microcontroller 

I 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.

[mac.6]

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)

[Bruce Abbott]

when you need to debug by looking at registers/memory/pointers,

But why do you need to do that?

[Jeroen3]

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.