GRAYnomad :: debugging

Debugging

The Quub system has support for multi-processor debugging built into the system. It's not an all-singing all-dancing solution, more a simple method of getting information out of the system and onto some form of display device. At the lowest level it just connects a slave processor to the LED on the core board or the QUUBugger so an application program can flash the LED.

To facilitate this the backplane has 4 signals dedicated to debugging, these are known as DBG-00, 01, 02 and 03.

A stackable has a DBGEN signal that is driven by the Stackable Control Chip (SCC), DBGEN should be connected to the enable inputs of one or more transmission gates or other logic that will cause the stackable's debug signals to be in a high-impedance state when DBGEN is low and allow them to be connected to the debug bus when DBGEN is high.

Of the 4 available debug signals a stackable will normally only use DBG-00 and/or DBG-01 with DBG-02/03 being intended for use by the core processor at this point.

DBG-00 - This is the most fundamental signal, it is connected to the LED on the core processor board (and also a LED on the QUUBugger) and can be used by any slave processor to indicate information on the LED.

DBG-01 - This signal is used in conjunction with DBG-01 to form a bi-directional high-speed synchronous link between any slave processor and a QUUBugger.

DBG-02/03 - These two signals are used to form a bi-directional high-speed synchronous link between the core processor and the QUUBugger. This connection is used to control slave access to the debug bus and to communicate with the QUUBmon running on the core processor.

QUUBmon

QUUBmon is an absolute bare bones monitor, it can only read from and write to IO, memory and registers (but then what else is there).

QUUBmon is designed to have an extremely small footprint, to be as nonintrusive and to use as few host resources as possible, to this end it...

Is written in assembler.

Sits on the watchdog interrupt.

Handles all commands atomically within the watchdog ISR.

Communicates with the application code through a shared memory space.

The writing of QUUBmon is a fair way off yet, but with it and the QUUBugger tool (below) it should be possible to get live views of system data and registers on a PC screen, even if the application program has crashed (obviously this depends on the severity and nature of the crash).

Also a GUI application running on the PC will have access to the MAP file and as such should be able to work with the program's symbols.

Some debugging examples

In the first example we see a very simple setup whereby both stackables have access to the LED on the core processor board. As this is a one-way communication the stackables are connected to the debug bus with simple tri-state buffer, this buffer is enabled with a DBGEN signal that originates from whatever mechanism make sense, jumper, dip switch, or an output from the slave processor.

Note: While possible, using an output from a slave processor as the DBGEN signal is discouraged due to the chance of a rogue processor overriding the debug bus.

While very rudimentary just having access to a single LED is a very useful debugging tool.

In the next example we have a similar arrangement, however this time the outputs from the slave processors are connected to a Sparkfun serial 4-digit LED display. Simple as this system is it allows any processor in the system to display a 16-bit value while using almost no system resources, and that is a hugely useful debugging tool.

This third example shows a system where all processors are running QUUBmon as a background monitor.

QUUBmon uses a high-speed synchronous comms link to talk to the QUUBugger and ties up only two general-purpose IO pins. It uses the watchdog interrupt (that is seldom used by applications) and is therefore relatively immune to application crashes; as long at this interrupt hasn't been disabled QUUBmon will continue to run and can be used to report on system variables such as the data on the stack (addresses and local variables) or the values of global variables.

All slave processors have their debug connection controlled by SCCs and these are under the control of the core processor and therefore by the PC application via the DBG-02/03 signals (the blue link).

ION prototype board

To aid the development of IONs a prototyping board has been designed. This board has the control logic required to implement an ION based on the ATtiny85 processor. It also has a large PTH prototyping area and because many modern sensors are not available in PTH packages several SMD pad sites that are broken out to the .1" grid.

This board has the following features.

4 mounting posts to connect external signals.

3 SOT23 sites with pins broken out to .1" grid.

2 SOIC (one 8 and one 16 pin) sites with pins broken out to .1" grid.

An ATtiny85 to be used as the ION processor.

All 6 processor IO pins broken out to a socket.

Status LED.

3-pin GVS header.

QUUBugger

The QUUBugger is a simple board that plugs directly into the Quub backplane and connects to the DBG-00:03 signals. It also monitors the three power rails on the backplane, can reset either the whole stack or just the board being developed, and talks USB to a PC and so can be used to interface all QUUBmons running on any system processor to a monitor program running on the PC.

