LED indicator for software debugging :)

Go To Last Post
46 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello, iv been working on my biggest project ever (600 lines of C' source code) with lots of functions.

I have an intermittent problem with program lockup in a certain part of my code after the MCU wakes up from hardware sleep mode via a pin change interrupt.

I have a sleep cycle function that handles powering down and doing house keeping when woken up.

 

I disable global interrupts right after sleep mode as my on/off button is software debounced only, the button ringing was causing the ISR to be called rapidly which i think was causing me some issues.

After all interrupts are disabled then i disable that pin change interrupt mask, only needed for waking up from sleep mode.

 

Anyways, iv been working away at removing my bug and I finally had the idea to at the end of functions or code portions to turn an led off to indicated the function was complete.

Using my new onboard tool to help me find bugs and clear sections of code. The atmel simulator helps me immensely, but it cant help me solve all my problems.

I do not yet have an ICE tool, but this simple LED indicator to help me test around my code was a light bulb moment for me. 

 

 

~William

Last Edited: Tue. Mar 13, 2018 - 06:35 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

If there is a question in your post, I missed it.

Greg Muth

Portland, OR, US

Xplained/Pro/Mini Boards mostly

 

Make Xmega Great Again!

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

vertamps wrote:
I do not yet have an ICE tool, but this simple LED indicator to help me test around my code was a light bulb moment for me. 

 I guess we should nickname you Edison then!  Congratulations, often times the simplest solutions are the most easily overlooked.  Good luck with your bug hunting.
 

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No question, just a long intro intro into me discovering using an led indication to help debug my code.

I could shorten it.

~William

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Greg_Muth wrote:

If there is a question in your post, I missed it.

No question, a light turned on in the attic!

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

vertamps wrote:

No question, just a long intro intro into me discovering using an led indication to help debug my code.

I could shorten it.

What, and ruin a moment of brilliance?  Don't do that.

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I have included a spare LED on most pcb's I have designed for many years, handy for debugging and once in production can be used for many purposes.  (heart beat, etc..)

In most Arduino boards, D13 will light a spare LED which can be used for this purpose....

 

 

Jim

 

Click Link: Get Free Stock: Retire early!

share.robinhood.com/jamesc3274

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks Larry, I am sure the idea will pay for itself soon enough.

~William

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've got a 28-pin IC test clip, a bit like this...

 

 

...with 8 LEDs and series resistors on it to give 'blinky-lights' debug access to a port's worth of bits.

#1 This forum helps those that help themselves

#2 All grounds are not created equal

#3 How have you proved that your chip is running at xxMHz?

#4 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've got a 28-pin IC test clip, a bit like this...

If there's a photo in there, I don't see it.

 

I assume you mean something like this?:

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A serial port is great for "non-ICE" debugging, too.

 

An old trick, for events too fast to see by eye with blinkenlichts, is to connect an output pin to a speaker.

As code execution is often cyclic, a distinctive sound could be heard ...

 

EDIT

 

typo

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Tue. Mar 13, 2018 - 08:11 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ki0bk wrote:
I have included a spare LED on most pcb's I have designed for many years, handy for debugging and once in production can be used for many purposes. (heart beat, etc..)

I also do this now with every design. One of the many things I have learned from the fellow 'Freaks here. Even if I don't populate it, it's there if I need it.

My digital portfolio: www.jamisonjerving.com

My game company: www.polygonbyte.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yep, a LED and Morse code are invaluable for debugging. devil

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The LED companies probably love us.

 

For peace of mind, design in our new line of LEDS. 

Additionally consider our $9.99/mo protection plan that assures quick, professional replenishment of any defective LED. 

If you're approved for this plan, we'll automatically bill you each month.  

When in the dark remember-the future looks brighter than ever.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

joeymorin wrote:

If there's a photo in there, I don't see it.

 

Odd. I see my photo OK on both desktop (Opera) and mobile (Chrome).

#1 This forum helps those that help themselves

#2 All grounds are not created equal

#3 How have you proved that your chip is running at xxMHz?

#4 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

One of the biggest problems (IMO) with deeply embedded systems is that if your code is careful and does all that modern-ish "range checking" and so on, and it detects an error ... there is no good way to report that error, and it's pretty ambiguous what you should DO.  Recently I've been thinking that Arduino-class boards should have an extra on-board "error" LED, so that if you do something stupid that is easily detected (say, "analogRead" from a pin that doesn't have analog capability), you can light up the LED to say "core error detected."   It's not much, but it's a lot better than "it isn't doing what I expected, and I have no idea why."

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You must have added it from a site that my system blocks...?

 

Hmm... nope... even more interesting... I found the link to the image by looking at the html source:

https://www.avrfreaks.net/sites/default/files/923690-14.jpg

When I put that into a new browser tab, I get:

 

I pulled it with wget, and attempting to view/edit it in any jpg-supporting application (including Firefox) gives me similar results... >>except<< Chromium.

 

A  peek with the 'file' command:

$ file -k 923690-14.jpg 
923690-14.jpg: RIFF (little-endian) data, Web/P image, VP8 encoding, 640x640, Scaling: [none]x[none], YUV color, decoders should clamp\012- data

So it's a WebP image, not a JPEG image, which is (still) not supported by Firefox, IE, or Safari.

 

Here's the same image in JPEG format (found via tineye.com):

http://icimges.tuluo.net/dk/415477_923690-14.jpg

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks joeymorin, I couldn't see it either...

David (aka frog_jr)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

joeymorin wrote:
So it's a WebP image, not a JPEG image, which is (still) not supported by Firefox, IE, or Safari.

, or Edge.

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

westfw wrote:
One of the biggest problems (IMO) with deeply embedded systems is that if your code is careful and does all that modern-ish "range checking" and so on, and it detects an error ... there is no good way to report that error, and it's pretty ambiguous what you should DO.
assert

The Ganssle Group logo

The Ganssle Group

Adding Automatic Debugging to Firmware for Embedded Systems

by Jack Ganssle

May, 2014

http://www.ganssle.com/dbc.htm

(mid-page)

Assertions as Contracts

...

Gimpel Software

Gimpel Software

PC-lint/FlexeLint Value Tracking

The assert() remedy

http://www.gimpel.com/html/value.htm#assert

P.S.

Some zero price lint have common checks :

https://docs.microsoft.com/en-us/visualstudio/code-quality/c6029

via

https://docs.microsoft.com/en-us/visualstudio/code-quality/code-analysis-for-c-cpp-warnings

and

Microsoft Docs

-analyze (Code Analysis)

https://docs.microsoft.com/en-us/cpp/build/reference/analyze-code-analysis

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Vertamps Edison, the brightest light in the Universe.smiley

 

Blinking a led is among the most primitive (but still usefull) debugging techniques around.

Every project should start with a blinking led.

Other very imple techniques are dumping info on a LCD or writing serial output to a serial terminal.

If you combine that with a "pretty affordable" Logic Analyser (Search: "24m 8ch" on Ali / Ebay) and Sigrok you get micro second accuracy timing with your debug data.

I have formalized this a bit and wrote a pretty simple debugging library.

With this library you can use different AVR pins for different parts of your program.

I use it for example to spit out Debug data for some interrupts on one pin, and other debug data on another pin. Using 3 or 4 AVR pins for this debug data is not uncommon.

Using different pins makes it very easy to spot on your Logic Analyser when your interrupts fired, or where other interesting things are happening.

The USD 5 for such a LA was the best electronics investment I ever did.

The USD 5 LA is often (not always) more usefull for debugging code than an USD 300 Digital Scope.

Usage information is in the comment in the "debug.h" file.

Attachment(s): 

Paul van der Hoeven.
Bunch of old projects with AVR's:
http://www.hoevendesign.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Paulvdh wrote:
Using different pins makes it very easy to spot on your Logic Analyser when your interrupts fired, or where other interesting things are happening.

Embedded

Troubleshooting real-time software issues using a logic analyzer

by David B. Stewart, PhD, InHand Electronics, Inc.

February 27, 2012

https://www.embedded.com/design/debug-and-optimization/4236800/Troubleshooting-real-time-software-issues-using-a-logic-analyzer

 

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

IE 11 - can't see pic

Brave 0.20.42 - can see pic

Waterfox 55.2.2 (the one I actually use) - can see pic

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Blinking a led is among the most primitive

OK, I'm a dinosaur..., (or should that be caveman?)

 

I always debug with an LED, and often with an LCD or a serial port.

 

I try to "reserve" the USART pins for a serial output option if they are not a primary part of a project.

 

I have a couple of LCD's with serial backpacks that just run a simple terminal program to display data dumps, when needed.

 

Uncle Bob used to always debug via a USART and a PC "menu" to test his various routines.

 

JS tried to teach me how to debug with a Dragon when we were working with some early Xmega chips.

I think that is when he totally gave up, through in the towel, and retired!

 

JC

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If it's not time/energy critical, and you don't have a spare LED or serial, it's still possible to store data in EEPROM. It can be a counter that changes after each program section has been executed.

Also, different types of activities usually have easy to recognise `signatures' on current consumption graph. Often you can make a good suggestion of what went wrong by just looking at recorded current consumption.

 


Qoitech AB, The Home of Otii Arc, an SMU for every developer

Check out Otii solution at www.qoitech.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yabusame wrote:

If it's not time/energy critical, and you don't have a spare LED or serial, it's still possible to store data in EEPROM. It can be a counter that changes after each program section has been executed.

 

But how do you convey that information to the person debugging?

#1 This forum helps those that help themselves

#2 All grounds are not created equal

#3 How have you proved that your chip is running at xxMHz?

#4 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yabusame wrote:
store data in EEPROM.

Doesn't have to be EEPROM.

 

If you have spare RAM, a circular "trace buffer" can be invaluable.

 

But, as Brian says, you need some way to read it out!

 

Usually (?), that would be with a debugger (which the OP doesn't have); but it could be a serial port, or any other convenient interface.

 

I have done it in the past over a GSM interface - giving a kind of remote debugging...

 

 

Also, different types of activities usually have easy to recognise `signatures' on current consumption graph

Very true, although this requires an oscilloscope to see.

 

If you have a 'scope, then you can get over the LED's speed limitation and view much faster information by toggling a pin or pins ..

 

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:
But, as Brian says, you need some way to read it out!
If it's EEPROM you just use your ISP programmer to read it. Not possible to use ISP if it's data in RAM though (AFAIK).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
If it's EEPROM you just use your ISP programmer to read it.

Good point.

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I know it's a technique that Lee often suggests so like so many things there's nothing new under the Sun !

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

EEPROM is a bit AVR-specific, but the RAM buffer is general.

 

there's nothing new under the Sun

Indeed.

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 2

Different tools fit best for different kind of problems.

The EEmem trick could work wel for some unattended battery powered gadged which inexpliably resets itself once a month in a desert (or something...).

I usually start with a blinking led for new projects.

I love my own little simplistic debug lib from #21. Just read the embedded article from #22. It is pretty similar from my little debug lib. Main difference is that David B. Stewart uses an 8-bit parrralel output design, while I use serial outputs on different pins.

I found that using different pins helps a lot with pin pointing possible errors.

I tend to use a pin exclusively for interrupts, so I know exactly when all interrupts fired.

The example I have here is not the best example, but just a capture I happen to have open at the time.

Tx = UART Tx line

Rx= UART Rx line.

RS485 Enable line.

Idle = toggle a pin whole day when the uC has notthing better to do.

Intrpt = Debug info of the several different UART interrupts.

You can see here that the UART Transmits 3 packets and receives 2 packets.

 

 

Now zoom in a bit:

You can see from "Idle" that my ATmega needs 180us to prepare a packet.

The "Intrput" trace is a bit messy because it has more information tan just from the interrupt. Call it a sort of multiplexing.

The UART data rate  here is 115k2. The Red top trace is decoded data from the Tx trace (Black label).

You can easily see that an interrupt is fired during transmission of each byte of the packet (First is a bit special, part of the "multiplexing" Wont go into that now).

When I zoom in a lot further on one of the interrupts I see the decoded data of the "Intrpt" trace in the lowest yellow "UART"

Look at the size of that byte compared to the Start bit of the 115k2 data stream on top.

This uC has a 11.0592MHz Crystal and the Debug data is spit out at 1/2 of that, so 5.5Mbps.

This means you can use a LOT of debug statements before ithas a significant infuence on the timing of your code.

The 0x60 can be easily correlated to the code.

Here is the interrupt routine's source code:

ISR (USART_UDRE_vect) {
/* Uart Data Register Empty interrupt routine.
Sends the Next byte of A Packet to the UART. If the last bye is put in UDR
this interrupt disables itself and enables the transmission complete interrupt
to clean up. */

	UDR = *pTxd;									DEBUG( 0x60);
	TxDBytes--;				// A byte has been transmitted, so decrement...
	pTxd++;
	if( ! TxDBytes) {								DEBUG( 0x61);
		// If the last byte has been send.
		UCSRB &= ~(1<<UDRIE);	// Then I'm finished and disable myself.
		// Bug: Clear interrupt flag for txcie before enabling interrupt?
		UCSRB |=  (1<<TXCIE);	// Transmission complete interrupt takes over.
	}
}

Note that I put the DEBUG() statements near the right margin. This has 2 big advantages.

1). I have a nice overview of where all the debug statements are in the code.

2). If you don't need them you don't see them. They do not interfere with normal program writing. The do not consume text lines.

