I am trying to write a binary to a STM32F413ZH Nucleo development board. I am running Windows 10.
I using the bare metal project examples from this github-page. I can succesfully compile any of the example projects but I can't write the binary to the microcontroller.
I am using the makefile which is included in the example projects. To build I write "make" and to write the binary I write "make burn". This gives the following error message:
$ make burn
st-flash 1.6.1
2020-10-21T17:06:17 INFO common.c: F1xx Medium-density: 20 KiB SRAM, 64 KiB flash in at least 1 KiB pages.
mmap() size_t overflow for file Debug/dac.bin
2020-10-21T17:06:17 ERROR common.c: map_file() == -1
stlink_fwrite_flash() == -1
make: *** [burn] Error -1
Can anyone explain why it doesn't work?
Related
When I try to run a simulation in SE mode in gem5 I get the following output:
warn: No dot file generated. Please install pydot to generate the dot file and pdf. build/RISCV/mem/mem_interface.cc:791: warn: DRAM device capacity (8192 Mbytes) does not match the address range assigned (512 Mbytes) 0: system.remote_gdb: listening for remote gdb on port 7000 build/RISCV/sim/simulate.cc:194: info: Entering event queue # 0. Starting simulation... build/RISCV/sim/mem_state.cc:443: info: Increasing stack size by one page. build/RISCV/sim/mem_state.cc:99: panic: Someone allocated physical memory at VA 0x4000000000000000 without creating a VMA! Memory Usage: 619616 KBytes Program aborted at tick 2222000
I'm using the ELF-linux cross compiler. Compiling with the Newlib-ELF cross compiler simulates just fine, but the thing is that I need to use pthreads(openmp) and the Newlib compilation doesn't support it. To get a grip on things I tried to simulate in x86, and found out that it wont work either with a simple gnu/gcc compilation. Then I complied replicating what the test-progs folder did with docker and then it worked fine. Is this the way to go? Since the error says there are problems with physical memory, would compiling with docker help out, or am I missing an obviuos fix? How would go about compiling RISCV with docker (I couldn't find examples of docker+RISCV)?
/Applications/CodeBlocks.app/Contents/MacOS/cb_console_runner DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:. /Users/leo1708/Desktop/C:C++ Code blocks/C programs/hello/bin/Debug/hello
leo1708#Deeps-Air ~ % /Applications/CodeBlocks.app/Contents/MacOS/cb_console_runner DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:. /Users/leo1708/Desktop/C:C++ Code blocks/C programs/hello/bin/Debug/hello
sh: /Users/leo1708/Desktop/C:C++: No such file or directory
Process returned 127 (0x7F) execution time : 0.009 s
I am getting the above error while compiling C programs in Code blocks on my Mac m1.
I don't know what happened I have made so many programs, now suddenly the program is not compiling and giving me this error.please help.
I compiled a C program using -m32 gcc option . I want to profile this program using a Pin tool . My kernel is 64 bit.
I have tried :-
1) pin -t64 <64-bit toolname> -t <32-bit toolname> -- <application>
2) pin -t <32-bit toolname> -- <application>
3) pin -t <64-bit toolname> -- <application>
I have the same .cpp tool file for both the tools compiled differently for 32 bit and 64 bit architectures.
Case 3 invoked an error 'unable to load .. Check the architecture type' .
Cases 1 and 2 , the command was successful but produced some unexpected output , for ex names of images written into a file is empty in this case but contains proper results when executed with a 64-bit application . Which is the correct way to set up the pin tool for this case?
well i found a workaround to compile the 32bit library of pin ( i mean instcount0 ) in 64bit arch.
i did modify the config file related to building the library.
i have pin located in /opt/ so , i edited
/opt/pin-3.0-76991-gcc-linux/source/tools/Config
at line 38
# Define the architecture of the target
# ; TARGET ?= $(HOST_ARCH)
TARGET = ia32
ifeq ($(TARGET),ia32)
BITS := 32
else
BITS := 64
endif
i just changed the target to ia32. works just fine after build .
There are a few caveats to know when starting a program under pin control:
1) The pintool must be compiled in the same architecture than the instrumented program (so, if your program is 32-bit, your pin tool must be 32-bit).
2) Ensure your system is setup to execute 32-bit programs on a 64-bit OS (some linux systems still need ia32-libs and / or need to be prepared for executing 32-bit programs (e.g. sudo dpkg --add-architecture i386)
3) Ensure you have all required libraries for PIN
4) Use pin.sh
Your command should be:
pin -t pintool.so -- <program> <program-options>
If you still have problems it is probably a problem with your pintool code rather than pin itself.
Did you tried one of the simple example (like inscount) on your program ?
Check the version of your PIN binary.
file PIN_DIR/pin
I downloaded PIN kit from this link. My PIN binary is 32-bit. If yours is 64-bit version, you can modify codes that check system architecture in pin.sh, and run
PIN_DIR/pin.sh
That should give you a 32-bit version PIN binary.
I'm trying to get a stand-alone application for U-Boot running.
Target is a LEGO EV3 brick - it has an TI OMAP (ARM9) CPU.
The output of U-Boot before hanging is:
U-Boot > fatload mmc 0:1 c0007FC0 uimage
reading uimage
384 bytes read
U-Boot > bootm
## Booting kernel from Legacy Image at c0007fc0 ...
Image Name: ITK EV3 sample OS
Image Type: ARM Linux Standalone Program (uncompressed)
Data Size: 320 Bytes = 0.3 kB
Load Address: c0008000
Entry Point: c0008000
Loading Standalone Program ... OK
OK
I tried the following commands to be located at address 0xC0008000 in "uimage":
mov pc, lr (ARM code)
bx lr (ARM code)
bx lr (Thumb code)
These commands should simply return (depending on ARM or Thumb mode being active). However all three commands result in U-Boot hanging so no more output is done after the last "OK".
Why does U-Boot hang?
I found out the answer myself:
In the version of u-boot used on the EV3 brick there is a bug: The starting address that is already converted to little-endian is converted twice so the result is - of course - wrong.
By storing the number little endian in the file the output of u-boot will be wrong:
Image Type: ARM Linux Standalone Program (uncompressed)
Data Size: 320 Bytes = 0.3 kB
Load Address: c0008000
Entry Point: 008000c0 <--- actually 0xC0008000!!!
Loading Standalone Program ... OK
OK
U-Boot >
however booting will work. This bug only affects stand-alone programs and not Linux kernels.
My problem is that the program will possibly be published so it must work with both buggy and bug-fixed u-boot versions.
Therefore I think about loading the program to an address like
0xC00101C0
which is stored little and big endian the same way.
I'm new with this and I am a little messed with it:
I'm trying to compile netcat source code for MIPS in order to deploy it in my router, what I do is:
Download the toolchain for mips: mips-linux-gcc
Download netcat source and expand it to a folder
cd path/to/netcatsource
Execute:
CC=path/to/compiler/mips-linux-gcc ./configure --host=mips-linux
make
The make command works fine and trying the file command over compiled netcat file displays:
file netcat
OUTPUT: ELF 32-bit MSB executable, MIPS, MIPS-I version 1 (SYSV), dynamically linked (uses shared libs), not stripped
For me everything seems fine, but if I execute ./netcat on my ubuntu box it works, and once I upload it to the router it displays the following error:
# ./netcat
Segmentation fault
This is the /proc/cpuinfo from my router:
# cat /proc/cpuinfo
system type : 963281T_TEF
processor : 0
cpu model : Broadcom4350 V7.5
BogoMIPS : 319.48
wait instruction : yes
microsecond timers : yes
tlb_entries : 32
extra interrupt vector : no
hardware watchpoint : no
ASEs implemented :
shadow register sets : 1
core : 0
VCED exceptions : not available
VCEI exceptions : not available
unaligned exceptions : 1395
Could anyone help me with this?
Regards
(I couldn't add a comment due to, I do not have enough points)
Try to static compile the source code
The problem may be happening because you do not have the necessary libraries on the router, maybe the binary is pointing to ld-linux.so and the router uses ld-uclibc.so. So try static build...
UPDATE
I recomend the buildroot toolchain, which by the way include netcat and many other tools like busybox