As I understand, on linux systems debugging is done via the ptrace sys-call.
I would like to know how would I write a debugger for a micro-controller (no-OS).
Let us for the sake of simplicity assume the case of a software debugger for a board like Arduino Due (ARM based).
What would I have to learn to accomplish such a project, assuming I have a fair idea on how debuggers work on Linux and Windows
How different would programming a debugger for a MCU system be? (I can't use sys-calls)
Is debugging achievable via USB or serial interface?
Which languages should I use? (C, C++, Arm assembly)
How can the armgcc compiler help me with my project (are there flag options such as -g etc?)
I plan to implement the debugger as a command line Linux utility.
Most modern processors, including the ARM on the Arduino Due have on-chip debug support accesses via a JTAG interface. The Cortex-M3 on-chip debug supports 8 hardware breakpoints and some other features - with code running in flash memory you cannot set software breakpoints.
The JTAG interface itself is rather simple, but you will need special hardware to support it from a PC. Depending of performance and features a JTAG debugger may vary in cost hugely from very low to serious money. Software to interface the JTAG to the debugger software is required. OpenOCD is an open source tool for interfacing JTAG/On-chip debug to GDB allowing GDB-ARM to be hosted on a PC to debug the remote ARM target.
You could in theory write your own software to to access the OCD via JTAG. I have never considered implementating a target hosted debugger on a microcontroller, although I have used VxWorks on ARM9, SrongARM and x86 and it has limited support for target hosted debugging. The utility of target hosted debug is limited by the lack of the source code and symbol table information that is available to a hosted debugger to support source-level debugging.
Even so, I believe that it is possible to access the on-chip debug from the target itself see ARM's documentation for details.
Related
There doesn't seem to be too much comprehensive information on this topic. It seems to be something that is done quite often and easily in professional tools like Keil and IAR, but it can be a bit tricky/inflexible to write tooling around them that isn't in some special script/language they support.
How do you watch/stream live variable data from a GDB Server without stopping the processor? This can of course be done in some manner with Trace/SWO on non M0 processors, but the professional toolsets work well without this functionality.
I have downloaded EDK (UEDK2014) from taniacore site and I have successfully build UEFI application in Debug mode using following command
C:\UDK2014.Complete.MyWorkSpace\UDK2014.MyWorkSpace\MyWorkSpace>
build -t VS2012x86 -b DEBUG
As it is in Debug mode it will create a .pdb file (SecMain.pdb). My Question is How to debug this binary using VS 2010.
I trided doing that by running SecMain.exe, attach it to Visual Studio 2010 and start debugging but not able to do that. Could any one have done this (Debugging an UEFi application using VS 2010) before ? please let me know if you have solution to this.
Yes, you can use an emulator as #sun2sirius said. The only problem though if your UEFI App or driver accesses the hardware directly the emulator won't help. In this case unfortunately "printf" is your best friend. So good Trace/Log library will help you to debug your driver.
There are a few ways to simplify the development:
Write as much platform-independent code as you can. Easier to debug in VS IDE under the Windows. Windows has protected memory pages and debugger will catch all potential memory issues; UEFI is in real mode, so your platform dependent code is not protected against accessing dunging pointers, buffer overrun etc. So again Trace/Log library is a big help.
There is a hardware debugger on the market like Arium. It can debug UEFI application running on the real hardware. But it's expensive and the hardware you debugging has to have a hardware debug port available. It's not hard to find on desktops but on the production laptops it is a rare beast! So you have to solder the connector if you need to debug a specific platform.
I case of UEFI driver development even HW Debugger is not much of a help because you have to have a debug built of the UEFI firmware (BIOS) on the platform installed in order to use a debugger.
We currently hold a full license for the IAR EWARM IDE but we need to upload firmware to units being made meaning only one person can do the uploading as the application is way over the kickstart size.
I'm wondering if there is an alternative method for just uploading (no debugging) IAR's outputted executable without the need for a fully licensed version? I've looked into the Eclipse plugin but this seems to rely on the IAR compiler still.
We're using the TMS470 chip and a JLink programmer.
Any advice would be much appreciated.
In your project options, there is a category for Output Converter. In this section you can get a Motorola S-record format, Intel hex format, binary, or other output type. From here, you can use the J-Link software, though you will need to purchase a license to be able to download arbitrary code not as a part of the debug process.
J-Flash is the software component needed for stand-alone flashing support: J-Flash order page.
J-Flash licences are locked the the hardware serial number - you will need one for each J-Link you want to use. They are somewhat expensive for an existing J-Link.
OpenOCD includes support for Segger J-Link (which IAR rebadge), and can be used a for stand-alone flash programmingbut whether it works apparently depends on the J-Link firmware version, so YMMV.
There are lower cost JTAG debugger/programmers(example) that will work reliably with OpenOCD and cost much less that a single J-Link licence.
Segger offers J-Flash, a PC software program that interfaces with the J-Link debug probe to program the flash memory on a target. You need a license for J-Flash but it's independent of the IAR (or other) toolchain.
You might need another software program to convert IAR's standard executable output format to a format that J-Flash can use, perhaps hex, s-record, or binary. IAR probably includes the conversion tool or you may be able to do a web search for something.
I was using PIC micro controller for my projects. Now I would like to move to ARM based Controllers. I would like to start ARM using Linux (using C). But I have no idea how to start using Linux. Which compiler is best, what all things I need to study like a lot of confusions. Can you guys help me on that? My projects usually includes UART, IIC, LCD and such things. I am not using any RTOS. Can you guys help me?
Sorry for my bad English
Once you put a heavyweight OS like Linux on a device, the level of abstraction from the hardware it provides makes it largely irrelevant what the chip is. If you want to learn something about ARM specifically, using Linux is a way of avoiding exactly that!
Morover the jump from PIC to ARM + Linux is huge. Linux does not get out of bed for less that 4Mb or RAM and considerably more non-volatile storage - and that is a bare minimum. ARM chips cover a broad spectrum, with low-end parts not even capable of supporting Linux. To make Linux worthwhile you need an ARM part with MMU support, which excludes a large range of ARM7 and Cortex-M parts.
There are plenty of smaller operating systems for ARM that will allow you to perform efficient (and hard real-time) scheduling and IPC with a very small footprint. They range form simple scheduling kernels such as FreeRTOS to more complete operating systems with standard device support and networking such as eCOS. Even if you use a simple scheduler, there are plenty of libraries available to support networking, filesystems, USB etc.
The answer to your question about compiler is almost certainly GCC - thet is the compiler Linux is built with. You will need a cross-compiler to build the kernel itself, but if you do have an ARM platform with sufficient resource, once you have Linux running on it, your target can host a compiler natively.
If you truly want to use Linux on ARM against all my advice, then the lowest cost, least effort approach to doing so is perhaps to use a Raspberry Pi. It is an ARM11 based board that runs Linux out of the box, is increasingly widely supported, and can be overclocked to 900MHz
You can also try using the Beagle Bone development board. To start with it has few features like UART I2C and others also u can give a try developing the device driver modules for the hardware.
ARM Linux compilers and build toolchains are provided by many vendors. Below are your options which I know of:
1.ARM themselves in form of their product DS-5 ;
2.Codesourcery now acquired by Mentor graphics. See some instructions to obtain & install, codesourcery toolchain for ARM linux here
3.To first start programming using ARM (C , assembly ) I find this Windows-Cygwin version of ARM linux tool chain very helpfull. Here. These are prebuilt executables which work under Cygwin(A Posix shell layer) on Windows.
4.Another option would be to cross compile gcc/g++ toolchain on Linux for ARM target of your choice. Search and web will have information about how it is done. But this could be a slightly mroe involved and long-winding process.
enjoy ARM'ing.
First, you should question yourself if you really need to program assembly language, most modern compilers are hard to beat when it comes to generating optimized code.
Then if you decide you really need it, you can make life easier for your self by using inline assembler, and let the compiler write the glue code for you, as shown in this wikipedia article.
Then the compiler to use: For free compilers there are practically only two choices: either gcc or clang.
There is also a non free toolchain from arm which when i last tried, 5 years ago, produced about 30% faster code than gcc at the time. I have not used it since.
The latest version of this compiler can be found here
You can also write standalone assembler code in .s files, both gcc and clang can compile .s into .o in the same way you would compile a .c or .cpp file.
Compile
If you are using a STM32 based microcontroller you need to get CMSIS and GNU arm-non-eabi-gcc package installed. Then you need to write your own makefile to pass your c codes into arm gcc compiler.
Programming
For the programming step you need to install openocd and configure that for your specific programmer. You can find a full description on how to do that on my blog
http://bijan.binaee.com/index.php/2016/04/14/how-to-program-cortex-m-under-gnulinux-arch/ and in my GitHub repository.
IDE
I'm using vim with CTags but you can use gEdit with the Shortcut plugin if you need a simpler text editor.
I am wondering how you profile software on bare metal systems (ARM Cortex a8)? Previously I was using a simulator which had built-in benchmark statistics, and now I want to compare results from real hardware (running on a BeagleBoard-Xm).
I understand that you can use gprof, however I'm kind of lost as that assumes you have to run Linux on the target system?
I build the executable file with Codesourcery's arm-none-eabi cross-compiler and the target system is running FreeRTOS.
Closely evaluate what you mean by "profiling". You are indeed operating very close to bare metal, and it's likely that you will be required to take on some of the work performed by a tool like gprof.
Do you want to time a function call? or an ISR? How about toggling a GPIO line upon entering and exiting the code under inspection. A data logger or oscilloscope can be set to trigger on these events. (In my experience, a data logger is more convenient since mine could be configured to capture a sequence of these events - allowing me to compute average timings.)
Do you want to count the number of executions? The Cortex A8 comes equipped with a number of features (like configurable event counters) that can assist: link. Your ARM chip may be equipped with other peripherals that could be used, as well (depending on the vendor). Regardless, take a look at the above link - the new ARMs have lots of cool features that I don't get to play with as much as I would like! ;-)
I have managed to get profiling working for ARM Cortex M. As the GNU ARM Embedded (launchpad) tools do not come with profiling libraries included, I have added the necessary glue and profiling functionality.
References:
See http://mcuoneclipse.com/2015/08/23/tutorial-using-gnu-profiling-gprof-with-arm-cortex-m/
I hope this helps.