This last is expecally handy in some of my more complicated interrupts. The RxC interrupt has 12 debug statements, 0x70 through 0x7f at the end (some omitted).

 

Now look at the first screenshot again. Near the end of the packet you see a wider squiggle, and the last UART byte does not trigger an interrupt. Zoom in a bit.

(I removed some channels.)

Not much to see, Zoom in more:

0x60 and 0x61 are both being written in the same UDRE interrupt. 0x61 means the interrupt has written the last byte of a packet to the UART Data registers.

It then disables itself, and enables the Transmission complete interrupt, as you can see in the code snippet above.

This is the result at the end of the packet.

The Transmission Complete interrupt frees up the RS485 driver and spits out 0x50 to show it has been triggered.

 

 

And this is only a small bit of the magic you can do with Open Source software and an USD 5 Logic Analyser (Search 24m 8ch, or any CY7C68013A development board on Ali / Ebay).

https://sigrok.org/wiki/Supported_hardware#Logic_analyzers

"better hardware" can do faster sampling rates. But I haven't had a use for that yet. This USD5 box is good enough to capture low-speed USB. (And Pulseview has decoders for that).

 

Everything put together:

This is why I call blinking a LED primitive.

 

Last a code snippet from the Rx interrupt with plenty of debug statements.

(Remember that I can En/Dis - able them with a single line of code & a recompile).

