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.
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.comwrote:
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
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.comwrote:
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
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.comwrote:
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
Another point - how about using another BL? There are some open source designs, at least they are better supported. You have to program the BL executive once over internal STM32 BL, but then you can rely on better service? Just an example: http://feaser.com/openblt/doku.php
2013/10/20 krasi gichev krasimirr@gmail.com
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.comwrote:
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
Hello,
On Sun, 20 Oct 2013 11:42:33 +0300 krasi gichev krasimirr@gmail.com wrote:
[]
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).
Also, ST/LINK is included on any STM32 Discovery board one of which you probably already have. Also, other boards you may have, have other models of JTAG adapters included. Also, you may have Bus Pirate or similar tool lying around. It may be not directly supported by OpenOCD, and it may be a chore to develop/debug driver directly in C, that's why projects like https://github.com/pfalcon/PySWD exist to prototype it first in Python.
Also, someone got tired of all that "Got to work with another hardware platform? Go shell out some buck and some time getting yet another "magic" JTAG adapter" approach and started project to pull a random board out of your drawer and use that as a JTAG adapter - https://github.com/pfalcon/simplejtag
[]
On Sun, Oct 20, 2013 at 9:42 AM, krasi gichev krasimirr@gmail.com wrote:
Not sure what particulat problem this could be, but I know that "BOOT0" selects the boot mode.
yes. what i've assumed is that it's ok to just completely overwrite the entire flash on each dev-cycle (no flash-based usb-based bootloader like the one used on the leaflabs maple). as long as i don't hit a flash block write-cycle limit within the development period it'll be ok.
About your last statement - wasn't it clear the doing things on general-purpose MCU means trading off development resources for freedom/flexibility?
in a word, yes. but it's been an absolute sod for hardware verification. Q ODM: we want to sign off the development of the hardware! A: err... you can't. there's no firmware yet. Q: well how can we test if the board we put together is correct or not A: err... you' can't!
so it was a bit of a risk.
If it was easier/cheaper that why would someone the earth make specialized chips
because it's possible with those specialised chips (USB-audio IC, USB-camera IC) to just... plug them in and go. the irony is that most USB-camera ICs have an 8051 embedded microcontroller with on-board ROM or flash, and most good Audio CODEC ICs have a Tensilica DSP with on-board ROM or flash!
so there are companies out there selling exactly the software that's required to do the job, using exactly the same kind of solution, it's just that they're entirely proprietary and ready-to-go. but the fact that these ICs have an on-board MCU/DSP means that they're going to be the same order of magnitude of cost.
*sigh* i'd _really_ like to use the STM32F207 with DCMI but the pricing out of HK is $5.50 for 10k units: nearly 20% *higher* than the 10k pricing off of digikey in EU/USA! which is nuts.
l.
Yes, difference is that those specialized chips are fixed, non-flexible - but ready. Yes, with FW, but those FWs are already done and tested. Overwriting entire flash is also OK, if it is specified for 10K cycles. I remembet the times when embedded program flash was rated for 100 cycles.
How about tracking the reason for this "interrupt-causes-a-problem"?
2013/10/20 luke.leighton luke.leighton@gmail.com
On Sun, Oct 20, 2013 at 9:42 AM, krasi gichev krasimirr@gmail.com wrote:
Not sure what particulat problem this could be, but I know that "BOOT0" selects the boot mode.
yes. what i've assumed is that it's ok to just completely overwrite the entire flash on each dev-cycle (no flash-based usb-based bootloader like the one used on the leaflabs maple). as long as i don't hit a flash block write-cycle limit within the development period it'll be ok.
About your last statement - wasn't it clear the doing things on
general-purpose
MCU means trading off development resources for freedom/flexibility?
in a word, yes. but it's been an absolute sod for hardware verification. Q ODM: we want to sign off the development of the hardware! A: err... you can't. there's no firmware yet. Q: well how can we test if the board we put together is correct or not A: err... you' can't!
so it was a bit of a risk.
If it was easier/cheaper that why would someone the earth make
specialized
chips
because it's possible with those specialised chips (USB-audio IC, USB-camera IC) to just... plug them in and go. the irony is that most USB-camera ICs have an 8051 embedded microcontroller with on-board ROM or flash, and most good Audio CODEC ICs have a Tensilica DSP with on-board ROM or flash!
so there are companies out there selling exactly the software that's required to do the job, using exactly the same kind of solution, it's just that they're entirely proprietary and ready-to-go. but the fact that these ICs have an on-board MCU/DSP means that they're going to be the same order of magnitude of cost.
*sigh* i'd _really_ like to use the STM32F207 with DCMI but the pricing out of HK is $5.50 for 10k units: nearly 20% *higher* than the 10k pricing off of digikey in EU/USA! which is nuts.
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
On Sun, Oct 20, 2013 at 11:34 AM, krasi gichev krasimirr@gmail.com wrote:
Yes, difference is that those specialized chips are fixed, non-flexible - but ready. Yes, with FW, but those FWs are already done and tested. Overwriting entire flash is also OK, if it is specified for 10K cycles. I remembet the times when embedded program flash was rated for 100 cycles.
How about tracking the reason for this "interrupt-causes-a-problem"?
i have to get on - the priority is to prove that the STM32F103 can do external-clock-triggered DMA reads of 8-bit GPIO at at least 6mhz. i can come back to the problems later.
l.
ok good news, after actually having a proper way to get code running i managed an hour ago to string together the right sequence of hardware and software. it's still early days yet: now i have to get this to run at 6mhz without swamping the processor. that's the next challenge.
l.
On Sun, Oct 20, 2013 at 1:22 AM, Ken Phillis Jr kphillisjr@gmail.com wrote:
Isn't it possible to use an embedded real time OS on the STM32F make things easier?
not particularly! this is pretty basic stuff that can be handled entirely via interrupts and timers. also, the tasks can be subdivided up automatically by having different USB endpoints.
so you end up with one huge state-machine where it's actually pretty clear what's going on: a real-time OS would strictly speaking just get in the way.
l.
On Sun, 2013-10-20 at 00:10 +0100, luke.leighton wrote:
well. there is a particular issue with stm32sprog which has massively hindered progress over the past few weeks.
hmmm.. I live and breathe cortex. I could help when I have spare time, but I'm doing NXP chips at the moment. (their software is Eclipse based and free up to 128K and their programmers are inexpensive costing about £15 from Farnell)
If you send details of the exact programmer, and complete developer software being used, then I can buy a few chips (got boards that will take 64, 100 and 144 pin chips) solder them up and do up some software.
"Verbosity makes things unclear": please remember to send exact links so I can click to place orders, and download and configure software - from experience we know pointing doesn't work for me. And also send precise details of what needs building.
On Mon, Oct 21, 2013 at 8:55 AM, joem joem@martindale-electric.co.uk wrote:
On Sun, 2013-10-20 at 00:10 +0100, luke.leighton wrote:
well. there is a particular issue with stm32sprog which has massively hindered progress over the past few weeks.
hmmm.. I live and breathe cortex. I could help when I have spare time,
it's ok joe i got this covered.
what i _could_ do with is a review on how to use libopencm3 to do "ETR"-based timer triggering instead of "Count/Compare". (TIM8_ETR instead of say TIM2_CH2). the latency on the Count/Compare is, at the speeds this is operating at, i believe, delaying things to the point where the data lines are no longer valid. the pseudo-algorithm for this is around page 300 of the reference manual.
but i'm sure with another day or two i'll get that sorted.
l.
arm-netbook@lists.phcomp.co.uk
-
joem -
Ken Phillis Jr -
krasi gichev -
luke.leighton -
Paul Sokolovsky