while running a demo SPI code in my stm32p103 board from olimex, the error at the reset run stage was:
target state: halted
target halted due to breakpoint, current mode: handler hardfault
xPSR:0x01000003 pc:0x4a445f8ce
any idea what this means???
as it was a demo program , i dont think theres a bug in the code.
thank you
abhinav:
as it was a demo program , i dont think theres a bug in the code.
A demo program shows “prof of concept”,
the last mile is up to you…
abhinav:
target state: haltedtarget halted due to breakpoint, current mode: handler hardfault
xPSR:0x01000003 pc:0x4a445f8ce
To find the pc in the 0x4000_0000 address space is just wrong,
can you find where it derails and see why you jump to this address?
BR
Johan
abhinav:
warning: Can not parse XML memory map; XML support was disabled at compile time0xf944f000 in ?? ()
what does that mean?
He tried to start the mcu with pc pointing at 0xf944f000,
and that is not valid…
You can look in the list file to see it looks fine.
arm-none-eabi-objdump -S main.elf > main.lst
check
sp at 0x0
pc at 0x4
and check that all code is placed in valid memory.
Then when you start again,
make sure that pc is valid before you connect the gdb client.
BR
Johan
ok
abhinav:
how do i check where the pc and sp are?i have seen the main.list file.heres the filemain.out: file format elf32-littlearm
Disassembly of section .text:
00000000 :
SPI_InitTypeDef SPI_InitStructure;
void RCC_Configuration(void);
void GPIO_Configuration(void);
int main(void)
{
0: b580 push {r7, lr}
2: b082 sub sp, #8
4: af00 add r7, sp, #0
GPIO_InitStructure.GPIO_Mode = GPIO_Mode_Out_PP;
GPIO_Init(GPIOB, &GPIO_InitStructure);
}
If I look in the list from a simple example
http://fun-tech.se/stm32/OlimexBlinky/mini2.php
main.elf: file format elf32-littlearm
Disassembly of section .text:
00000000 <g_pfnVectors>:
0: fc 4f 00 20 15 00 00 00 10 00 00 00 10 00 00 00 .O. ............
00000010 <Default_Handler>:
10: bf00 nop
12: e7fd b.n 10 <Default_Handler>
00000014 <main>:
int main(void)
{
14: b480 push {r7}
16: b083 sub sp, #12
18: af00 add r7, sp, #0
There you can see
0x0 = a vector/nvic (with sp and pc)
0x10 = Something called Default_Handler
0x14 = main
In your example it looked like your main was at address 0x0,
therefore did not have a valid sp and pc to start with.
BR
Johan
Your linker script is broken or your vector table is missing.
Try my example from my webpage - www.freddiechopin.info (in Download → ARM → Examples
4/3!!
ya i used ur linker file and added the vector table.still the same error!!!
i have downloaded the library and seen that you used a start up file startup.s somewhere.but you did not include it in the make file anywhere.I am sure i am missing something at this point.how do i tell the compiler to use the start up file?
abhinav:
i have downloaded the library and seen that you used a start up file startup.s somewhere.but you did not include it in the make file anywhere.I am sure i am missing something at this point.how do i tell the compiler to use the start up file?
I did write a little bit about a minimal config here:
http://fun-tech.se/stm32/OlimexBlinky/mini.php
http://fun-tech.se/stm32/OlimexBlinky/mini2.php
Then you just append all the other goodies that is needed…
BR
Johan
You’re making it harder than it is by intentionally starting everything from the wrong side…
Get the complete project, configure the clocks and LED port + pin (config.h), compile & test it - if something is wrong here, it’s on your side. If it works fine (the configured led blinks) then start modifying it to your needs and try to understand how it all works TOGETHER. The linker script is tightly coupled with startup.s and vectors.c which are tightly coupled with makefile - probably none of the four would work “alone” “out of the box” - but they can operate simultaneously without problems in any project that obeys the simple rules…
The startup.s assembly file IS referenced in the Makefile via a wildcard for all files which match a .s pattern - just like C (.c) or C++ (*.cpp) files are.
4/3!!
i did use all four files together.but in the linking part, it says
arm-none-eabi-ld: warning : cannot find entry symbol Reset_Handler;defaulting to 08000000
vectors.o : (.vectors+0x4):undefined reference to Reset_handler
make:***[main.out] Error 1
And I know that you haven’t used all four, because my makefile uses gcc for linking, and that’s intentional… You have also modified the vector table (what for?) because the entry there says Reset_Handler, not Reset_handler.
Do it as I’ve recommended or keep doing random changes here and there without understanding. The choice is yours.
4/3!!
ya i used your code to successfully blink the LED.but when i tried to flash it again after erasing the LED program (stm32x mass_erase 0), the write failed saying
flash write_bank 0 main.bin 0
not enough working area available(requested 16384, free 8144)
timed out while waiting for target halted
error executing stm32x flash write algorithm
flash writing failed with error code: 0xfffffc7a
error writing to flash at address 0x08000000 at offset 0x00000000 (-902)
called at file “command.c”, line 469
called at file “embedded:startup.tcl”, line 89
called at file “embedded:startup.tcl”, line 91
called at file “embedded:startup.tcl”, line 93
any idea what this implies?
I also looked up the stm32x.c file and found out that this error may occur when the file sixe is greater than the flash size.when i checked, my bin file size was 512 Mb.I dont know why it ballooned into such a big file when all the the .o files are of normal size.any idea?
The solution is simple - don’t use bin files! Use hex or elf.
They are so big, because there are no addresses - what’s why a file with single byte at 0x8000000 has to have 0x7FFFFFF zeroes in front of it. But they don’t have to, because you can dump only some address range, but then after a few days you really don’t know what does the bin file contain… Or maybe you have something messed up with the linker script, and the bin file contains entries from the RAM, so between 0x8000000 and 0x20000000 it has a lot of zeroes again… They’re just worthless…
I hope that you “reset halt” the chip before trying anything?
4/3!!
lemme try
Ok - this is my last advice - take a look at my linker script and compare it to yours. Every difference you find is YOUR MISTAKE.
EOT for me, as you are really creating problems. The linker file that I posted on my webpage is a “right” one and solves your problems. If you really want to write your own, take a look at how it’s done IN DETAILS.
BTW - you do know that STM32 actually has flash at 0x8000000 and not at 0x0?
4/3!!
Freddie Chopin:
BTW - you do know that STM32 actually has flash at 0x8000000 and not at 0x0?
It is true that you find the flash at 0x08000000,
but if it is not the flash that is mirrored down to 0x0 (for the nvic).
What type of memory is the nvic stored in then at address 0x0?
BR
Johan