I have a custom boot loader program. The loader must be able to program any part of the flash, including upgrading itself. To accomplish this, the loader startup code copies the whole program from flash into RAM and then jumps to main().
The program works fine, but I can't get the debugger to set breakpoints. The specific error message that I get is "Unable to set requested breakpoint on target". Reading the state of variables and single stepping DOES seem to work.
How can I get the debugger to work in this setup?
Development Environment: Atmel Studio 7
Processor: ATSAME70 (This is an ARM Cortex M7)
Compiler: GCC
Tool: Atmel-ICE
Interface: SWD (Serial Wire Debug)
The relevant portions of the linker script look like this...
/* Memory Spaces Definitions */
MEMORY
{
rom (rx) : ORIGIN = 0x00400000, LENGTH = 0x00004000 /* rom, 2097152K */
ram (rwx) : ORIGIN = 0x20400000, LENGTH = 0x00060000 /* ram, 393216K */
}
SECTIONS
{
.reset : {
. = ALIGN(4);
KEEP("Device_Startup/startup.o"(.text))
KEEP(*(.reset_code))
} > rom
PROVIDE(_exit = .);
.text :
{
. = ALIGN(4);
_rom_to_ram_copy_vma_start = .;
KEEP(*(.vectors .vectors.*))
*(.text .text.* .gnu.linkonce.t.*)
...
...
_rom_to_ram_copy_vma_end = .;
} > ram AT > rom
_rom_to_ram_copy_lma_start = LOADADDR(.text);
}
The program coplies everthing between _rom_to_ram_copy_vma_start and _rom_to_ram_copy_vma_end into RAM and then jumps to main in RAM.
Given that I used "ram AT > rom" in the linker script one would think that the debugger should know that the code is in RAM and should have no problem setting the breakpoint there.
I'm trying to compile some C code to run on an ARMv6 simulator, with FLASH memory starting # 0x0 and RAM starting at 0x800000. Right now, I can pass binary files off the the simulator just fine...
However, I want the instructions generated to not include any writes to flash memory, and only operate within RAM memory (after copying RAM). Is this possible?
I am using the GNU toolchain to compile.
This is my current linker script:
MEMORY
{
rom(rx) : ORIGIN = 0x00000000, LENGTH = 0x00800000
ram(!rx) : ORIGIN = 0x40000000, LENGTH = 0x00800000
h : ORIGIN = 0x40000000, LENGTH = 0x00400000
}
SECTIONS
{
.text : { *(.text*) } > rom
.bss : { *(.bss*) } > ram
.heap : { *(.heap*) } > h
}
end = ORIGIN(h) + LENGTH(h);
_stacktop = ORIGIN(ram) + LENGTH(ram);
Your build linker script (normally a .ld file) determines the locations of your device's memory and how the linker sections are mapped to that. Your link map should not include writable sections in read-only memory, that will fail.
[Added after linker script added to question]
You linker script seems unusual in lacking a .data section:
.data : { *(.data) } > ram
Without that it is not clear what the linker will do with static initialised data.
Also your question states that the RAM starts at 0x800000, but the linker script clearly locates it at 0x40000000. Perhaps this misunderstanding of your memory map is leading you to erroneously believe that writes to the ROM region are occurring?
Windbg Command !dlls,Why in the !dlls -a command output, SECTION HEADER value are all 0?
The following is my walkthrough:
0:000> !dlls -a
0x00673270: D:\WinAfl\test\a.exe
Base 0x00400000 EntryPoint 0x00401280 Size 0x0000a000
Flags 0x00004000 LoadCount 0x0000ffff TlsIndex 0x0000ffff
LDRP_ENTRY_PROCESSED
File Type: EXECUTABLE IMAGE
FILE HEADER VALUES
14C machine (i386)
8 number of sections
50000 time date stamp Mon Jan 05 03:01:20 1970
2800 file pointer to symbol table
29C number of symbols
E0 size of optional header
307 characteristics
Relocations stripped
Executable
Line numbers stripped
32 bit word machine
Debug information stripped
OPTIONAL HEADER VALUES
10B magic #
2.24 linker version
1200 size of code
2400 size of initialized data
200 size of uninitialized data
1280 address of entry point
1000 base of code
3000 base of data
----- new -----
00400000 image base
1000 section alignment
200 file alignment
3 subsystem (Windows CUI)
4.00 operating system version
1.00 image version
4.00 subsystem version
A000 size of image
400 size of headers
C9C4 checksum
00200000 size of stack reserve
00001000 size of stack commit
00100000 size of heap reserve
00001000 size of heap commit
00400098 Opt Hdr
0 [ 0] address [size] of Export Directory
7000 [ 3CC] address [size] of Import Directory
0 [ 0] address [size] of Resource Directory
0 [ 0] address [size] of Exception Directory
0 [ 0] address [size] of Security Directory
0 [ 0] address [size] of Base Relocation Directory
0 [ 0] address [size] of Debug Directory
0 [ 0] address [size] of Description Directory
0 [ 0] address [size] of Special Directory
9004 [ 18] address [size] of Thread Storage Directory
0 [ 0] address [size] of Load Configuration Directory
0 [ 0] address [size] of Bound Import Directory
70C8 [ 8C] address [size] of Import Address Table Directory
0 [ 0] address [size] of Reserved Directory
0 [ 0] address [size] of Reserved Directory
0 [ 0] address [size] of Reserved Directory
SECTION HEADER #1
name
0 virtual size
0 virtual address
0 size of raw data
0 file pointer to raw data
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
0 flags
(no align specified)
SECTION HEADER #2
name
0 virtual size
0 virtual address
0 size of raw data
0 file pointer to raw data
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
0 flags
(no align specified)
SECTION HEADER #3
name
0 virtual size
0 virtual address
0 size of raw data
0 file pointer to raw data
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
0 flags
(no align specified)
SECTION HEADER #4
name
0 virtual size
0 virtual address
0 size of raw data
0 file pointer to raw data
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
0 flags
(no align specified)
SECTION HEADER #5
name
0 virtual size
0 virtual address
0 size of raw data
0 file pointer to raw data
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
0 flags
(no align specified)
SECTION HEADER #6
name
0 virtual size
0 virtual address
0 size of raw data
0 file pointer to raw data
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
0 flags
(no align specified)
SECTION HEADER #7
name
0 virtual size
0 virtual address
0 size of raw data
0 file pointer to raw data
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
0 flags
(no align specified)
SECTION HEADER #8
name
0 virtual size
0 virtual address
0 size of raw data
0 file pointer to raw data
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
0 flags
(no align specified)
0x00673300: C:\windows\SysWOW64\ntdll.dll
Base 0x77c60000 EntryPoint 0x00000000 Size 0x00180000
Flags 0x00004004 LoadCount 0x0000ffff TlsIndex 0x00000000
LDRP_IMAGE_DLL
LDRP_ENTRY_PROCESSED
File Type: DLL
FILE HEADER VALUES
14C machine (i386)
5 number of sections
598D4C81 time date stamp Fri Aug 11 14:19:45 2017
0 file pointer to symbol table
0 number of symbols
E0 size of optional header
2102 characteristics
Executable
32 bit word machine
DLL
OPTIONAL HEADER VALUES
10B magic #
9.00 linker version
D6200 size of code
68400 size of initialized data
0 size of uninitialized data
0 address of entry point
10000 base of code
F0000 base of data
----- new -----
77c60000 image base
10000 section alignment
200 file alignment
3 subsystem (Windows CUI)
6.01 operating system version
6.01 image version
6.01 subsystem version
180000 size of image
400 size of headers
146B93 checksum
00040000 size of stack reserve
00001000 size of stack commit
00100000 size of heap reserve
00001000 size of heap commit
77c600f0 Opt Hdr
101F8 [ F6B8] address [size] of Export Directory
0 [ 0] address [size] of Import Directory
110000 [ 5A028] address [size] of Resource Directory
0 [ 0] address [size] of Exception Directory
13D400 [ 3940] address [size] of Security Directory
170000 [ 4CB8] address [size] of Base Relocation Directory
E5E84 [ 38] address [size] of Debug Directory
0 [ 0] address [size] of Description Directory
0 [ 0] address [size] of Special Directory
0 [ 0] address [size] of Thread Storage Directory
75B50 [ 40] address [size] of Load Configuration Directory
0 [ 0] address [size] of Bound Import Directory
0 [ 0] address [size] of Import Address Table Directory
0 [ 0] address [size] of Reserved Directory
0 [ 0] address [size] of Reserved Directory
0 [ 0] address [size] of Reserved Directory
SECTION HEADER #1
name
0 virtual size
0 virtual address
0 size of raw data
0 file pointer to raw data
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
0 flags
(no align specified)
SECTION HEADER #2
name
0 virtual size
0 virtual address
0 size of raw data
0 file pointer to raw data
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
0 flags
(no align specified)
SECTION HEADER #3
name
0 virtual size
0 virtual address
0 size of raw data
0 file pointer to raw data
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
0 flags
(no align specified)
SECTION HEADER #4
name
0 virtual size
0 virtual address
0 size of raw data
0 file pointer to raw data
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
0 flags
(no align specified)
SECTION HEADER #5
name
0 virtual size
0 virtual address
0 size of raw data
0 file pointer to raw data
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
0 flags
(no align specified)
!dlls only work in live debugging mode
not in dump analysis
to dump just one module use -c { expression resolving to and address in some modules virtual address space }
see below the second query
0:000> lm m calc
Browse full module list
start end module name
00710000 007d0000 calc (deferred)
0:000> !dlls -c calc
0x001321c8: C:\Windows\system32\calc.exe
Base 0x00710000 EntryPoint 0x00722d6c Size 0x000c0000
Flags 0x00004000 LoadCount 0x0000ffff TlsIndex 0x00000000
LDRP_ENTRY_PROCESSED
0:000> !dlls -c 7c1234
0x001321c8: C:\Windows\system32\calc.exe
Base 0x00710000 EntryPoint 0x00722d6c Size 0x000c0000
Flags 0x00004000 LoadCount 0x0000ffff TlsIndex 0x00000000
LDRP_ENTRY_PROCESSED
!dlls -a in my windbg output more than 27k lines resolving all dependencies
0:000> .shell -ci "!dlls -a -c 7c1234" wc -l
27872
it outputs kernel32.dll 15 times
0:000> .shell -ci "!dlls -a -c 7c1234" grep -c -i kernel32.dll
15
I use STM32F417 with external 512*16 RAM under FreeRTOS. When I see a MAP file the address of used memory are still in the internal RAM.
RTOS Heap def:
> static unsigned char ucHeap[ 60*1024 ]__attribute__ > ((section(".ExRam")));
arm-gcc-link.ld file:
> rom (rx) : ORIGIN = 0x08000000, LENGTH = 0x00100000
> ram (rwx) : ORIGIN = 0x20000000, LENGTH = 0x00020000
>ram2 (rwx) : ORIGIN = 0x60000000, LENGTH = 0x00100000
>...
>ExRam (NOLOAD): { *(.ExRam.) } > ram2
>...
MAP File:
> .ExRam 0x60000000 0xf000
>*(.ExRam.)
>.ExRam 0x60000000 0xf000 ..\obj\heap_4.o
>
> .ARM.extab *(.ARM.extab * .gnu.linkonce.armextab.*)
> 0x6000f000 __exidx_start = .
Variable , Why not in 0x6000000 area?:
>.bss 0x200053ac 0x2c ..\obj\tcp_in.o
>.bss 0x200053d8 0x4 ..\obj\raw.o
>.bss 0x200053dc 0x10 ..\obj\ip_addr.o
>.bss 0x200053ec 0x100 ..\obj\ssl_ciphersuites.o
>.bss 0x200054ec 0x678 ..\obj\dns.o
>.bss 0x20005b64 0x8 ..\obj\lwip_timers.o
The heap is used by malloc to allocate memory dynamically, at run time. The linker creates the map file at build time, before your code is running. The linker knows only about variables that are defined at compile time. The linker has no knowledge of how the heap will be used at run-time. Therefore the map file cannot possibly itemize the variables that may be created in the heap.
The variables that are listed in the map file in the .bss and .data sections are defined at compile time and statically allocated. They don't appear in the heap because that is not what the heap is for.
OK,
I found that in the MAP file are not listed variables located in the extRAM heap. It means that object listed in RAM are lower size if there are variables located in the heap in extRAM but are not listed under heap address (0x6000000) same way like variables/object located in the internal RAM.
The GPU device that I have is GeForce GT 750M, which I found is compute capability 3.0. I downloaded the CUDA code found here: (https://github.com/fengChenHPC/word2vec_cbow. Its makefile had the flag -arch=sm_35.
Since my device is compute capability 3.0, I changed the flag to -arch=sm_30. It compiled fine, but when I run the code, I get the following error:
word2vec.cu 449 : unspecified launch failure
word2vec.cu 449 : unspecified launch failure
It shows it multiple times, because there are multiple CPU threads launching the CUDA kernel. Please note that the threads do not use different streams to launch the kernel, so the kernel launches are all in order.
Now, when I let the flag be, i.e. -arch=sm_35, then the code runs fine. Can someone please explain why the code won't run when I set the flag to match my device?
Unfortunately your conclusion that the code works when compiled for sm_35 and run on an sm_30 GPU is incorrect. The culprit is this:
void cbow_cuda(long window, long negative, float alpha, long sentence_length,
int *sen, long layer1_size, float *syn0, long hs, float *syn1,
float *expTable, int *vocab_codelen, char *vocab_code,
int *vocab_point, int *table, long table_size,
long vocab_size, float *syn1neg){
int blockSize = 256;
int gridSize = (sentence_length)/(blockSize/32);
size_t smsize = (blockSize/32)*(2*layer1_size+3)*sizeof(float);
//printf("sm size is %d\n", smsize);
//fflush(stdout);
cbow_kernel<1><<<gridSize, blockSize, smsize>>>
(window, negative, alpha, sentence_length, sen,
layer1_size, syn0, syn1, expTable, vocab_codelen,
vocab_code, vocab_point, table, table_size,
vocab_size, syn1neg);
}
This code will silently fail if the kernel launch fails because of incomplete API error checking. And the kernel launch does fail if you build for sm_35 and run on sm_30. If you change the code of that function to this (adding kernel launch error checking):
void cbow_cuda(long window, long negative, float alpha, long sentence_length,
int *sen, long layer1_size, float *syn0, long hs, float *syn1,
float *expTable, int *vocab_codelen, char *vocab_code,
int *vocab_point, int *table, long table_size,
long vocab_size, float *syn1neg){
int blockSize = 256;
int gridSize = (sentence_length)/(blockSize/32);
size_t smsize = (blockSize/32)*(2*layer1_size+3)*sizeof(float);
//printf("sm size is %d\n", smsize);
//fflush(stdout);
cbow_kernel<1><<<gridSize, blockSize, smsize>>>
(window, negative, alpha, sentence_length, sen,
layer1_size, syn0, syn1, expTable, vocab_codelen,
vocab_code, vocab_point, table, table_size,
vocab_size, syn1neg);
checkCUDAError( cudaPeekAtLastError() );
}
and compile and run it for sm_35, you should get this on an sm_30 device:
~/cbow/word2vec_cbow$ make
nvcc word2vec.cu -o word2vec -O3 -Xcompiler -march=native -w -Xptxas="-v" -arch=sm_35 -lineinfo
ptxas info : 0 bytes gmem
ptxas info : Compiling entry function '_Z11cbow_kernelILx1EEvllflPKilPVfS3_PKfS1_PKcS1_S1_llS3_' for 'sm_35'
ptxas info : Function properties for _Z11cbow_kernelILx1EEvllflPKilPVfS3_PKfS1_PKcS1_S1_llS3_
0 bytes stack frame, 0 bytes spill stores, 0 bytes spill loads
ptxas info : Used 34 registers, 448 bytes cmem[0], 8 bytes cmem[2]
~/cbow/word2vec_cbow$ ./word2vec -train text8 -output vectors.bin -cbow 1 -size 200 -window 7 -negative 1 -hs 1 -sample 1e-3 -threads 1 -binary 1 -save-vocab voc #> out 2>&1
Starting training using file text8
Vocab size: 71290
Words in train file: 16718843
vocab size = 71290
cbow.cu 114 : invalid device function
ie. the kernel launch failed because no appropriate device code was found in the CUDA cubin payload in your application. This also answers your earlier question about why the output of this code is incorrect. The analysis kernel simply never runs on your hardware when built with the default options.
If I build this code for sm_30 and run it on a GTX 670 with 2gb of memory (compute capability 3.0), I get this:
~/cbow/word2vec_cbow$ make
nvcc word2vec.cu -o word2vec -O3 -Xcompiler -march=native -w -Xptxas="-v" -arch=sm_30 -lineinfo
ptxas info : 0 bytes gmem
ptxas info : Compiling entry function '_Z11cbow_kernelILx1EEvllflPKilPVfS3_PKfS1_PKcS1_S1_llS3_' for 'sm_30'
ptxas info : Function properties for _Z11cbow_kernelILx1EEvllflPKilPVfS3_PKfS1_PKcS1_S1_llS3_
0 bytes stack frame, 0 bytes spill stores, 0 bytes spill loads
ptxas info : Used 34 registers, 448 bytes cmem[0], 12 bytes cmem[2]
~/cbow/word2vec_cbow$ ./word2vec -train text8 -output vectors.bin -cbow 1 -size 200 -window 7 -negative 1 -hs 1 -sample 1e-3 -threads 1 -binary 1 -save-vocab voc #> out 2>&1
Starting training using file text8
Vocab size: 71290
Words in train file: 16718843
vocab size = 71290
Alpha: 0.000009 Progress: 100.00% Words/thread/sec: 1217.45k
ie. the code runs correctly to completion without any errors. I can't tell you why you are not able to get the code to run on your hardware because I cannot reproduce your error on my hardware. You will need to do some debugging on your own to find the root cause of that.
As this LINK shows there is no GeForce GTX 750M.
yours is either:
GeForce GTX 750 Ti
GeForce GTX 750
or
GeForce GT 750M
If yours is one of the first two then your GPU is Maxwell-based and has Compute Capability = 5.0.
Otherwise, your GPU is Kepler based and has Compute Capability = 3.0.
If you're not sure what your GPU is, first figure it out by running deviceQuery from the NVIDIA SAMPLE.