I'm developing a bootloader for the MPC5748G in C.
The bootloader will be running on RAM so i want to know how can i debug the bootloader code running on the MPC Target.
Thanks
Without further information on the platform you are using, the general guideline is that you compile your Bootloader software with Debug symbols, and once loaded, start a debugging session which should be configured to attach to the process (instead of the classical load-then-break-at-main). Then, hitting pause should interrupt the target, and from here on it is a normal debugging session.
Related
I am trying to use Clion IDE to debug various NXP ARM M MCUs using J-link.
In case when program is only in RAM it works fine but but in case of flash targets after program load IDE often slows down for a while and then I will get timeout. Some click on pause button in right moment pauses program somewhere and allows me to debug...
My question is there any way how to see interactions of IDE with armgdb client or armgdb and j-link gdb server?
I tried to capture communication with gdb server using wire shark but it seems to be a binary protocol...
Thank you.
I found there is possibility to let gdb echo commands which showed me what is going on.
Unfortunately in case of Clion the only way is to put it into .gdbinit file in the root of project.
set trace-commands on
It showed me warning
warning: A handler for the OS ABI "Windows" is not built into this configuration
of GDB.
Which leads me to comment of this question gdb-multiarch (MINGW64) cannot determine architecture from executable?
Well I am not sure what caused Clion to hang but having .gdbinit with just set osabi none in it solved it.
I have a code running in Ring0 and it is crashing. I do not have any gdb server in my software. It is pure assembly diagnostic software. I am using Corei7
In embedded systems I used a hardware debugger (with Jtag), I can stop the core and check the exception registers...
I am not able to find the same process in x86 based boards.
Can someone point out how they do debugging of assembly code without using gdb.... Or if you use a JTAG/HW debugger please let me know as well
thanks
I'm curious about how, running Windows 7 on x86, you could execute some code in kernel mode. This is for my own personal use; so I'm not bothered about giving Windows a trillion permissions or whatever. Does kernel mode code have to be specially compiled or linked? etc
Only code from the kernel itself, and from certain device drivers, can run in kernel (supervisor, ring 0) mode.
So you will have to write a device driver.
EDIT: the question has already been answered here.
Ring 0 drivers can execute code in kernel mode.
You will need Windows Device Driver Kit for such development.
Also you have to be extremely careful with driver development because unhandled exception occurring in the kernel indicates a serious bug that exists in the operating system or (more likely) in a device driver and not in an application. Once memory in the kernel gets potentially corrupt, it isn't safe for the system to continue running and you see what is typically called "the Blue Screen of Death."
So normally your drivers should be WHQL certified.
I'm working with an 8051 (Cypress FX2LP) that doesn't have jtag/bdm capability. Typically, developers on this project have been using ad-hoc serial printfs for debugging. I'm looking into options for serial debug monitors such as Keil's Mon51, Isd51 or IAR's generic ROM-monitor.
I'll need to modify/configure this debug monitor to write to code RAM (to set software breakpoints). I'd guess that most 8051 debug monitors offer the ability for such modifications in order to support Harvard architecture or bank switching.
Does anybody have recommendations for serial debuggers for 8051 or similar processors?
Have you had to modify it to write to Harvard code RAM or flash etc?
I used for years Keil uVision PK51 and the Cypress FX2 EZ-USB Development kit. This kit (EZ-USB_devtools_version_261700.zip) worked correctly with FX2 and FX2LP.
It includes a Windows driver that automatically downloads the monitor firmware on board and stay resident in 8051 memory. This monitor takes control of one of the 2 serial board and manage the communication with the debugging tool. You have to set the Keil environment debugger to use the "Keil Monitor-51 driver".
Once your fw is downloaded and running you can set breakpoints, display watch, etc...
The Cypress driver works correctly with Windows 2K/XP. I never tried it with Vista or later. Probably there is a newer version of the Cypress that is able to run on the latest Windows.
Good luck
I have been using Mon51 with the Cypress FX2 for going on 10 years with very good success. In addition we use the RTXtiny task switcher and code banking. I have found the monitor to be generally solid and with enough functionality for our needs.
The Mon-51 code comes as a library from Keil, so it is not available. A couple of years ago I was having trouble getting code banking to work with the monitor, and since I wasn't getting very good support from Keil, I started to disassemble the monitor to figure out what was going wrong. Before I got very far I solved my problem and I never finished the reverse engineering project.
Our hardware platform is "von-neumanized" so that code and xdata space overlap. This is necessary for the monitor to work correctly. We have modified the monitor initialization code so that it runs at 115200 baud from an external uart and that works well. In addition we had to build our own version of the monitor so that it was located at a different location in memory. Keil has actually made it pretty easy to configure things without having to dive into the actual monitor code.
I've to test some low level code on an ARM architecture. Typically experimentation is quite complicated on the real board, so I was thinking about QEMU.
What I'd like to get is some kind of debugging information like printfs or gdb. I know that this is simple with linux since it implements both the device driver for the QEMU Integrator and the gdb feature, but I'm not working with Linux. Also I suspect that extracting this kind of functionality from the Linux kernel source code would be complicated.
I'm searching from some simple operating system that already implements one of those features. Do you have some advice?
You don't need a target OS to debug code that's running inside QEMU -- QEMU already does that for you.
Specifically, QEMU supports remote debugging from GDB -- you can run QEMU with the appropriate command-line options and it will export an interface that a copy of GDB (running on the host machine) can connect to. At that point, you can debug the program in GDB pretty much just as if you were running it on the host machine.
http://wiki.osdev.org/GDB appears to have a bit more basic information; possibly not enough to completely get you started, but at least give you the basic idea and some terms to look for in the QEMU and GDB documentation. Skip over the bit about "Implementing GDB Stubs", which doesn't apply here since QEMU has one already, and start at the section on "Using Emulator Stubs". The short form is simply that you start QEMU with the -s option (export a GDB connection on localhost:1234) and the -S option (wait for a GDB "continue" command before starting execution), and then in GDB on your host you say target remote :1234 instead of run. Also, of course, you need to be using an ARM version of GDB rather than a native-x86 one.
(In addition, if you're willing to pay for a commercial solution, CodeSourcery's ARM toolchain has the IDE integration to set all of this up automatically, including support for "printf" to print into the debugger console. That works on a physical board, too, if you've got a hardware debugger. Usual disclaimer about me being a CodeSourcery employee applies -- but I do find it very easy to use.)
Update, 2012: CodeSourcery's toolchain is now called Mentor Graphics Sourcery CodeBench, but all the above still applies.
I realise that I am addressing your original problem here rather than your proposed solution (perhaps that's better?), but to use GDB (or Insight/GDB) directly on the target, use a low-cost JTAG tool and OpenOCD. An example of such a set-up and how to implement it can be found here.
If you have a larger budget, a more fully featured JTAG debugger may be useful, such as the Abatron BDI3000 with bdiGDB firmware which allows remote debugging and device programming over Ethernet with GDB and no special drivers or target debug agent.
Maybe a microkernel like OKL4 would suit your needs?