This isn’t “buggy”; you may feel it’s inconvenient, but it’s poor design for
application startup code to make unverified assumptions about the state of the
machine, *particularly* if you plan to (or may be) be invoked by a bootloader.
There are of course, differing schools of thought on this subject; for example:
a) Moving SCB_VTOR before branching to code in flash is actually a terrible
idea from a product perspective, as it means the bootloader has no way of
regaining control if the loaded code is bad. Leaving it pointing to the
bootloader means that fatal exceptions that occur before the loaded application
has configured its own exception processing will be fielded by the bootloader,
giving it a chance to do something sensible (e.g. re-enter bootloader mode).
b) Applications should be started as though they were the first code to run
since reset (even though in reality they tend to be at least second or third).
c) Applications should include additional metadata and conform to a documented
bootloader start interface (NXP do some of this with their CRC buried in the
vector table, for example).
Opinion b) is not an option on many platforms, and IMO ARMv7M is probably
teaching people bad habits by making it (nearly) possible.
= Mike
> On 28 Feb 2015, at 3:51 am, Tommi Rouvali <[email protected]> wrote:
>
>
> 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
>> <https://github.com/leaflabs/maple-bootloader>) I've used a binary
>> (http://static.leaflabs.com/pub/leaflabs/maple-bootloader/maple_mini_boot.bin
>>
>> <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 <[email protected]
>> <mailto:[email protected]>> 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
>> <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/
>> <http://goparallel.sourceforge.net/>
>>
>> _______________________________________________
>> libopencm3-devel mailing list
>> [email protected]
>> <mailto:[email protected]>
>> https://lists.sourceforge.net/lists/listinfo/libopencm3-devel
>> <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
> [email protected]
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/libopencm3-devel
