Running Gmp on Stm32f4 discovery board - microcontroller

I discover the stm32f4 discovery board.
For the moment I'm able to use leds, button, and to communicate through serial port.
I'm now trying to use the Gmp library on this board.
I build the arm-none-eabi toolchain following these instructions: https://blog.tan-ce.com/gcc-bare-metal/
I configure Gmp with the following options:
./configure CC=arm-none-eabi-gcc CFLAGS="-nostartfiles --specs=nosys.specs -g" --host=arm-none-eabi --disable-assembly
My project compiles and links without any issue, but
when I try to initialise an mpz_t on the board with the following code:
mpz_t a;
mpz_init_set_str(a, "31", 10);
I fall into the HardFault_Handler (), my arm-none-eabi-gdb gives me:
(gdb) bt
#0 HardFault_Handler () at ./src/stm32f4xx_it.c:34
#1 <signal handler called>
#2 0x08016ade in __gmpn_fft_best_k (n=134358201, sqr=134358201) at mul_fft.c:151
#3 0x0801816e in __gmpn_mul_fft (op=0x80006f5 <HardFault_Handler>, pl=134219497, n=0x8022471 <Reset_Handler>, nl=537001984, m=0x80224b9 <WWDG_IRQHandler>, ml=134358201, k=134358201) at mul_fft.c:870
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
If someone has already run Gmp on a microcontroller I am very interested in the way to do it !

I finally found the solution, the cortex type must be specified.
For the stm32f4, add -mcpu=cortex-m4 to the CFLAGS solve the problem.
I use the toolchain available here: arm-none-eabi toolchain
The whole configuration command is:
./configure CC=arm-none-eabi-gcc CFLAGS="-nostartfiles --specs=nosys.specs -mcpu=cortex-m4" --host=arm-none-eabi --disable-assembly --prefix=your-bare-metal-gmp-location
where "your-bare-metal-gmp-location" is the installation directory (you must not install a bare metal library in the classical /usr/local).

Related

How to compile and flash attiny88 with arduino-cli?

I can't understand, what device-name I should use for attiny88? For example, string for my old nano was arduino:avr:nano:cpu=atmega328old
I installed cores for attiny in arduino-cli, and test this board in ArduinoIDE and it works well, but I want to use arduino-cli.
(Sorry for my English)
Found the solution, this string named as FQBN. And I can get this FQBN for all my boards after exec command arduino-cli board listall

HCI_UART on NRF52840, attaching the device on a Yocto based Linux SBC errors out saying "Can't init device hci0: Cannot assign requested address (99)"

I am trying to Interface a BLE module based on Nordic's nrf52840 to a Yocto based SBC, to which all the BlueZ related packages have been added.
I have flashed Zephyr's sample hci_uart program onto the module. The module seems to run perfectly on my Linux PC (BlueZ version 5.48), whereas on the SBC(BlueZ version 5.54) it fails to get inited. Here's the error that comes when I use
root#rb-imx6:~# hciconfig hci0 up
root#rb-imx6:~# Can't init device hci0: Cannot assign requested address (99)
Can anyone please help me out on this?
Thanks in advance.
The error of assigning an address is caused by missing Linux kernel configuration options:
CONFIG_CRYPTO_USER
CONFIG_CRYPTO_USER_API
CONFIG_CRYPTO_USER_API_AEAD
CONFIG_CRYPTO_USER_API_HASH
CONFIG_CRYPTO_AES
CONFIG_CRYPTO_CCM
CONFIG_CRYPTO_AEAD
CONFIG_CRYPTO_CMAC
This is likely to happen with a self-built Buildroot or Yocto Embedded Linux system. If you run into this error, you should enable above options and recompile the kernel.
See the BlueZ requirements here: https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/README#n64
To see detailed debug output from BlueZ, run it with -d option:
bluetoothd -d

Ardino-Nano-BLE-Sense "Send Data With Sound" Chirp Project Issue

