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

[krasi gichev]

About your last statement - wasn't it clear the doing things on
general-purpose MCU means trading off development resources for
freedom/flexibility? If it was easier/cheaper that why would someone the
earth make specialized chips?
It was good decision, especially for this project, just don't blame
yourself, it is expected to take more time and resources (and, I hope it is
not the case, something can go wrong).


2013/10/20 krasi gichev <krasimirr at gmail.com>

> 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/1a28cca7/attachment-0001.html>