For more information go to the QUUBugger section.

		Debugging
		The Quub system has support for multi-processor debugging built into the system. It's not an all-singing all-dancing solution, more a simple method of getting information out of the system and onto some form of display device. At the lowest level it just connects a slave processor to the LED on the core board or the QUUBugger so an application program can flash the LED. To facilitate this the backplane has 4 signals dedicated to debugging, these are known as DBG-00, 01, 02 and 03. A stackable has a DBGEN signal that is driven by the Stackable Control Chip (SCC), DBGEN should be connected to the enable inputs of one or more transmission gates or other logic that will cause the stackable's debug signals to be in a high-impedance state when DBGEN is low and allow them to be connected to the debug bus when DBGEN is high. Of the 4 available debug signals a stackable will normally only use DBG-00 and/or DBG-01 with DBG-02/03 being intended for use by the core processor at this point. DBG-00 - This is the most fundamental signal, it is connected to the LED on the core processor board (and also a LED on the QUUBugger) and can be used by any slave processor to indicate information on the LED. DBG-01 - This signal is used in conjunction with DBG-01 to form a bi-directional high-speed synchronous link between any slave processor and a QUUBugger. DBG-02/03 - These two signals are used to form a bi-directional high-speed synchronous link between the core processor and the QUUBugger. This connection is used to control slave access to the debug bus and to communicate with the QUUBmon running on the core processor.
		QUUBmon
		QUUBmon is an absolute bare bones monitor, it can only read from and write to IO, memory and registers (but then what else is there). QUUBmon is designed to have an extremely small footprint, to be as nonintrusive and to use as few host resources as possible, to this end it... Is written in assembler. Sits on the watchdog interrupt. Handles all commands atomically within the watchdog ISR. Communicates with the application code through a shared memory space. The writing of QUUBmon is a fair way off yet, but with it and the QUUBugger tool (below) it should be possible to get live views of system data and registers on a PC screen, even if the application program has crashed (obviously this depends on the severity and nature of the crash). Also a GUI application running on the PC will have access to the MAP file and as such should be able to work with the program's symbols.
		Some debugging examples
		In the first example we see a very simple setup whereby both stackables have access to the LED on the core processor board. As this is a one-way communication the stackables are connected to the debug bus with simple tri-state buffer, this buffer is enabled with a DBGEN signal that originates from whatever mechanism make sense, jumper, dip switch, or an output from the slave processor. Note: While possible, using an output from a slave processor as the DBGEN signal is discouraged due to the chance of a rogue processor overriding the debug bus. While very rudimentary just having access to a single LED is a very useful debugging tool. In the next example we have a similar arrangement, however this time the outputs from the slave processors are connected to a Sparkfun serial 4-digit LED display. Simple as this system is it allows any processor in the system to display a 16-bit value while using almost no system resources, and that is a hugely useful debugging tool. This third example shows a system where all processors are running QUUBmon as a background monitor. QUUBmon uses a high-speed synchronous comms link to talk to the QUUBugger and ties up only two general-purpose IO pins. It uses the watchdog interrupt (that is seldom used by applications) and is therefore relatively immune to application crashes; as long at this interrupt hasn't been disabled QUUBmon will continue to run and can be used to report on system variables such as the data on the stack (addresses and local variables) or the values of global variables. All slave processors have their debug connection controlled by SCCs and these are under the control of the core processor and therefore by the PC application via the DBG-02/03 signals (the blue link).
		ION prototype board
		To aid the development of IONs a prototyping board has been designed. This board has the control logic required to implement an ION based on the ATtiny85 processor. It also has a large PTH prototyping area and because many modern sensors are not available in PTH packages several SMD pad sites that are broken out to the .1" grid. This board has the following features. 4 mounting posts to connect external signals. 3 SOT23 sites with pins broken out to .1" grid. 2 SOIC (one 8 and one 16 pin) sites with pins broken out to .1" grid. An ATtiny85 to be used as the ION processor. All 6 processor IO pins broken out to a socket. Status LED. 3-pin GVS header.
		QUUBugger
		The QUUBugger is a simple board that plugs directly into the Quub backplane and connects to the DBG-00:03 signals. It also monitors the three power rails on the backplane, can reset either the whole stack or just the board being developed, and talks USB to a PC and so can be used to interface all QUUBmons running on any system processor to a monitor program running on the PC. For more information go to the QUUBugger section.