I am having some issues with the Send Data with Sound Project on Arduino. I have my Arduino nano BLE sense, ChirpSDK by Asio Ltd Version 3.4.0 installed, I put in the CHIRP_APP_KEY, CHIRP_APP_SECRET, CHIRP_APP_CONFIG from the chirp website, and I also have the Arduino nano BLE board selected when uploading the code. But for some reason I keep getting this error below:
ChirpColor:22:10: error: chirp_connect.h: No such file or directory
#include "chirp_connect.h"
^~~~~~~~~~~~~~~~~
compilation terminated.
exit status 1
chirp_connect.h: No such file or directory
Any help would be very much appreciated, thanks.
The SDK functions have been renamed in the latest release. So connect is replaced with sdk.
With the latest version, you need to
#include "chirp_sdk.h"
See the latest header file for the function declarations - https://github.com/chirp/chirp-arduino/blob/develop/src/chirp_sdk.h

How to use Intel Pin on MPI code

I am pretty new to MPI and Intel Pin. I already installed pin-2.13-62732-gcc.4.4.7-linux on my linux environment, I need t use this tool on MPI codes. foreexample I want to get the number of instruction(such as inscount0 which is already existed in pin) of MPI code (like imul.c). Would you tell me what I can do?
The least painful way I found is to use tau_pin. https://www.cs.uoregon.edu/research/tau/docs/old/re39.html
You can start analysis of your MPI application following way:
mpirun –np $NPROCS pin -t $PIN_TOOL -- $APP
It the same as in case of Valgrind: Using valgrind to spot error in mpi code

Is it possible to debug core file generated by a executable compiled without gdb flag?

Is it possible to debug core file generated by a executable compiled without gdb flag ?
If yes, any pointers or tutorials on it ?
Yes you can. It will not be easy though. I will give you an example.
Lets say that I have the following program called foo.c:
main()
{
*((char *) 0) = '\0';
}
I'll compile it and make sure that there is no symbols:
$ cc foo.c
$ strip a.out
$ file a.out
a.out: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, stripped
Ok, time to run it:
$ ./a.out
Segmentation fault (core dumped)
Oops. There seems to be a bug. Let's start a debugger:
$ gdb ./a.out core
[..]
Reading symbols from /tmp/a.out...(no debugging symbols found)...done.
[..]
Core was generated by `./a.out'.
Program terminated with signal 11, Segmentation fault.
#0 0x0804839c in ?? ()
(gdb) bt
#0 0x0804839c in ?? ()
#1 0xb7724e37 in __libc_start_main () from /lib/i386-linux-gnu/libc.so.6
#2 0x08048301 in ?? ()
Hmm, looks bad. No symbols. Can we figure out what happened?
(gdb) x/i $eip
=> 0x804839c: movb $0x0,(%eax)
Looks like it tried to store a byte with a value of zero to the memory location pointed by the EAX register. Why did it fail?
(gdb) p $eax
$1 = 0
(gdb)
It failed because the EAX register is pointing to a memory address zero and it tried to store a byte at that address. Oops!
Unfortunately I do not have pointers to any good tutorials. Searching for "gdb reverse engineering" gives some links which have potentially helpful bits and pieces.
Update:
I noticed the comment that this is about debugging a core dump at a customer. When you ship stripped binaries to a customer, you should always keep a debug version of that binary.
I would recommend not stripping and even giving the source code though. All code that I write goes to a customer with the source code. I have been on the customer side too many times facing an incompetent vendor which has shipped a broken piece of software but does not know how to fix it. It sucks.
This seems to be actually a duplicate of this question:
Debug core file with no symbols
There is some additional info there.
Yes, you can,
this is what people who i.e. write cracks are doing,
unfortunately i don't have the slides and documents of a course i followed at university anymore, but googling for reverse engineering or disassembly tutorials will give you some starting points. Also knowing your way around in assembly code is essential.
Our class was based on a book mainly chapter 1 & 3 but there is a new edition out now
Computer Systems: A programmer's perspective by R.E. Bryant and D.R. O'Hallaron
which explains the basics behind computer systems and also gives you good knowledge of the working of programs in systems.
Also when learning this be aware that 64bit cpus have different assembly code than 32bit cpu's, just in case.
If the program is compiled without -g flag,you cannot debug core file.
Otherwise you can do so as:
gdb executable corefile
More you can find at:
http://wwwpub.zih.tu-dresden.de/~mlieber/practical_debugging/04_gdb.pdf

Resources