[Arm-netbook] stress! and working with libopencm3, stm32sprog and an STM32F103

[krasi gichev]

Not sure what particulat problem this could be, but I know that "BOOT0"
selects the boot mode. Quite common case is when you have wrong code inside
(that configures something bad, e.g. disables JTAG/SWD), you have to go
into Bootloader mode and connect then over SWD. This is in case when you
use jtag/swd and y default work in flash boot mode. So going into STM BL is
a measure to stop chip from booting so pins remain correctly set up, and
then you can safely connect over jtag/swd.
Is this a known issue with stm32sprog? It soulds like something left from
STM BL initialization that breaks you software. Something like
pre-configured interrupts, vectors, registers. It is common problem in
embedded world when you have this kind of "stages". I mean that obviously
the values after cold reset (and boot0 at 0 that skips the STM BL code) are
fine for your application. But when STM BL passes before your code it
modifies some registers and initial conditions are now different, so your
code fails. The obvious solution is to detect what is different, and to
take measures inside your code (before enabling interrupts) to fix it.
Where is the hand:
- when your code just starts?
- when interrupts / peripheral modules are configured?
- when interrupts are ENABLED?
I suppose you have some kind of gpio / printf debugging features so you can
test and identify the right point.
How about giving SWD a try?. It is supported under linux, and the adapter
is quite cheap (look on STM site for ST/LINKv2, I beleive it is something
like 25USD).  You can use it to program and to have real on-target
debugging - isn't it more convient for you? I hope you have those 2 pins
free for connection.


2013/10/20 Ken Phillis Jr <kphillisjr at gmail.com>

> Isn't it possible to use an embedded real time OS on the STM32F make
> things easier? I know that ChibiOS/RT [1] is under GPLv3 and that the BSD
> option is nuttX [2].
>
> [1] http://en.wikipedia.org/wiki/ChibiOS/RT
> [2] http://en.wikipedia.org/wiki/NuttX
>
>
>
>
>
> On Sat, Oct 19, 2013 at 6:10 PM, luke.leighton <luke.leighton at gmail.com>wrote:
>
>> well.  there is a particular issue with stm32sprog which has massively
>> hindered progress over the past few weeks.  it's very simple: when
>> uploading and running a program using stm32sprog, if it has interrupt
>> service routines it is guaranteed to crash.  however if you then set
>> BOOT0 to 0 and do a RESET, the program will work absolutely fine
>> [assuming it's coded correctly]
>>
>> this simple little thing has prevented progress over the past couple
>> of weeks because it has been impossible to distinguish "code
>> incorrectly written" from "code that crashed due to stm32sprog".
>>
>> dozens of examples and bits of code that _should_ have worked - DMA,
>> ADC, DAC, Timers - will and can now all be revisited.
>>
>> patience, patience...
>>
>> ... anyway i'm currently tracking how to get timers to update from an
>> external gpio pin, and from there to fire DMA.  it _is_ possible...
>> just.... requires a huge amount of careful reading and research just
>> to come up with only 30 lines of code that connect all the dots
>> together without connecting any of the thousands of other options.
>>
>> i think... to be absolutely honest, if i had known that the STM32F was
>> so comprehensive / complex i would have said "sod it" and used a
>> low-cost FPGA instead.  but, hey, this is kinda hair-raisingly fun....
>>
>> l.
>>
>> _______________________________________________
>> arm-netbook mailing list arm-netbook at lists.phcomp.co.uk
>> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
>> Send large attachments to arm-netbook at files.phcomp.co.uk
>>
>
>
> _______________________________________________
> arm-netbook mailing list arm-netbook at lists.phcomp.co.uk
> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> Send large attachments to arm-netbook at files.phcomp.co.uk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.phcomp.co.uk/pipermail/arm-netbook/attachments/20131020/d4cb2d3b/attachment.html>