<div dir="ltr">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.<div>
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. </div>
<div>Where is the hand:</div><div>- when your code just starts?</div><div>- when interrupts / peripheral modules are configured?</div><div>- when interrupts are ENABLED?</div><div>I suppose you have some kind of gpio / printf debugging features so you can test and identify the right point.<br>
<div>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.<br>
</div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/10/20 Ken Phillis Jr <span dir="ltr"><<a href="mailto:kphillisjr@gmail.com" target="_blank">kphillisjr@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">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].<br><br>[1] <a href="http://en.wikipedia.org/wiki/ChibiOS/RT" target="_blank">http://en.wikipedia.org/wiki/ChibiOS/RT</a><br>

[2] <a href="http://en.wikipedia.org/wiki/NuttX" target="_blank">http://en.wikipedia.org/wiki/NuttX</a><div><div class="h5"><br><br><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Oct 19, 2013 at 6:10 PM, luke.leighton <span dir="ltr"><<a href="mailto:luke.leighton@gmail.com" target="_blank">luke.leighton@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">well.  there is a particular issue with stm32sprog which has massively<br>
hindered progress over the past few weeks.  it's very simple: when<br>
uploading and running a program using stm32sprog, if it has interrupt<br>
service routines it is guaranteed to crash.  however if you then set<br>
BOOT0 to 0 and do a RESET, the program will work absolutely fine<br>
[assuming it's coded correctly]<br>
<br>
this simple little thing has prevented progress over the past couple<br>
of weeks because it has been impossible to distinguish "code<br>
incorrectly written" from "code that crashed due to stm32sprog".<br>
<br>
dozens of examples and bits of code that _should_ have worked - DMA,<br>
ADC, DAC, Timers - will and can now all be revisited.<br>
<br>
patience, patience...<br>
<br>
... anyway i'm currently tracking how to get timers to update from an<br>
external gpio pin, and from there to fire DMA.  it _is_ possible...<br>
just.... requires a huge amount of careful reading and research just<br>
to come up with only 30 lines of code that connect all the dots<br>
together without connecting any of the thousands of other options.<br>
<br>
i think... to be absolutely honest, if i had known that the STM32F was<br>
so comprehensive / complex i would have said "sod it" and used a<br>
low-cost FPGA instead.  but, hey, this is kinda hair-raisingly fun....<br>
<br>
l.<br>
<br>
_______________________________________________<br>
arm-netbook mailing list <a href="mailto:arm-netbook@lists.phcomp.co.uk" target="_blank">arm-netbook@lists.phcomp.co.uk</a><br>
<a href="http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook" target="_blank">http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook</a><br>
Send large attachments to <a href="mailto:arm-netbook@files.phcomp.co.uk" target="_blank">arm-netbook@files.phcomp.co.uk</a><br>
</blockquote></div><br></div></div></div></div>
<br>_______________________________________________<br>
arm-netbook mailing list <a href="mailto:arm-netbook@lists.phcomp.co.uk">arm-netbook@lists.phcomp.co.uk</a><br>
<a href="http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook" target="_blank">http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook</a><br>
Send large attachments to <a href="mailto:arm-netbook@files.phcomp.co.uk">arm-netbook@files.phcomp.co.uk</a><br></blockquote></div><br></div>