The LA helped tremendously in debugging & verifying every if statement and goto of the execution path in this heavily optimized interrupt routine.

#if defined ( USART_RXC_vect)
ISR ( USART_RXC_vect)
#else
ISR ( USART_RX_vect)
#endif
{											DEBUG( 0x70);
/* Uart Received a Byte Interrupt.
This interrupt routine does the minimum processing needed to
receive 1 complete Packet. This includes:
1). Synchronization on the first byte an incoming Packet. (MPCM mode).
2). Reject & restart on unwanted packets.
3). Reject & restart on errors. (data overrun).
4). Reject & restart if an incoming packet is bigger than this node is
	confgured to handle.
5). Storing of the Packet where it has been pointed to by
		ReceiverEnable( )
6). Receiver shuts itself down after a complete packet is received.

Notes:
- Do not use ISR_NOBLOCK. UDR is double buffered.
- There is no timeout checking. If a Received Packet is to short, the
	startbyte of the Next Packet will generate an error and the receiver will
	try to synchronize on the 3rd packet. The second packet is then lost.
	Bug: Also restart on unexpected received start byte's? 2015-01-04. */
	static uint8_t DestAddressLowByte;
	uint8_t Usr = UCSRA;	// UCSRA must be read before UDR
	uint8_t Udr = UDR;		// Read UDR once (buffering).

	if( Usr & (1 << DOR)) {								DEBUG( 0x71);
		// Data Overrun Error. Current packet is corrupt.
RxRestart:
		pRxd = pPacketIn;	// Restart for the next packet.
		UCSRA = 1<<MPCM;
		RxDState = RXDHDB0;
		return;
	}
	if( RxDState == RXDHDB0) {							DEBUG( 0x72);
		DestAddressLowByte = Udr;	// Save it for later.
		UCSRA = 0;					// Clear MPCM to receive the rest of the packet.
	}
	else if( RxDState == RXDHDB1) {							DEBUG( 0x73);
		/* Received first 2 bytes, which is a complete destination address.
		Now we can decide whether we want this packet or not. */
		if(  ( Udr == NODE_ADDRESS_HI8)
		   &&( DestAddressLowByte == NODE_ADDRESS_LO8) ) {		        DEBUG( 0x74);
			/* We are being addressed. Just keep on receiving. */
		}
#if WANT_BROADCASTS
		else if( Udr == 0x00) {							DEBUG( 0x75);
			/* It is a broadcast and we want boadcasts.
			Just keep on receiving. */
		}
#endif // WANT_BROADCASTS
#if RECEIVE_RANGE
		else if( Udr == RECEIVE_RANGE) {					DEBUG( 0x76);
			/* Receive Range address match. Keep on receiving. */
		}
#endif // RECEIVE_RANGE
		else {
			/* This packet is not for us. Restart Receiver. */	        DEBUG( 0x77);
			goto RxRestart;
		}
	}
	else if( RxDState == RXDHDB5) {							DEBUG( 0x78);
		/* This byte has the PacketSize. Read it to determine how much bytes
		we want before shutting down. */
		if( Udr > MUMAR_MAX_DATA_SIZE) {					DEBUG( 0x79);
			/* Can not receive this packet because it is to big.
			Restart for the next packet. */
			goto RxRestart;
		}
		// +1 Because RxDState is always decrement at the end.
		RxDState = MUMAR_CHECKSUM_SIZE + Udr + 1;
	}
	else if( RxDState == RXDLASTBYTE){ 						DEBUG( 0x7a);
		// This is the last byte of the Packet. Do some cleanup.
		UCSRB &= ~(1<<RXCIE);		// Disable receiver interrupt
		*pRxd = Udr;
		RxDState = RXDPACKETREADY;
		return;			// Finished.
	}
	// We returned on all errors, we only come here if there's data to store.
	*pRxd = Udr;		/* Store this byte.*/					DEBUG( 0x7f);
	pRxd++;
	RxDState--;			// Keep the ByteCounter up to date.
}

