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@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@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@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@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netbook@files.phcomp.co.uk


_______________________________________________
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netbook@files.phcomp.co.uk