Probably not related but saying it anyway:
I recall having an issue with STM32F103 buildin bootloader. If I use
that to flash and run my code, CPU is still using bootloaders vector
table, and not mine. Doing SCB_VTOR= 0x08000000 on my code fixed that.
Maybe your code could set SCB_VTOR to correct value also?
27.2.2015, 11:19, Jorik Jonker kirjoitti:
(switching to main email account)
Thanks Mike for your explanation, that explained the vector table. It
turned out that the culprit was the "Maple DFU Bootloader" I am using
to flash the code. I thought it was irrelevant, since I tried Frank's
suggestion already, so how could it mess things up, right?
Since I was unable to get the DFU code to work from Leaflabs Github
(https://github.com/leaflabs/maple-bootloader) I've used a binary
(http://static.leaflabs.com/pub/leaflabs/maple-bootloader/maple_mini_boot.bin).
As I do not know for sure from which source the binary was compiled, I
am guessing that the bootloader lacks the setup of SCB_VTOR and just
jumps to 0x8005000.
Lesson learned: use SWD instead of buggy bootloaders.
Best,
Jorik
On 23 February 2015 at 15:33, Jorik Jonker <jo...@efgh.nl
<mailto:jo...@efgh.nl>> wrote:
Hi all,
After a few years of toying around with AVR I started
experimenting with ARM using libopencm3. I got myself a cheap
STM32 board and started coding. I was trying to get a very simple
example working using a timer, ISR and a LED connected to a PWM
port, and spent many hours not getting it to work.
I've tried to adopt the example in
'libopencm3-examples/examples/stm32/f1/other/timer_interrupt' to
my specific board using different GPIO and Maple's linker script,
but no luck too.
I've narrowed the code down to something that should toggle the
onboard LED at 2Hz, yielding a 1Hz LED blinker. Unfortunately, the
LED is shut off after the bootloader (Maple's DFU) finishes.
I've created a Gist with my files:
https://gist.github.com/jonkerj/e40e9b95f8e336c26a23
I am not an expert on vector tables, but I find the generated
vector table in my ELF binary rather suspicious for two reasons.
First of all, I am trying to hook on TIM2's IRQ, which should be
IRQ 28 on STM32 F1, according to ST's datasheet and libopencm3's
json file. If we take a look into the objdump in the gist, we see
that the vector table starts at 0x8005000. My ISR seems to be
referenced at 0x80050b0 (that's IRQ 44, right?) and not at
0x8005070 (which is IRQ 28).
Secondly, the vector table references the ISR routine "off by
one": my ISR starts at 0x080051cc and the vector table jumps
to 080051cd.
I am a bit at loss if I am messing things up or if I'm running
into a bug, so I was hoping a post to libopencm3's list could shed
some light on this matter.
Best regards,
Jorik Jonker
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
libopencm3-devel mailing list
libopencm3-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libopencm3-devel
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
libopencm3-devel mailing list
libopencm3-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libopencm3-devel