A LA is still a magic tool for me for debugging software, but it is not an all enevoping tool.

But in some ways it is superior to an ICE.  With an LA you can easily spit out internal variables through any otherwize unused peripheral UART, SPI, PWM, I2C (no Ack bit!). and it has a very low impact on timing. If you set a breakpoint or step through your code with an ICE all timing is lost. The LA preserves all relative timing and you can look back in the past what happened and what code was executed before your bug manifested itself. Note how nicely the debug code from the interrupts lines up with the start bits of the RS485 data. This can help tremenously in identifieing all kinds of timing issues.

Last I've put a "Timing" trace on the "idle" toggle pin. which is toggled each time the uC goes through its for( ;;) loop in main().

While idle it needs 21.8us to do it's thing. When an interrupt fires the timing increases to 29.5 or 31.4us in the example below.

This means that the total excecution time of an interrupt, inclusive all interrupt entry overhead and the debug info overhead ( 1.7us/byte) can easily be calculated

29.5-21.8= 7.7us for the first interrupt.

31.4-21.8= 9.6us for the second interrupt.

 

Paul van der Hoeven.
Bunch of old projects with AVR's:
http://www.hoevendesign.com

Last Edited: Wed. Mar 14, 2018 - 06:23 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That's pretty cool debugging...looks like I need to find pulseview(?).  Seems to really beat using a scope

