RCC_APB2ENR = (unsigned int*)(0x40021000 + 0X18) // Assigning RCC_APB2ENR to the correct memory location GPIO_A_BRR = GPIO_A + 0X14 // Assigning GPIO_A_BSRR to the correct memory location GPIO_A_BSRR = GPIO_A + 0X10 // Assigning GPIO_A_BSRR to the correct memory location GPIO_A_IDR = GPIO_A + 0X08 // Assigning GPIO_A_IDR to the correct memory location */
GPIO_A_CRL = GPIO_A + 0x00 // Assigning GPIO_A_CRL to the correct memory location GPIO_A = (unsigned int*)0x40010800 // Assigning GPIOA to the correct memory location Why is stm assigning the wrong addresses when i used pointers to specify the memory locations, or could there be any other mistakes. i connected the led across a 10k resistor.
#Rom memory variable in keil mdk arm code#
My code is a simple program to blink the led at portA1. but the st-link upload seems to upload the hex file to the worng addresses for example :īut stlink shows the device data range from 0x0800 0000 to 0x0800 03d4. I wrote directly to the memory addresses using information from the datasheet.
If I take your code, make it shorter, don't have all day.I have written my code for stm32f103c8t6 board in keil using tha adequate startup files. Void PUT32 ( unsigned int, unsigned int ) įor (volatile unsigned int i=0 i Īrm-none-eabi-objcopy -O binaryĪrm-none-eabi-gcc -Wall -Werror -O2 -nostdlib -nostartfiles -ffreestanding -mthumb -mcpu=cortex-m3 -march=armv7-m -c notmain.c -o Īrm-none-eabi-ld -o -T flash.ld flash.o test.o Īrm-none-eabi-objdump -D > Īrm-none-eabi-objcopy -O binary This second answer is a demonstration of the kinds of things that would affect the performance results the OP may be seeing and examples of to possibly test for those STM32F103C8 blue pill. TODO: benchmarking and disassembly for arm-none-eabi-gcc. O3: RAM: 1032, Flash: 1176, Execution Time (20 iterations): 9.9 sec soft_delay PROC
O2 -Otime: RAM: 1032, Flash: 1136, Execution Time (20 iterations): 9.8 sec soft_delay PROC O1: RAM: 1032, Flash: 1216, Execution Time (20 iterations): 13.3 sec soft_delay PROC O0: RAM: 1032, Flash: 1444, Execution Time (20 iterations): 18.7 sec soft_delay PROC Here are the benchmarks and disassembly of soft_delay() function for each optimization level (RAM and Flash amounts include initialization code). And it affects drastically, especially execution time. Playing around with different optimization levels of Keil ArmCC, I see I hope that there are many experienced embedded developers who already encountered this issue and have the answer. I have not yet dived into the jungles of optimization and disassembling, Keil over-optimization (unlikely, because the code is very simple)Īrm-none-eabi-gcc under-optimization due to wrong compiler flags (I use CLion Embedded plugins` CMakeLists.txt)Ī bug in the initialization so that chip has lower clock frequency with arm-none-eabi-gcc (to be investigated) The surprise is that arm-none-eabi-gcc program runs 50% slower in Release mode (-O2 -flto) and 100% slower in Debug mode. It was compiled with both Keil uVision v.5 (default compiler) and CLion using arm-none-eabi-gcc compiler. LL_GPIO_TogglePin(LED_GPIO_Port, LED_Pin) I have a simple blinking led program running on STM32f103C8 (without initialization boilerplate): void soft_delay(void)
0 kommentar(er)
