I have been helping to develop the E-blocks range of hardware at Matrix now for nearly 8 years and in that time I have made many new E-blocks and mods to existing E-blocks to bring up the level of functionality whilst trying to keep complexity to a minimum.
After lots of internal and external discussions we came up with a set of tools designed to allow a user to gain a better understanding of how the system is performing. We captioned this suite of tools as “Ghost Technology” mainly because it doesn’t appear to be there at all in terms of what the user sees when creating and running their programs. The idea is switch it on and it works without needing any changes to your program.
Ghost technology is essentially made up of several key elements:
- The ability to erase and re-program a target Microcontroller device
- The ability to control the execution of code running in the target chip (ICD – In Circuit Debug)
- The ability to monitor the external signals going to and from the target chip (ICT – In Circuit Test)
Currently the only hardware compatible with Ghost Technology is our version 9 EB006 PICmicro Multiprogrammer. Also required is an up to date version of Flowcode 6 which has been updated today (24/03/14 – 6.0.6) to coincide with the launch of Ghost technology.
This block diagram from the EB006 datasheet gives you an overview of the hardware systems in place to allow Ghost to function.
The host device we use to drive Ghost technology is a 16-bit PIC24 device running at a speed of 70 million operations per second. This is then linked to a high speed external RAM device to allow us to store and process large amounts of data as it happens, ready to be passed over to the PC running Flowcode.
Using script based chip profiles we are able to re-program a multitude of different devices using the same core sets of routines. The charge pump hardware allows us to generate the high voltages required by some chips enabling re-programming using only a standard USB supply. By multiplexing the programming pins between the host IC and the E-blocks port we can ensure that whatever you have connected to the E-blocks system will not cause the programming to fail. By using the expansion header it is possible to link the programming signals through to a custom PCB or other third party board. *1
In Circuit Debug (ICD)
Using the powerful Flowcode 6 software we are able to inject debug code directly into the underlying C code generated by your project. This allows you to run, pause and step the program running in the chip just like you are able to do in simulation. The advantage to controlling the code directly in the chip is that you can also gain access to actual internal features such as control registers and variable values to help you sanity check that what happens in simulation is the same as what happens in the hardware. You can also use the same functionality to set the value of a variable or register on board the chip. Again the ICD pins are multiplexed to ensure that connected E-block hardware cannot interfere with the ICD operation and the ICD signals can be passed onto other third party boards. *1
ICD with current icon highlighted
ICD reading and writing variables or registers
Note that when enabling or disabling the ICD mode you have to recompile your program to the chip. This also applies if your program has been modified or if you have changed any breakpoints set to fire during the program.
In Circuit Test (ICT)
Using the Flowcode 6 software we are able to monitor all of the pins on the target microcontroller in both digital and analogue modes of operation. The digital pins are all sampled at the same time at the rate specified in the ICT settings window in Flowcode. Any enabled analogue pins will be sampled in a round robin fashion at the same rate as the digital samples. Once we have collected the pin data it is then possible to perform actions such as decoding a communications bus (UART, SPI, I2C) or convert an analogue value into a meaningful value such as temperature. The scope window in Flowcode allows us to see the signals as they happen and allows decoded data to be overlaid on top of the signal traces. Any decoded data is also made available via the console window to provide a clean textual version of the data. Analogue based components will automatically add a trace to the scope window to allow the signal to be monitored simply. Communications based components also automatically create scope channels with the correct packet decoding structure to allow the signals to be decoded easily. During ICT the Flowcode panels are disabled to help the user understand that the simulation is no longer active. Again the ICT will also work with third party boards by connecting the signals to the expansion header on the EB006. *1
ICT showing analogue traces
ICT showing digital traces with packet decoding
ICT showing data packets
Changing ICT settings does not require a recompile and program like the ICD mode does.
The current maximum sample rate for ICT is 100KHz on all I/O pins which is fast enough to debug most data busses running at low speeds. Note that the main bottleneck for ICT operation is the USB connection so we have compressed the results as much as possible in order to try and increase the data rate. The compression is achieved by only passing values of port pins that have changed since the last sample. If there is a lot going on in your program then the I/O pins are likely to be changing state much more often which will effect the amount of data you can pull through during ICT. We therefore offer an overflow and wrap option which basically allows you to sample until the buffer is filled and then stop or to loop around and carry on sampling at the risk of an occasional data glitch. The additional on-board memory ensures that there is always a large amount of data that can be captured even when there is a lot going on.
In Circuit Debug (ICD) & In Circuit Test (ICT)
The ICD and ICT modes can be ran at the same time to allow you to monitor the hardware as well as control the program execution and read or write values. Note that using ICD and ICT together can occasionally add delays to the ICT sampling routines and so may break the strict timings required by the packet decoding operation. If your experiencing any issues with this then running the data bus at a lower rate or disabling the ICD feature should allow you to decode the bus data packets correctly.
ICD and ICT working together
*1 – The connections between boards will need to be as short as possible to allow the Programming, ICD and ICT to function correctly otherwise transmission line problems start to creep in and cause corruption to the signals.
11,857 total views, 2 views today