When in the dark remember-the future looks brighter than ever.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Paulvdh wrote:
Different tools fit best for different kind of problems.

Indeed.

 

 

But the most important tool of all is the one between your ears ...

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Not possible to use ISP if it's data in RAM though (AFAIK).
PDI and UPDI have load and store instructions that can access data space.

In AVRDUDE via "Terminal Mode Operation" dump and write (about halfway into the manual)

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Paulvdh wrote:
Note that I put the DEBUG() statements near the right margin.
In MPLAB X, the trace and log macros are on the next line :

via

Microchip

Developer

How Instrumented Trace Works

http://microchipdeveloper.com/realice:user-instrumented-trace-works

though not via a 5USD logic analyzer wink

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:
That's pretty cool debugging...looks like I need to find pulseview(?). Seems to really beat using a scope
Absolutely. For an oscilloscope the front panel with all the buttons are a very important part of the user interface. An Oscilloscope is not "comfortable" to work with if you have a keyboard & mouse as input.

 

But for a Logic Analyser a standard computer interface is a very good fit.

For this demo I made the program a bit smaller, usually I use the full 1920 pixels width of my screen.

Then you get the tremendous zoom of the Logic Analyser software. A zoom factor of 1:1.000.000 is no exception.

Zooming works with the scroll wheel of the mouse and the "center" of zoom is always on the mouse cursor.

This will work pretty much the same for most PC based LA software I guess.

