Debugging MCU Code

Debugging

Of course it' i possible to develop a debug embedded applications with none special development and debugging tools, you just need how to download the program to the microcontroller and then debug it. Within the beginnings of microcontroller software development, which suggests the 70’s and early 80’s, this often was the tactic of choice: Debugging tools were rare, tools for different architectures often nonexistent. In consequence, the program was often developed on paper, burned into an EPROM, and then tested on the target hardware. Debugging, unavoidable in complex applications, was either through with external measurement equipment like logic analyzers, or realized through more or less creative use of the output elements on the target. as an example, targets generally contained some LEDs for status output, which were used for debug output during the debugging phase. Through them, the engineer visualized the program flow, indicating if and within which order the program reached certain memory addresses.

Since programming an EPROM took plenty of it slow, so-called ROM emulators resp. EPROM emulators were employed; these consisted of a RAM of the identical size, which used some additional logic to simulate the behavior of the ROM resp. EPROM within the target hardware, but was at the identical time externally accessible to facilitate programming. With these emulators, program and data can be directly downloaded from variety PC to the target hardware, much like we nowadays program storage. Such ROM emulators saved plenty of it slow, but didn't facilitate the debugging process itself. Still, it had been possible to debug applications this fashion, although it took lots of some time and patience. However, since a minimum of the previous tends to be briefly supply in any commercial project, efforts were made to facilitate the debugging process at an early age. Even so, the techniques utilized within the first years of embedded systems programming are still important in situations where no debugging environment is on the market (either because an exotic controller is getting used or because the controller remains too new be supported by a tool chain). it is also often the case that individuals who know the thanks to debug without tools are better at debugging (with or without tools) than people who have only learned to debug in elaborate debug environments. Therefore, we are visiting first provide you with an summary of techniques useful when no debugger is on the market, before we shift our concentration to the various debugging tools available today.

Before we advance to the varied debugging tools, allow us to think about what it's we'd like from a debugger. Any state-of-the-art debugger will offer breakpoints, that is, it'll allow the user to define points within the code where program execution should stop and control should be transferred to the debugger. Related to that is the single-stepping feature, which simply executes the code instruction by instruction. When control is with the debugger, the user generally wants to induce information about the state of the program. On top of the list is that the examination and modification of variable contents, followed by information about the decision history and also the parameters with which functions were called. So any debugging tool worth its salt should be ready to offer these features to the user. When developing for embedded and real-time systems, the timing behavior of the program and its interaction with the hardware become issues yet. So ideally, useful debuggers should also support the user during this regard.

Embedded Software and Hardware Architecture could also be a primary dive into understanding the embedded architectures and writing software to manage the hardware of the project under consideration. After having proper debugging tools and spending some time on learning of these tools will boost your experience in writing low-level firmware to directly interface hardware for efficient, readable and portable design practices smaller to bigger projects. But it all depends upon your focus and intentions that how much you spend time in programming and debugging the software along with associated electronics circuit boards. The Host Linux Machine for example is a machine where one can built and ran code under a simulated environment to an Integrated Development Environment. By using this kind of tool and platform one can build and install code directly on to ARM Cortex-M4 Microcontroller for testing the intended tasks. If a code developer tries various tasks and assignments for writing firmware to interact and configure the ARM architecture and then the MSP432 microcontroller platform then he can sure build a very successful application or system using these very power microcontrollers. The Texas Instruments Launch Pad with the MSP432 microcontroller are excellent choice for designing, debugging the microcontrollers based projects.

In-Circuit Debugging

In-circuit debugging (ICD) is the tool required by almost all microcontroller project developer because it is the most powerful fault-finding technique available for microcontrollers here all around. It allows the chip to be programmed and tested in circuit using the well know platform named MPLAB. The use of MPLAB along with the ICD enables the programmer to regulate or control the program execution within the actual target board or project board or prototype board where the microcontroller is being used. It means, now no need to pull off the MCU chip from board under consideration for programming and additionally you can test your code with the circumstances of the actual hardware. This can be obviously a serious advantage, because it allows the interaction of the PIC chip MCU with its hardware for complete testing than in an exceedingly purely software simulation. Microchip currently offers three main debugging interfaces which all support the entire range of PIC chips MCU. These debugging interfaces or tools possess the subsequent features like USB connection, Program download, read and verify, In-circuit debugging, Unconditional and conditional breakpoints, Register display and stopwatch timing etc etc.

Lets start with the PICkit3 is that the most cost-effective solution for non-professional developers, providing all the required features for learning and hobby applications in an exceedingly compact and easy-to-use package. It’s an enhanced version of PICkit2, operating at a USB full speed rate of 12 Mb/s. It uses the six-pin in-line board connector, which can normally connect direct to the project circuit. The ICD3 is more powerful, operating with high-speed USB (up to 480 Mb/s) to produce real-time ICD with maximum MCU clock rates and more complex breakpoint triggering options. It uses the six-pin RJ-11 connector, designed to attach on to chips that support ICD, or to a header board (see below) for those who don't.

It may be noted that the PICkitX means any of PICkit ( PICkit2 or 3) and ICDx programmers are both capable of supporting In-circuit debugging. However the smaller mid-range like 16FXXX chips, i.e. 16F690 chip don't support ICD internally. For these chips, ICD may be implemented instead by employing a header board connected between the ICD module and also the chip socket on the applying board. The header board carries a version of the target chip that includes the on-chip ICD circuitry, which substitutes for the target device while the system is under development (these chips aren't available separately). The ICD module sits in between the host PC running MPLAB IDE and also the application board MCU socket. When debugging is complete, the chip will be programmed to run independently and plugged directly into the board. The on-board reset circuit has been included to indicate how it's isolated from the VPP by a 1k0 resistors.

Other methods of debugging:

There are several other methods or techniques available for debugging the code for its actual behavior in its actual environment , some of these are like ICE (In Circuit Emulator), Simulators, use of proper LEDs or LCD for proper messaging. Among these the technique named In Circuit Emulator (ICE) is comparatively costly. The other are used defined which altogether depends upon the user field of interest. However the simulators are helpful at assembler level code verification. There are some simulators which will tell the project develop about how the code is taking or the clock cycles can be checked and some provide a stopwatch to check the execution time for a couple or bench of statements.

The UART or RS232 is also used for transferring some important results at some specific time for the debugging purposes. Mostly MCU have built in UART and at the other end project developer can build a custom hardware or can use PC as well. In Computer there are Hyper terminals software available which can transmit and received the messages on specified baud rate. Important things that the code developers have to write some extra lines of code which will be specific to only debugging point of view. When that situation arises the corresponding message can be read using hyper terminal on suitable computer through the interface of serial communication using RS232 serial communication protocol. It may also be noted that the serial communication using USART RS232 is very much slower as compared to USB interface. Using In circuit debugger based on USB technology is much faster. Rest is on the project developer that which method he adopts for debugging or totally don’t consider the debugging at once.