cortex-m

Recently I've been trying to do FFT calculations on my STM32F4-Discovery evaluation board then send it to PC. I have looked into my problem - I think that I'm doing something wrong with FFT functions provided by manufacturer. I'm using CMSIS-DSP libraries. For now I've have been generating samples with code (if that works correct I'll do sampling by microphone). I'm using arm_rfft_fast_f32 as my data are going to be floats in the future, but results I get in my output array are insane (I think) - I'm getting frequencies below 0. number_of_samples = 512; (l_probek in code) dt = 1/freq/number_of

I'm trying to write a proof of concept in C that demonstrates code execution from a memory buffer in the stack on an ARM Cortex-M3. This will be useful to demonstrate that using the ARM MPU correctly can prevent such an attack. I figured a quick and dirty way to get some code into the stack is to copy it from a regular function and then use a goto to jump to it like so: static void loopit(void) { printf("loopit\n"); while (1); } void attack(void) { uint8_t buffer[64] __attribute__((aligned(4))); memcpy(buffer, loopit, sizeof(buffer)); goto *((void *) (int) buffer); } I would expect that when I

My project has started experiencing a problem in which the SysTick rate is usually, but not always set too fast. I have not changed the code that is relevant, and it seems to be temperature-related. I am using an STM32F072B-DISCOVERY board, with VisualGDB on Visual Studio Community 2015. My initialization code includes the following function: void Setup_Init_Clocks() { // Set up 48 MHz Core Clock using HSI (8Mhz) with PLL x 6 RCC_PLLConfig(RCC_PLLSource_HSI, RCC_PLLMul_6); RCC_PLLCmd(ENABLE); // Wait for PLLRDY after enabling PLL. while (RCC_GetFlagStatus(RCC_FLAG_PLLRDY) != SET) { } RCC

I found a couple of places online which state that CLREX "must" be called whenever an interrupt routine is entered, which I don't understand. The docs for CLREX state (added the numbering for easier reference): (1) Clears the local record of the executing processor that an address has had a request for an exclusive access. (2) Use the CLREX instruction to return a closely-coupled exclusive access monitor to its open-access state. This removes the requirement for a dummy store to memory. (3) It is implementation-defined whether CLREX also clears the global record of the executing processor that

I am trying to retrieve the return address of an IRQ handler in my code. My aim is to save the value of the PC just before the watchdog timer expires and before the reset for debug purposes, using WDT_IRQHandler(). I am also testing this approach with other IRQs to check if I grasped the idea. But it seems I haven't. I have read the documentation available. I understood that when an exception happens, 8 registers are pushed to the stack: R0, R1, R2, R3, R12, LR, PC and XPSR. I have also read that the stack is automatically double word aligned. So in my mind, retrieving the return address is as

I'm trying to debug an embedded project using remote GDB. My system: Target: ARM Cortex M0. SEGGER J-Link GDB Server V6.10 Command Line Version arm-none-eabi-gdb 7.10.1.20160616-cvs CLion 2016.2.2, Build #CL-162.1967.7 Ubuntu 16.04 I have the following in my .gdbinit file: target remote localhost:2331 #(I remove this line when debugging with CLion) set verbose on file "/path_to_output_file/blinky.elf" monitor reset break main The thing that has troubled me for days now, is that this works fine if I debug with gdb directly from a terminal, but not when I use the debugger in CLion. In CLion I