I wrote a simple code :
start:
ldi r16,12
ldi r17,-56
rjmp start
I want to see the values of r16 and r17 in bits in ATMELStudio7
how is it possible?
thanks
I think the easiest way is to use a debugger like a JTAGICE3. This device is a programming device and a debugging device which is useful when you want to check internal memories of the processor like registers, RAM, EEPROM, Flash, etc. You can also single-step through your program to watch the results of your operations.
You can check this video for more information.
A more advanced technique is to use some sort of an interface to visualize the contents of your registers, like the USART to send the data to your PC. But imho this is not very beginner friendly.
Related
I am using the GCC toolchain and the ARM Cortex-M0 uC. I would like to ask if it is possible to define a space in the linker so that the reading and writing operations would call the external device driver functions for reading and writing it's space (eg. SPI memory). Can anyone give some hints how to do it?
Regards, Rafal
EDIT:
Thank you for your comments and replies. My setup is:
The random access SPI memory is connected via SPI controller and I use a "standard" driver to access the memory space and store/read data from it.
What I wanted to do is to avoid calling the driver's functions explicitly, but to hide them behind some fixed RAM address, so that any read of that address would call the spi read memory driver function and write would call the spi write memory function (the offset of the initial address would be the address of the data in the external memory). I doubt that it is at all possible in the uC without the MMU, but I think it is always worth to ask someone else who might have had similar idea.
No, this is not how it works. Cortex-M0 has no memory management Unit, and is therefore unable to intercept accesses to specific memory regions.
It's not really clear what you are trying to achieve. If you have connected SPI memory external to the chip, you have to perform all the accesses using a driver, it is not possible to memory map the SPI port abstraction.
If this is an on-device SPI memory controller, it will have two regions in the memory map. One will be the 'memory'region, and will probably behave read-only, one with be the control registers for the memory controller hardware, and it is these registers which the device driver talks to. Specifically, to write to the SPI, you need to perform driver accesses to perform the write.
In the extreme case, (for example Cortex-M1 for Xilinx), there will be an eXecute In Place (XIP) peripheral for the memory map behaviour, and a SPI Master device for the read/write functionality. A GPIO pin is used to multiplex the SPI EEPROM pins between 'memory mode' and çonfiguration mode'.
I am at moment having some problems storing an image generated in the PS part of my Zynq into the DDR3 of my board, and then read that image into the PL side of the board such that the VGA driver created there can
The PS creates a 640x480 image, which ideally i want to store in the Dram.
I've until now used the DMA to transfer the data back and forth and store it as in some way (not storing all pixels) into the block ram of my system. but that isn't a ideal solution and I know so too..
So my question is how do i access the DDR ram of my zynq board, i know it is located on the PS side, but cant seem to find any documentation explaining how it should be interfaced and so..
Usually on zynq you try to use Axi interface for the data.
You can use that by the interconnects and the adress.
In Vivado you have right of the block design diagram a tab called "Address Editor".
In my case a simple test application (axi dma with fifo) is used.
I configured the axi dma to the base address "0x4040_0000" Range of 64K so the High Adress is "0x4040_FFFF".
In The SDK you can access this memory via a C/C++ program.
Here is a short AXI DMA example:
axi dma example
This example was written for the zedboard but I tried it with the z-turn 7020 board and it worked in Vivado 2014.4 and 2016.1.
I hope this helps you.
I'm using Intel's Pin Tool to do some binary instrumentation, and was wondering if there an API to get the instruction byte code at a given address.
Something like:
instruction = getInstructionatAddr(addr);
where addr is the desired address.
I know the function Instruction (used in many of the simple/manual examples) given by Pin gets the instruction, but I need to know the instructions at other addresses. I perused the web with no avail. Any help would be appreciated!
CHEERS
wondering if there an API to get the instruction byte code at a given
address
Yes, it's possible but in a somewhat contrived way: with PIN you are usually interested in what is executed (or manipulated through the executed instructions), so everything outside the code / data flow is not of any interest for PIN.
PIN is using (and thus ships with) Intel XED which is an instruction encoder / decoder.
In your PIN installation you should have and \extra folder with two sub-directories: xed-ia32 and xed-intel64 (choose the one that suits your architecture). The main include file for XED is xed-interface.h located in the \include folder of the aforementioned directories.
In your Pintool, given any address in the virtual space of your pintooled program, use the PIN_SafeCopy function to read the program memory (and thus bytes at the given address). The advantage of PIN_SafeCopy is that it fails graciously even if it can't read the memory, and can read "shadowed" parts of the memory.
Use XED to decode the instruction bytes for you.
For an example of how to decode an instruction with XED, see the first example program.
As the small example uses an hardcoded buffer (namely itext in the example program), replace this hardcoded buffer with the destination buffer you used in PIN_SafeCopy.
Obviously, you should make sure that the memory you are reading really contains code.
AFAIK, it is not possible to get an INS type (the usual type describing an instruction in PIN) from an arbitrary address as only addresses in the code flow will "generate" an INS type.
As a side note:
I know the function Instruction (used in many of the simple/manual
examples) given by Pin gets the instruction
The Instruction routine used in many PIN example is called an "Instrumentation routine": its name is not relevant in itself.
Pin_SafeCopy may help you. This API could copy memory content from the address space of target process to one specified buffer.
any apps or the system kernel can access or even modify the content of CPU cahce and/or TLB?
I found a short description about the CPU cache from this webiste:
"No programming language has direct access to CPU cache. Reading and writing the cache is something done automatically by the hardware; there's NO way to write instructions which treat the cache as any kind of separate entity. Reads and writes to the cache happen as side-effect to all instructions that touch memory."
From this message, it seems there is no way to read/write the content of CPU cahce/TLB.
However, I also got another information that conflicts with the above one. That information implies that a debug tool may be able to dump/show the content of CPU cache.
Currently I'm confused. so please help me.
I got some answers from another post: dump the contents of TLB buffer of x86 CPU. Thanks adamdunson.
People could read this document about test registers, but it is only available on very old x86 machines test registers
Another descriptions from wiki https://en.wikipedia.org/wiki/Test_register:
A test register, in the Intel 80486 processor, was a register used by
the processor, usually to do a self-test. Most of these registers were
undocumented, and used by specialized software. The test registers
were named TR3 to TR7. Regular programs don't usually require these
registers to work. With the Pentium, the test registers were replaced
by a variety of model-specific registers (MSRs).
Two test registers, TR6 and TR7, were provided for the purpose of
testing. TR6 was the test command register, and TR7 was the test data
register. These registers were accessed by variants of the MOV
instruction. A test register may either be the source operand or the
destination operand. The MOV instructions are defined in both
real-address mode and protected mode. The test registers are
privileged resources. In protected mode, the MOV instructions that
access them can only be executed at privilege level 0. An attempt to
read or write the test registers when executing at any other privilege
level causes a general protection exception. Also, those instructions
generate invalid opcode exception on any CPU newer than 80486.
In fact, I'm still expecting some similar functions on Intel i7 or i5. Unfortunately, I do not find any related document about that. If anyone has such information, please let me know.
(I'm primarily interested in x86 architectures, but would be interested to hear if there's a way to do this in other architectures also)
Is there any way to programmatically check the state of a cache line containing a certain memory address? I don't want to read the contents of that address, and don't want the penalty of reading from main memory incurred from a cache miss, I just want to check the state of the cache line.
And is there any way to programmatically revalidate an invalid cache line without writing through to memory? (well, I guess with MESI, by "revalidate" I mean change its state to "Modified")
The only thing I can think of is to use the PREFETCH optimization hint. So, instead of:
mov eax, (DWORD PTR [esi])
You would do:
prefetch [esi]
;
; give processor time to load cacheline...
;
mov eax, (DWORD PTR [esi])
Fundamentally I think what you're trying to do is flawed. If you were running on a custom single-tasking operating system it might work, but on today's modern multi-tasking systems it's simply impossible to control the processor like that.
Cache is completely invisible to programmer. Programmer works with virtual addresses while cache work with physical addresses.