I am currently using IAR EWARM 9.10 to develop an application for Kinetis K66. I am in the process of debugging a hard fault and I noticed that when I inspected certain locations - using EWARM's memory view - in the K66 Flash, the contents were reported as double dashes ('--'). How should I be interpreting this?
Example attached...
The dashes (-) in the Memory visualization window means unmapped memory.
In a Kinetis device where the installed Flash memory ends at 0x000FFFFF, the "Memory 1" window shows up like this on the end of the region:
For the Kinetis devices, the flash memory available for the user's code is discontiguous and within 0x0000_0000~0x0000_03FF | 0x0000_0410~END_OF_FLASH.
This is due a "flash configuration" region (0x0000_0400~0x0000_040F) reserved for the FlashConfig section.
For a similar device, using IAR EWARM 9.30:
Related
so when I connect my development board (NUCLEO-f446re) to my laptop , everything is working normally , but there is only one thing that confuses me , see the next picture
windows recognize my development board as external storage device with 1.52 MB size (partition named NODE_F446RE(E:))
when I open it , the next image show what I see
there is only 2 files there , the .HTM file takes me to this link and the .TXT file has the follow content:
Version: V2J40M27
Build: May 5 2022 13:16:48
so I don't understand what does this mean ?, like what does 1.5MB storage represent in my MCU even though , the flash size of my MCU is only 512 KB which is way less than the shown storage , also what happens if I put any .exe file in that partition ?
From the web page you link (emphasis by me):
USB re-enumeration capability: three different interfaces supported on USB
Virtual Com port
Mass storage (USB Disk drive) for drag'n'drop programming
Debug port
Your board offers the option to program your application. Simply drap and drop the bin (binary) file of the application into this drive.
It is "just" a virtual drive, the software behind it does the flashing for you, if it receives a binary file.
Why the size of the drive is bigger than the available flash memory, is not clear. Perhaps to allow for necessary overhead to mimic a file system, and to have room for the files you see.
If you copy an exe file in it, I'd expect some kind of error message. Or that the file will not be stored. Experiment!
This functionality is perhaps not well documented, but is part of the "Mbed Enabled" functionality. It is a feature of the Mbed bootloader, to allow "drag'n'drop programming" via a "fake" mass storage device in order to avoid the need for special programming tools or protocols.
You can write to the device, but the "file" will not appear in the filesystem, rather the content will be used to program the on-chip flash memory.
The files on the fake drive are read-only - mbed.htm will open in a browser and take you to the Mbed sign-up/login where you can start developing using Mbed. details.txt contains details of the mbed firmware pre-loaded on the board.
At one time the Mbed on-line/in-browser IDE lacked hardware programming and debug capability, so this feature was the primary means of programming Mbed boards, and debugging was painful. I believe all that has changed now and the feature is perhaps less important in development.
https://os.mbed.com/platforms/ST-Nucleo-F446RE/
As announced at WWDC 2015, Clang Address Sanitizer is being brought to Xcode and OS X.
Session 413: Advanced Debugging and the Address Sanitizer
How do you enable Clang Address Sanitizer for your Xcode project?
Address Sanitizer has been added as a new feature in Xcode 7.
Use the Runtime Sanitization > Enable Address Sanitizer flag in your scheme to enable the option.
git will then shown this change to your .xcscheme file:
enableAddressSanitizer = "YES"
From the New Features in Xcode 7 document:
Address Sanitizer. Xcode 7 can build your app with instrumentation designed to catch and debug memory corruption using the address sanitizer.
Objective-C and C code is susceptible to memory corruption issues such as stack and heap buffer overruns and use-after-free issues. When these memory violations occur, your app can crash unpredictably or display odd behavior. Memory corruption issues are difficult to track down because the crashes and odd behavior are often hard to reproduce and the cause can be far from the origin of the problem.
You enable the address sanitizer in the build scheme. Once enabled, added instrumentation is built into the app to catch memory violations immediately, enabling you to inspect the problem right at the place where it occurs. Other diagnostic information is provided as well, such as the relationship between the faulty address and a valid object on the heap and allocation/deallocation information, which helps you pinpoint and fix the problem quickly.
Address sanitizer is efficient—fast enough to be used regularly, as well as with interactive applications. It is supported on OS X, in the Simulator, and on iOS devices.
I have a custom bios ( I actually have the image of the SPI Flash Bios, but in my opinion it should be the same ) and I would like to debug with GDB. Is it possible to run with GDB ? I know where there is the first executed instruction ( 0h3FFFF0 ) inside the file, and the files it should be a sequence of assembler instruction. Is there a way to follow the flow and run step by step the bios ?
First, it's incorrect to assume that SPI image will contain only BIOS executable. It usually much more then that (ie. ME, Setup parameters, flash descriptor). To investigate what is inside your image I suggest to use binwalk <spi_image>, if you will be lucky, it will detect layout of your image. Then you can extract image parts by binwalk -e <spi_image>.
Second, since I don't know if we talk about modern hardware or some obsolete I will try to be general. I don't think GDB is able to run BIOS binary because those binaries doesn't contain any debugging information that GDB can understand. GDB need to know what executable file it deals with, what is the ABI used and what is the physical architecture of target being debugged. Even if it will know all those information the code could be only disassembled because BIOS starts with low level hardware initialization, which cannot be recreated in GDB. On the other hand modern hardware BIOS (UEFI firmware) is typically signed.
What is the best thing you can do with extracted BIOS binary is to get datasheet of your hardware and use disassembler like IDA Pro or radare2 to investigate code flow.
Is there any memory debugger for linux kernel?
We have issues with "NULL pointer dereference" kernel oops among other crashes on android/linux arm based hardware.
Thanks
Modern kernels contain a great deal of built-in diagnostic tools (those are available in "Kernel hacking" sub-menu of the kernel source configuration tool). However, on embedded targets one has also an option of using gdb with a good jtag debugger, such as Abatron BDI series (this will, of course, allow for the most precise diagnostics, including diagnostics of interrupt related problems).
In the absence of hardware debugger, the following options can be quite handy to detect memory leaks (don't forget to compile the kernel with "Compile the kernel with debug info" and "Compile the kernel with frame pointers" set):
Kernel memory leak detector - useful in catching kmalloc/kfree errors.
KGDB (with suboptions) - this will enable a built-in gdb server inside the kernel, which can be accessed from a gdb front-end over a serial port. There's also a KGDB_KDB option to do the same manually (by omitting the gdb front end and using a human manageable protocol).
kmemcheck - requires the least of human interaction and the most machine resources, but can be handy in doing initial memory related problem analysis.
There are plenty of other diagnostics options, useful with more specific classes of problems. Most of them are reasonably documented both with kernel configuration tool snippets as well as with separate documents in Documentation/ sub-directory of the source (+ various online publications).
If a Windows application has the IMAGE_FILE_LARGE_ADDRESS_AWARE set in the image header (via the /LARGEADDRESSAWARE compiler flag), this is typically to allow a 32-bit application to use more than 2GB of memory (only makes sense if the 32-bit Operating System has set the 3GB switch in boot.ini). See MSDN article /3GB for more info.
My questions is, what happens if you run this application on a system that does NOT have the 3GB switch set. Is it simply ignored? Or will the app try and use a 3GB heap and get out-of-memory errors because the userspace only has 2GB available?
I keep hearing anecdotally that the LARGEADDRESSAWARE switch is ignored for 2GB userspace systems but cannot find any official Microsoft documentation on this.
Thanks in advance.
Basically the IMAGE_FILE_LARGE_ADDRESS_AWARE tells the system, "I know that addresses with the high bit set are not negative, and can handle them".
If the system is prepared to provide user mode addresses above 2GB, then it will. If the system is not prepared to give those addresses (ie., a 32-bit Windows OS without the /3GB setting), the process can't get those addresses anyway - but no harm done.
Also note that if an image has the IMAGE_FILE_LARGE_ADDRESS_AWARE bit set it will get access to address space above 2GB on Win64 systems, which do not support (or need) the /3GB switch. A 32-bit application will get an address space of something close to 4GB and a 64-bit application will get a huge address space - 7TB to 8TB depending on the platform (64-bit builds set the bit by default).
http://msdn.microsoft.com/en-us/library/aa366778.aspx#memory_limits
The switch is ignored, if you can call it that. For once, Microsoft actually managed to come up with a descriptive name.
The flag means exactly what it says. This image file is aware that large addresses exist.
That is, it won't crash, if it is given a pointer above the 2GB boundary.
And that's all. The OS doesn't have to treat the process special in any way. It simply indicates that if the OS is able to provide more than 2GB memory, this process can handle it without crashing.
You can make a simple hello world application which never uses more than 1.5MB, and still has this flag set. It doesn't mean "I want to use 3GB of memory", it means "When I request memory, I don't care if it's above or below the 2GB boundary".
So since the flag doesn't require the OS to do anything special, the OS simply won't do anything special if there is nothing special it can do.