A few static screenshots can not do justice to the ease in which you can zoom in and out fast with a scrollwheel.

If you have to do this on a stand alone Logic analyzer it easily becomes 'Fiddling with knobs" and a bit distracting from the actual signal analysis.

With the scroll wheel it is so intuitive you can stay fully focused on the debugging and signals themself.

The Salaea software is slightly better at "scrolling", but I compensate for that by never scrolling at all in Pulseview.

I usually zoom out on the left side on the screen, move the mouse to the right, and zoom in there.

After a bit of getting used to it comes quite natural.

 

@gchapman: I see no reference that those __LOG() should stay in the left. C source code is usually fair game for coding styles.

http://microchipdeveloper.com/realice:user-instrumented-trace-works wrote:
you can report program locations or variable values to MPLAB X IDE while the application is running and examine them via the Trace window once the application halts.
How does this compare with the fine grained timing you get from a LA trace? For example you can easily see that the UDRE interrupt is triggered and writes the next byte to the Uart Data register as soon as the start bit of the previous byte is being shifted out.

Paul van der Hoeven.
Bunch of old projects with AVR's:
http://www.hoevendesign.com

Last Edited: Wed. Mar 14, 2018 - 06:42 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Paulvdh wrote:
I see no reference that those __LOG() should stay in the left

Likewise.

 

I see your logic in putting your DEBUG stuff at the right margin - but having it at the left just seems to mess-up the indentation  structure entirely!

 

 

C source code is usually fair game for coding styles.

Indeed.

 

One of the first things the preprocessor does is collapse all the whitespace!

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Paulvdh wrote:
How does this compare with the fine grained timing you get from a LA trace?
Less precision due to

  • Interrupts are disabled during LOG and TRACE
  • Communication speed (PGC/PGD, SPI, 8-bit port)

http://microchipdeveloper.com/realice:user-instrumented-trace-types

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@gchapman.

I want to (sligtly) apologize.

It is not entirely fair to pick out one small part out of a complete system, and then only compare that part with another system.

Logic Analysers excell in high resolution timing and timing relationships between different signals and it his hard to beat them at that point.

For that you need an extra hardware box, and separate wires to connect to your system, and you have to install & get used to the software for it.

In the embedded article you quote in #22 it is suggested to build in an extra connector for comfortable access to some pins to use for debugging with an LA.

 

I have heard that the MPLAB (X ? ) software sort of works under Linux, but is buggy there. I never tried it.

Every now and then I had an urge to buy some debugging tool for the AVR's I use.

At one point I almost bought the Dragon. The only thing holding me back were the (too many) reports of the Dragon failing, due to a badly designed power supply in the first batch of Dragons.

 

But I do know that ever since I started using my litte LA for debugging software the feeling of "poking in the dark" went away. The insight I gained with it was so big that I was just happy with the tools I have and I did not feel a wish for better tools anymore.

 

It would be fun to read an in depth review / comparison of the pro's and con's of debugging with a Logic Analyser versus MPLAB X or ATATMEL ICE. But because either solution would need hardware which is at least 10x the price of a USD 5 logic analyser and Atmel / Microchip does not (to my knowledge) have a high priority in making their tools work under Linux with the same "user experience" as under some other OS it is unlikely that I will make that comparison.

 

With the screenshots here I have merely given a short presentation on how a LA can be used with a bit of inline debugging code to follow the real-time execution path of a small embedded system such as an AVR. I hope it wil insprie others to add this tool to their toolbox.

Paul van der Hoeven.
Bunch of old projects with AVR's:
http://www.hoevendesign.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 2

Just stopping by to show and tell that i found my bug. I have a counter variable in an Interrupt for cycling a PWM sine array.

That interrupt and PWM output needs to be active in order to count the array back to zero as part of my conditional to exit a while loop when pausing the sine output.

That interrupt was not active and so i was stuck in a loop inside my function that waits for the PWM sine array to be at zero point as far as an AC signal is concerned. 

When shutting down an amplifier ic that gets fed two combined sine waves I wanted to shut off the sinewaves at the zero point so a low frequency transducer/speaker

does not have a harsh spike from shutting off from a peak. Just a little extra spit at shine on the project im working on.

   

~William

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

assert

