I am bit new to this field and my query here is a bit vague. I am particularly interested in how any of you, who have had experience with uBoot and a JTAG debugger (like a Lauterbach), have gone about tackling and resolving an issue within uBoot.
Specifically, I would really appreciate if you could describe the problem encountered within uBoot, and how did the JTAG help you resolve the issue.
Thanks,
vj
I have used this many times using Texas Instruments' CCS debugger. I would create a dummy project with the u-boot source code and then attach. Afterward, I can load the u-boot symbols or the u-boot app itself and step through the code. Reloading and restarting u-boot is helpful to work through issues.
This applies to any problem with u-boot, including start-up problems.
I use LPCXpresso (based on Eclipse) to debug U-Boot on my board (with LPC4350 MCU).
But be careful, you could have problem to debug and you maybe need to modify the .lds file (linker script).
You have to find this file but be cautious, the file is copied and modified when you configure the compilation for your board, you have to look for the original file.
Then if you find
/DISCARD/ :
{
*(*)
}
in the .lds file, you won't be able to debug. Just remove it or comment it.
Related
I am trying to debug a driver in UEFI firmware (OVMF) via gdb as described here:
https://github.com/tianocore/tianocore.github.io/wiki/How-to-debug-OVMF-with-QEMU-using-GDB
It works well, but I discovered that just having debug symbols for my driver is not enough. I also need debug symbols for the whole OVMF image to properly see what's going on. I have a lot of .debug files after OVMF is built with edk2, but I don't understand which ones I need to load into gdb, and what addresses I should use.
I found some instructions involving DebugPkg, but I couldn't make gdb_uefi.py work no matter what. It always failed to locate EFI_SYSTEM_TABLE_POINTER.
In the end, I ended up writing my own script, which implements gdb command that does manage to successfully load all debug symbols. It is probably a worse solution, since it requires a setup: "debug.log" with driver addresses must be present when loading is performed, so you need to run QEMU at least once first. But, this is good enough for me.
My script can be found here:
https://github.com/artem-nefedov/uefi-gdb
Edit : Problem circuvented by generating a Makefile project but I'd still like to know what is going on.
This question echoes my unresolved problem mentioned here (STM32 app not running sometimes, remains in DFU).
I have a custom board STM32L486 based and I am using the built-in DFU mode to upload new firmware over USB using dfu-util on Linux.
Sometimes, for unknown reasons, the app won't start after leaving the DFU mode.
A slight change in code can make it work or break it. (see link above for details).
Examples of changes that can reverse the problem :
Adding / removing a HAL_Delay or a LED Blink
+1 or -1 on an array size
Adding / removing a sprintf format
What seems to work is building the binary with Og optimisation (or using the STLink tool and debug mode).
I have tried to increase the heap and stack (up to 20x the default), it doesn't change anything.
Checking the prepare dead code/data removal options in Atollic seem make build fail more than other times.
What could be causing the issue of the app not starting, not even the init steps ?
How can I track down the culprit flags that may cause this ?
Can this be linked to a memory alignment problem ?
Any ideas / insights / comments on how to check is welcome.
I have been able to reproduce the same issues (from here and my other link) on a Nucleo board.
I tried to generate a Makefile project from CubeMX and the problem does not happen. I guess this is a bug in either the binary generated by Atollic or the compiler/linker settings that the IDE.
Note that my Makefile uses the exact same toolchain as Atollic so this cannot be a toolchain issue.
This issue is hereby circumvented by this, but I'd still like to understand what may happen.
As far as I've tried, this DFU issue and app not rebooting is caused when building from Atollic (TrueStudio).
Generating a Makefile project from CubeMX solved this issue though I still cannot explain why.
while i was using cubemx to set peripherals of my stm32f407 arm core, just before generating code, i checked and selected the "set all free pins as analog (to optimize the power consumption)" dialog box in project settings-> code generator-> HAL settings, without masking the debug pins (swdio and swclk). After that, i downloaded a simple blinky code inside the microcontroller successfully using keil ide. but now when i want to use keil to erase or download a code, i see "no target connected" error in debug tab and i cant download any code. How can i solve this problem? Thanks for your helps.
After about 10 hours searching, i found the solution.
if someone had the same problem, here is the solution :
https://electronics.stackexchange.com/questions/204996/stm32-st-link-cannot-connect-to-mcu-after-successful-programming
As an addition to your answer - when you set all as analog, set in the SYS the correct debug interface. It will prevent code generator from setting those pins as analog.
I am using Qemu to learn some linux kernel development/hacking and wanted to debug the boot process of Linux (2.6.34.3). I have compiled for the ARM versatile platform and is using Codesourcerys arm-none-eabi crosscompiler. I am using Eclipse as the environment to build and debug using gdbserver.
So I have manged to successfully build and run the kernel in qemu but the problem is that I dont see any source code in the debugger at the boot process(at address 0), I can only see the disassembly code. However, when it switches to virtual memory at init/main.c (address over 0xC0000000), the source code appears and I can see the source code and step through and over code. Why is that? I want that from the beginning.
Anyone have any tips on how to debug the boot process of Linux? All the guides in google shows how to debug the kernel, but they all show from start_kernel() (located in init/main.c) and not from the beginning of the boot process (in arch/arm/boot/compressed/head.S). Anyone with experience help please, thank you!
Looked into the System.map in the root folder and there is only symbols for stuff from c0004000 (where the virtual address start). I load vmlinux into gdbserver to get debug information, Maybe thats why theres no source?
The Linux kernel uses a 2-step booting processing (and this does not include any boot loader like u-Boot ...). You can better understand this especially by looking into 2 .lds files (detailed below) for linking:
arch/arm/boot/compressed/vmlinux.lds.in, which generates arch/arm/boot/compressed/vmlinux.lds.
Along with other .o files in arch/arm/boot/compressed, a vmlinux is generated inside this folder.
You can use arm-none-eabi-nm -a -n arch/arm/boot/compressed/vmlinux to see the symbols for this stage. All addresses are physical addresses.
These symbols are NOT included in System.map
The second vmlinux is generated by kernel .o files and arch/arm/kernel/vmlinux.lds (note: the path is different)
I hope this explains why you can not see the booting source code in Eclipse.
linux kernel is too complex to understand(for a beginner).
Why dont use use a smaller OS like xv6:
OS is small, sourcecode is about 8000 lines
used by many universities
based on V6(unix),
boot process is the same except that its less complicated than that of linux.
Appendix B of the xv6 book deals with boot process(its short and sweet).You can run gdb on qemu and see the boot process, the main files to check out for are bootasm.S(in assembler) and bootmain.c.
This is much simpler and easier to do and understand when compared to linux.(atleast for beginners).There are assingmennts on , setting up qemu , using gdb ,tracking the boot process , doing changes to the source code etc in the link given.Give it a shot :)
Cheers,
sharan
head.S is written in assembly, not C. That's what the .S suffix indicates.
I am wondering which debugging tool I can use for an assembly program and how to use it.
I have written a simple bootloader in assembly. However, it is not quite working properly as I wished, even though I think the logic is correct. So, I am trying to use a debugger so that I can step through the bootloader, checking the register status and etc.
I tried GDB on Ubuntu, compiling my .asm to .elf and .o (Do I need to do it? If yes, what is the next step?) Also, I read that there is an internal debugger in Bochs simulator, but I can't quite find any document how to use it. I also have Visual Studio 2010, windbg, but I don't know how to use it for .asm file debugging.
If you have done this before, it would be an easy answer. Any help would be really appreciated.
Sincerely
If you want to debug bootloader code, you obviously need to run it in the same environment that the code itself is going to run in. As I'm sure you already know, bootloader code is executed in real mode once the BIOS finishes doing the POST. The bootloader is then loaded into memory at 7c00h and a jump to that address is executed.
Obviously, this kind of environment cannot be reliably emulated once you've got your computer running and a "real" operating system already loaded, since by that time your CPU is in protected mode (or long mode, if it's AMD64). Your only option at this point is to use QEMU or Bochs in order to emulate a real PC inside your operating system. I've used Bochs to debug some bootloader code I've written in the past and it worked quite well. Check the manual pages for more detailed instructions.