I've been trying to get U-Boot SPL to print debug messages. I've noticed plenty of debug() functions that aren't printing to the serial console, however when I define the DEBUG preprocessor macro, I still don't see those messages.
Is this something the SPL can even do? Especially since the serial console is initialized in preloader_console_init() can any messages be sent before that function is executed?
Assuming that your UART is configured correctly, you should see messages once preloader_console_init has been run. Prior to that, you can (depending on your platform) see about getting DEBUG_UART to function in your environment.
Related
On a SAM4C microcontroller platform the time() function is called within a library. I found out, that this gives the right time (1496321612) when I start from debugger. However, when I make a hardware reset on the board, and the flashed firmware executes without debugger, time() doesnt return and the firmware stucks at this point.
I wonder how time is set at all. I debug only via ATMEL JTAG ICE (Segger) and do not set the time explicitly. When I change date on my PC I get back a different time while debugging...Is there an automatic mechanism that sets time from my PC when a debug session gets started by the Segger ICE and why is my firmware crashing when time is not set?
This can be achieved using the mechanism called semi-hosting. Overall the mechanism is allowing the target to use some facilities available on the host computer (the one running the debugger HW/SW). The simplified mechanism is like the following:
The target firmware is linked against a library supporting the semihosting.
Each time the firmware is invoking the semihosted function, a debugger event is happening (It can be some SVC/SWI call, special breakpoint or something else, depending on the specific platform).
The debugger is "catching" this event, figuring out what was requested (it can be some IO function, or a request for time as in your case) and passing this request to the host software.
The host software is doing what was requested and passing the result to the debugger.
The debugger is passing the result to the target FW.
The target is resuming.
For the needs of project, I wrote a simple java socket program to implement a "fake" gdbserver stub. Thus, support the minimum number of gdb RSP commands:g,G,m,M,c and s. For other commands, just response with "$#00". According to the manual of gdb, this would tell gdb that the "server" doesn't support other commands.
I use the Eclipse CDT to help me debug. In the debug configurations, I selected c/c++ remote application, and set the debugger connection using TCP on localhost:10000, where my java program will use to listen.
At first, gdb send commands like qSupported, Hg0, qTStatus, ?, and qC. The response to all of them are "$#00" to tell gdb the "server" doesn't support those commands. Then, gdb send qAttached and qOffsets. After sending two "$#00" responses and received a "+" from gdb, gdb says "warning: invalid remote reply:".
Can someone please tell me why did this occur? Why gdb doesn't send commands and say"invalid remote reply:", which I don't know what reply is invalid, after all, I just send "$#00" and "+" to gdb.
This baffled me too when I read the GDB manual. I suspect that the set of commands you need to implement (i.e. those that should effect the state of your simulator) is a subset of the commands your server needs to be able to reply to.
This excellent guide to writing an RSP server by Embecosm has a very handy sequence diagram in Section 3.1 which describes the initial handshake between GDB and your RSP server:
Once you have the handshake working, it's much easier to see how the protocol fits together and start writing in the code that interacts with your simulator (or other target).
In my project, I need to input some command into my WinCE device through the debug Serial Port. But I found that I can only use "printf" or "RETAILMSG" to output my debug info but I can't simply call "scanf" to get the data of debug Serial Port.
By look up the MSDN, I have found a function named "OEMReadDebugByte". It is a KERNEL function of WinCE, but when I try to call this function in my WinCE application, the Platform Builder post "error LNK2019: unresolved external symbol OEMReadDebugByte referenced in function wmain"
Can I use insert a case in the KernelIoControl? How ? Which file define the "KernelIoControl"?
Or... there are any solutions else?
Thanks a lot!!!
Thank you!
This function is meant to be used in the bootloader to read input from the user to set-up bot mode, network configuration etc. It's not used by the kernel. Serial is used for debug output and there is no easy way to change this. What you may do is to implement an application that provide a serial console and change your BSP removing serial debug and changing it to a system that sends this information to the application (using shared memory or something like this) that then outputs it on the serial port console.
Implementing it will require some knowledge of the OAL and BSP structure and features.
Is there a way to get kernel previous debug information after kernel crash occurs.
I am trying to develop a kernel module which basically captures IP packets in the IP layer inside the kernel network stack and after some modification I have to send the same packet back to the NIC for transmission.
During all these processes I'm writing debug information with the help of printk(). But if any thing goes wrong and a kernel failure occurs, we have to restart the system. Is there a way to get my previous debug information, because after rebooting the debug information is not present as I try to get it by dmesg command?
Actually, the /var/log/dmesg file contains the current boot print message log. The /var/log/kern.log file contains your previous boot kernel print message log in Ubuntu. In other Linux flavours it will contain in the /var/log/messages file in Fedora, etc..
Kernel log messages can be viewed in /var/log/dmesg files even after restart of the system.
There will be so many files with dmesg.X, and those files are previous kernel logs. dmesg is the latest file.
See difference between dmesg and /var/log/kern.log
You could try to interact with your hung system by entering magic SysRq key sequences via your keyboard or a serial console.
Recent versions of Linux support crash dumps. When successful, these will include a full dump of memory, including kernel log messages and stack traces.
Actually, the crash information (dmesg) is present in the location /var/crash/.
Here we have the folders for every system crash. Folder names like 127.0.0.1-date-time. vmcore-dmesg.txt are present inside the folders. From these file, we have get the dmesg which are executed before the crash.
GNOME Logs is a very useful software for that. You can limit the log messages to the last session and easily read what the last messages before the crash were.
Are there any soft debuggers for microcontrollers (say PIC24) something like GDB. My platform doesn't run Linux so can’t use GDB. More than a debugger I need to log data, something like what CCP does.
I have a PICKit2 but it does not support runtime watch window update, only on breakpoints my watch variables be updated.
Has anyone tried using MODBUS RTU for runtime data logging ?
Transmit your data over a serial bus and log it at the computer end. Many micros come with a UART so RS-232 messages could be logged by simply directing the serial input to a file (you might need a USB to serial converter, such as the FTDI devices/leads/cable assemblies based on them). Or use CAN bus or any other serial protocol that you can get an interface to your computer with, and possibly write your own logger.