assert is great for standardized error checking, but it doesn't really provide any hints on what to do with the fact that you have an error, and the more detailed info about the error.   Even if there is a spare UART for printf(), it might not be connected to anything, and there might not be anyone watching.  Assuming that your device has room for printf in the first place.  (Heh.  A lot of Arduino Sketches get 12k smaller if you remove the (useless?) printf() from _exit() - https://github.com/arduino/Ardui... )

 

It might be neat to add functionality to the bootloader (or to the pc-side that uses it) retrieve a special "debugging area" of RAM/etc after it does a reset and before it starts writing new memory...

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You're welcome; I was not perturbed and quite the contrary as your long read posts are a different take on why and how to operate a logic analyzer.

Paulvdh wrote:
Logic Analysers excell in high resolution timing and timing relationships between different signals and it his hard to beat them at that point.
What's "better" is instruction trace but that's only on some 32-bit MCU; I'm not aware of instruction trace being a part of any 8-bit or 16-bit MCU.

16-bit MPU Z8000 had instruction trace via the emulator pod that would sit on top of the enclosure; today, that capability is a part of some MPU and MCU.

Some applications need instruction trace for bench tests, lab tests, object code verification, and maybe qualification testing; wouldn't be feasible for verification and validation testing (environment chambers, vehtronics, avionics, etc)

Paulvdh wrote:
In the embedded article you quote in #22 it is suggested to build in an extra connector for comfortable access to some pins to use for debugging with an LA.
That's handy though even that might not make product manufacturing.

Hopefully, at least there are pads on the PCB for such.

The logic analyzer manufacturers do make it easy to connect their products.

Paulvdh wrote:
The only thing holding me back were the (too many) reports of the Dragon failing, due to a badly designed power supply in the first batch of Dragons.
Power the AVR Dragon from a self-powered USB hub to prevent USB VBUS brownout, add DragonLair, enclose it.

Some see value in AVR Dragon, Microchip continues making more, and it can do HVSP (Atmel-ICE cannot do a 12V reset signal, IIRC Power Debugger can)

An Atmel-ICE would be "better" than an AVR Dragon especially for some AVR (PDI for XMEGA AVR, UPDI for later model tinyAVR and megaAVR, AVR data space via PDI and UPDI)

Hopefully the Atmel-ICE sales at microchipDIRECT will continue to be somewhat periodic.

If don't need a UPDI debugger then there's pyupdi (Python UPDI) and El Tangas's STK500 UPDI.

Maybe someone will create a pypdi because there's a sigrok PDI decoder.

 


Saleae

Saleae

Logic Accessories

https://www.saleae.com/accessories

...

 

Logic-to-2x4 Header (Gen 2)
Build Logic support right into your next PCB. Just design in a 2x8 IDE header (2.54mm/.100in pitch) and use it with this cable. 9in (23cm) length. Features ultra-flexible wire.
Works with: Logic 4, Logic 8, Logic Pro 8, Logic Pro 16 (Generation 2)

 

...

Dragon

http://aplomb.nl/TechStuff/Dragon/Dragon.html

...

DragonLair

...

http://www.microchip.com/developmenttools/productdetails.aspx?partno=atavrdragon

http://www.microchip.com/developmenttools/productdetails.aspx?partno=atatmel-ice

https://github.com/mraardvark/pyupdi/

https://www.avrfreaks.net/forum/stk500-updi-working-was-enabling-xtiny-updi

https://sigrok.org/wiki/Protocol_decoder:Avr_pdi

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

Also, different types of activities usually have easy to recognise `signatures' on current consumption graph

Very true, although this requires an oscilloscope to see.

 

If you have a 'scope, then you can get over the LED's speed limitation and view much faster information by toggling a pin or pins ..

 

 Or a combination of printf-style debugging over UART and power graph, just like Otii does:

 

https://www.qoitech.com/blog/synchronizing-debug-logs-power-consumption

 

 Although unable not replace a scope or logic analyser, it offers a unique possibility to align messages sent by DUT with recorded current consumption. At least, I couldn't find anything similar that works out-of-the-box even in high end DMMs/SMUs.

 


Qoitech AB, The Home of Otii Arc, an SMU for every developer

Check out Otii solution at www.qoitech.com

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 2

larryvc wrote:

vertamps wrote:
was a light bulb moment for me. 

 I guess we should nickname you Edison then!  Congratulations, often times the simplest solutions are the most easily overlooked.  Good luck with your bug hunting.
 

Or Swan, maybe.

Quebracho seems to be the hardest wood.