AVR Freaks

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

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?:

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.

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.  

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

assert

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

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

 

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

 

 

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

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

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

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.

 

[Edit=2019-01-23] I link to this post a lot to promote the use of LA's in general and the Open Sorce Sigrok / Pulseview combination in particular, Open source packages do not have a marketing division, nor any budget to advertise in magazines.

 

Also: The debug output in this post is generated from debug.h, which I attached in post #21 [/Edit]

Indeed.

 

 

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

 

https://sigrok.org/wiki/PulseView

 

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.

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.

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

 

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.

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)

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.

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

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