recently I have bougth a ESP32 devkit and a low budget FT4232H jtag adapter which I managed to setup in VSCode using the Espressif-idf plugin.
Basically it seems to work so far. I can build, flash and monitor the ESP32 from VSCode. Also also managed to setup the debug configuration, but I am still missing some features in while debugging.
I can step through the code, watch variables and see the call stack.
But I can't see periphals, registers or memory
I guess I have to set some more options in GDB, OpenOCd or even ESP32 config but I don't know which ones.
Any ideas were i have to dig?
You appear to be almost there.
I have a very similar interface with the memory loading afterwards but only after stepping into certain operations.
https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/jtag-debugging/debugging-examples.html
Following this document produced by espressif. Memory can be accessed and stepped into using the keyboard shortcut (x) when using openOCD.
Give that a try.
Related
I'm developing firmware on a custom board and would like breakpoints and step-through debugging. I can't retroactively fit JTAG.
What's the best way to add breakpoint debugging in VSCode on Windows? I print general logs to the serial port and would like to retain that, if possible. The application is freertos-based. I've tried OpenOCD in the past but I don't at all find anything in VSCode intuitive, so need a bit of a "for-dummies" hand-holding here.
Currently printing logs to serial, it's effective only to a point...
The ESP32 requires a JTAG connection (and an adapter, e.g. ESP-Prog) for debugging.
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 could program and debug this project for the first time. But the problem is that I can't reprogram or debug it again. There is no bootloader on the chip. The only way to communicate with this chip is SWD. As a debugger, I am using Atmel ice. The microchip is SAMD21E16B-U. The project is created by Atmel Start. Visual Studio is used as an IDE to import the project.
After debugging again, the error is:
The problem may be because of setup. I am not sure what I missed. I followed the visualGDB website for importing this project.
I checked the power connection.
There is no option for "connect under reset" on visualgdb debug setting. However, this option was available on STM chips.
I really appreciate it if you can guide me on what I can do for reprogramming this chip? Or which information I should look for. Thanks for any helpful recommendations, in advance.
The following steps solved my problems. I think erasing my chip was helpful to reprogram the chip. I am not sure which step exactly caused the error. But after these steps, I didn't get that error.
Choose the right chip: samd21e16b instead of samd21e16b-U (The first selection was based on a schematic. My schematic wasn't correct (look at the physical chips on our board or use a microchip studio. Microchip studio detected the right chip for me). I have selected an incorrect device while creating our project (e.g. Our device has different SRAM, Flash, and packages.)). Then, I needed to set up again and choose the right chip.
Erase the chip by microchip studio and was able to reprogram it. So, I am using microchip studio for erasing the chip and getting back to visual studio, and then reprogramming, or debugging it
Checked the power connection (connect the Vcc 3.3 by SWD connector and
make sure that the green light on Atmel ice is on before debugging (The green led on Atmel ice is showing that the chip power is ok and correct)
also, I should make sure that my chip is connected to pc by USB. It may be different in your chip to provide power)
I didn't change my debugger from Atmel ice to J-Link but it was a solution that the visualGDB (sysProgs) support team mentioned. I will only add their quotes briefly. It may be helpful for the ones who want to solve the problem by the visual studio and reset the chip. But I didn't change my debugger or didn't configure openOCD. I used microchip studio and reset the chip instead.
VisualGDB Support team: This looks like a device connectivity issue rather than something VisualGDB-specific. Our best advice would be to try using Segger J-Link. It comes with its own fully supported replacement for OpenOCD, which generally works better in many edge cases. VisualGDB supports both OpenOCD and J-Link software, so all the features you previously used will continue working the same way.
VisualGDB does not manage resetting/erasing directly. It simply launches the open-source OpenOCD tool that handles the low-level communication with the target.
You might be able to configure OpenOCD to change the reset behavior by editing the OpenOCD script files, however, this is something to do at your own risk and it may require extensive research into OpenOCD internals.
If you are looking for an easy out-of-the-box solution, please consider using Segger J-Link instead.
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'm currently setting up vmware Server 2.0 for kernel debugging with gdb ( see this setup guide ) and someone asked me why not use kvm?
So I ask: kvm vs. vmware for kernel debugging / USB driver development
what are the pros and cons of each?
Driver development? are you working on a driver for a particular piece of hardware? if so, then you probably won't be able to use virtualization, because the virtualized instance won't have access to the new hardware.
For this you will need two machines, one running a remote debugger on the other.
*Edit: * Apparently you're developing a driver for a USB Device? this is one area in particular that a VM actually Can help. These days most VM's have the ability to delegate specific USB devices to a guest OS.
That said, this situation doesn't really offer any benefits over the remote debugger option, because you still need a way to inspect the state of the running or crashed OS, and VM's offer very little assistance in this regard. You might be able to replay saved states from just before a crash.
You might be able to get a bit of traction using UML, which would allow you to do local debugging as on a regular user process, which is a little bit less trouble.
Instead of answering the direct question I'll add another option... Depending on if the kernel in question is a Linux kernel, and what part(s) of it you are working on, you might find that UserModeLinux (included in the 2.6.x source, and available as patch sets for 2.4 and 2.2) may trump both of those options.
As it runs the kernel as a userland process under the host kernel it is easier to attach common debugging tools to. I believe it is very commonly used in the early stages of updates/additions to file-system related code. If you are developing/debugging modules that interact directly with hardware it may be much less use to you though.
Reference links: home,
other
I recently started building GNU Mach/HURD and found the combination of QEmu/KVM to work really quite well.. for the following reasons:
QEmu presents quite a clean environment
Networking has alot of options
I can easily mount the filesystem using a raw device file / loopback
Bottom line is, for kernel work I just want the minimum of functionality to boot and see the result. VMWare is much more for usable virtualization rather than down-and-dirty.
There is however no comparison to booting on a real machine with real hardware. The VM environment can seem like a safety blanket somtimes ... because even my toaster would know what a Realtek RTL8139C was.
If it is a "real hardware" device, of course, vmware will not emulate it, so you won't be able to debug the driver under it (nor will any other virtualisation software, unless you extend one to do so).
Device driver debugging can be done to some extent with a real hardware machine with a normal kernel - although there are obviously things you can't do - like set breakpoints.
It is still possible to attach a debugger to the kernel and inspect stuff. Moreover, traditional printf() debugging is quite possible (printk, anyone), and there are various features in the kernel which make debugging easier. It's possible to build the kernel with various debug options to try to detect pointer problems, memory leaks etc.
By default, the kernel even gives a nice-ish stack trace on the log when it encounters an OOPS or BUG condition (obviously this does not necessarily get written anywhere if the system hangs or crashes). Of course a pointer-out-of-range condition happening inside an interrupt is a recipe for disaster, but you could still get a stack trace on the screen immediately before the panic :)