On 20 Jun., 22:25, Mark Borgerson <mborger...@comcast.net> wrote:> In article <0vidnfqFnZKEYXzSnZ2dnUVZ_uKdn...@web-ster.com>, > t...@seemywebsite.com says... > > > > > > > > > > > > > On Wed, 20 Jun 2012 09:11:07 -0700, langw...@fonz.dk wrote: > > > > On 20 Jun., 17:53, Tim Wescott <t...@seemywebsite.com> wrote: > > >> On Wed, 20 Jun 2012 10:51:52 -0500, Tim Wescott wrote: > > >> > I'm using an STM32F103VB, and one of the things that I'm doing is > > >> > doing a set of ADC reads which are then being transferred via DMA =to> > >> > a buffer. > > > >> > For some reason, when I'm debugging the DMA transfer gets scramble=d:> > >> > channel 0 ends up where channel 1 is supposed to go, channel 1 whe=re> > >> > channel 2 should be, on up the line until finally the last channel > > >> > gets written to channel 0. > > > >> > I have the code set up for the ADC to run in "scan" mode, with the > > >> > DMA (theoretically!) sucking the data off and putting it into memo=ry.> > > >> > Furthermore, I have the ADC ISR set up so that on an end of > > >> > conversion interrupt (which is only supposed to happen at the end =of> > >> > the scan in scan mode) the DMA engine gets reinitialized to point =to> > >> > the base of the memory array it's supposed to write to. > > > >> > Does anyone have any obvious clue to what I'm doing wrong? Does ST > > >> > have any good bits of sample code that I've missed? > > > >> > Thanks in advance. > > > >> Whoops -- I meant to cross-post this to sed, 'cause there may be fol=ks> > >> over there with useful information, too. > > > > a suggestion from a quick google > > >http://www.micromouseonline.com/2009/05/26/simple-adc-use-on-the-stm32=/> > #axzz1yLmVUCe5 > > > That's way too simple -- my problem isn't getting the right numbers out > > of the ADC. =A0My problem is getting the right numbers out of the ADC, =at> > the right times, and into the right spots in memory fast. > > > The _only_ way that I can see to do multiple consecutive ADC conversion=s> > with that part is to use the ADC scan mode and DMA -- so I pretty much > > must get it working. > > > It is very frustrating to halt the processor, restart, and see all the > > right numbers in all the wrong places. =A0Scary, too, considering that =I'm> > controlling enough power to make things awfully toasty if I screw it up=.> > I think the STM32 debug hardware has the option to stop the timer clocks > when debugging. =A0If you don't do that, perhaps your timer is triggering > an ADC cycle while in the debug mode. > > Mark Borgersongenerally when you are working on stuff that controls with motors and power stopping the cpu is not an option. You have to use some type of realtime debugger to look at variables and such used to be that you had to make your own with uart or something like that, but now most also have to the option to do it over the jtag or what ever debug interface is used -Lasse
DMA losing sync on ST ARM processor
Started by ●June 20, 2012
Reply by ●June 20, 20122012-06-20
Reply by ●June 20, 20122012-06-20
In article <89321ffc-6291-439a-893a- 2686e0df5aec@v9g2000vbc.googlegroups.com>, langwadt@fonz.dk says...> > On 20 Jun., 22:25, Mark Borgerson <mborger...@comcast.net> wrote: > > In article <0vidnfqFnZKEYXzSnZ2dnUVZ_uKdn...@web-ster.com>, > > t...@seemywebsite.com says... > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 20 Jun 2012 09:11:07 -0700, langw...@fonz.dk wrote: > > > > > > On 20 Jun., 17:53, Tim Wescott <t...@seemywebsite.com> wrote: > > > >> On Wed, 20 Jun 2012 10:51:52 -0500, Tim Wescott wrote: > > > >> > I'm using an STM32F103VB, and one of the things that I'm doing is > > > >> > doing a set of ADC reads which are then being transferred via DMA to > > > >> > a buffer. > > > > > >> > For some reason, when I'm debugging the DMA transfer gets scrambled: > > > >> > channel 0 ends up where channel 1 is supposed to go, channel 1 where > > > >> > channel 2 should be, on up the line until finally the last channel > > > >> > gets written to channel 0. > > > > > >> > I have the code set up for the ADC to run in "scan" mode, with the > > > >> > DMA (theoretically!) sucking the data off and putting it into memory. > > > > > >> > Furthermore, I have the ADC ISR set up so that on an end of > > > >> > conversion interrupt (which is only supposed to happen at the end of > > > >> > the scan in scan mode) the DMA engine gets reinitialized to point to > > > >> > the base of the memory array it's supposed to write to. > > > > > >> > Does anyone have any obvious clue to what I'm doing wrong? Does ST > > > >> > have any good bits of sample code that I've missed? > > > > > >> > Thanks in advance. > > > > > >> Whoops -- I meant to cross-post this to sed, 'cause there may be folks > > > >> over there with useful information, too. > > > > > > a suggestion from a quick google > > > >http://www.micromouseonline.com/2009/05/26/simple-adc-use-on-the-stm32/ > > > #axzz1yLmVUCe5 > > > > > That's way too simple -- my problem isn't getting the right numbers out > > > of the ADC. �My problem is getting the right numbers out of the ADC, at > > > the right times, and into the right spots in memory fast. > > > > > The _only_ way that I can see to do multiple consecutive ADC conversions > > > with that part is to use the ADC scan mode and DMA -- so I pretty much > > > must get it working. > > > > > It is very frustrating to halt the processor, restart, and see all the > > > right numbers in all the wrong places. �Scary, too, considering that I'm > > > controlling enough power to make things awfully toasty if I screw it up. > > > > I think the STM32 debug hardware has the option to stop the timer clocks > > when debugging. �If you don't do that, perhaps your timer is triggering > > an ADC cycle while in the debug mode. > > > > Mark Borgerson > > generally when you are working on stuff that controls with motors and > power > stopping the cpu is not an option. You have to use some type of > realtime > debugger to look at variables and such > > used to be that you had to make your own with uart or something like > that, but > now most also have to the option to do it over the jtag or what ever > debug > interface is used >The manual for the STM32F2xx mentions that the option to keep the timer clocks running when the CPU is halted for debugging is useful when using the timers to generate PWM for motor control. Mark Borgerson
Reply by ●June 20, 20122012-06-20
On 20 Jun., 22:45, Mark Borgerson <mborger...@comcast.net> wrote:> In article <89321ffc-6291-439a-893a- > 2686e0df5...@v9g2000vbc.googlegroups.com>, langw...@fonz.dk says... > > > > > > > > > > > On 20 Jun., 22:25, Mark Borgerson <mborger...@comcast.net> wrote: > > > In article <0vidnfqFnZKEYXzSnZ2dnUVZ_uKdn...@web-ster.com>, > > > t...@seemywebsite.com says... > > > > > On Wed, 20 Jun 2012 09:11:07 -0700, langw...@fonz.dk wrote: > > > > > > On 20 Jun., 17:53, Tim Wescott <t...@seemywebsite.com> wrote: > > > > >> On Wed, 20 Jun 2012 10:51:52 -0500, Tim Wescott wrote: > > > > >> > I'm using an STM32F103VB, and one of the things that I'm doing is > > > > >> > doing a set of ADC reads which are then being transferred via DMA to > > > > >> > a buffer. > > > > > >> > For some reason, when I'm debugging the DMA transfer gets scrambled: > > > > >> > channel 0 ends up where channel 1 is supposed to go, channel 1 where > > > > >> > channel 2 should be, on up the line until finally the last channel > > > > >> > gets written to channel 0. > > > > > >> > I have the code set up for the ADC to run in "scan" mode, with the > > > > >> > DMA (theoretically!) sucking the data off and putting it into memory. > > > > > >> > Furthermore, I have the ADC ISR set up so that on an end of > > > > >> > conversion interrupt (which is only supposed to happen at the end of > > > > >> > the scan in scan mode) the DMA engine gets reinitialized to point to > > > > >> > the base of the memory array it's supposed to write to. > > > > > >> > Does anyone have any obvious clue to what I'm doing wrong? Does ST > > > > >> > have any good bits of sample code that I've missed? > > > > > >> > Thanks in advance. > > > > > >> Whoops -- I meant to cross-post this to sed, 'cause there may be folks > > > > >> over there with useful information, too. > > > > > > a suggestion from a quick google > > > > >http://www.micromouseonline.com/2009/05/26/simple-adc-use-on-the-stm32/ > > > > #axzz1yLmVUCe5 > > > > > That's way too simple -- my problem isn't getting the right numbers out > > > > of the ADC. My problem is getting the right numbers out of the ADC, at > > > > the right times, and into the right spots in memory fast. > > > > > The _only_ way that I can see to do multiple consecutive ADC conversions > > > > with that part is to use the ADC scan mode and DMA -- so I pretty much > > > > must get it working. > > > > > It is very frustrating to halt the processor, restart, and see all the > > > > right numbers in all the wrong places. Scary, too, considering that I'm > > > > controlling enough power to make things awfully toasty if I screw it up. > > > > I think the STM32 debug hardware has the option to stop the timer clocks > > > when debugging. If you don't do that, perhaps your timer is triggering > > > an ADC cycle while in the debug mode. > > > > Mark Borgerson > > > generally when you are working on stuff that controls with motors and > > power > > stopping the cpu is not an option. You have to use some type of > > realtime > > debugger to look at variables and such > > > used to be that you had to make your own with uart or something like > > that, but > > now most also have to the option to do it over the jtag or what ever > > debug > > interface is used > > The manual for the STM32F2xx mentions that the option to keep the timer > clocks running when the CPU is halted for debugging is useful when using > the timers to generate PWM for motor control. > > Mark Borgersondepends on how intelligent the timer is of course, but imagine a robot controlled by that motor, stop the cpu at the wrong time at it might just keep going until it hits something HARD -Lasse
Reply by ●June 20, 20122012-06-20
In article <96260cdf-ec22-4dac-9848-8dbee8e9d327 @p27g2000vbl.googlegroups.com>, langwadt@fonz.dk says...> > On 20 Jun., 22:45, Mark Borgerson <mborger...@comcast.net> wrote: > > In article <89321ffc-6291-439a-893a- > > 2686e0df5...@v9g2000vbc.googlegroups.com>, langw...@fonz.dk says... > > > > > > > > > > > > > > > > > > > > > On 20 Jun., 22:25, Mark Borgerson <mborger...@comcast.net> wrote: > > > > In article <0vidnfqFnZKEYXzSnZ2dnUVZ_uKdn...@web-ster.com>, > > > > t...@seemywebsite.com says... > > > > > > > On Wed, 20 Jun 2012 09:11:07 -0700, langw...@fonz.dk wrote: > > > > > > > > On 20 Jun., 17:53, Tim Wescott <t...@seemywebsite.com> wrote: > > > > > >> On Wed, 20 Jun 2012 10:51:52 -0500, Tim Wescott wrote: > > > > > >> > I'm using an STM32F103VB, and one of the things that I'm doing is > > > > > >> > doing a set of ADC reads which are then being transferred via DMA to > > > > > >> > a buffer. > > > > > > > >> > For some reason, when I'm debugging the DMA transfer gets scrambled: > > > > > >> > channel 0 ends up where channel 1 is supposed to go, channel 1 where > > > > > >> > channel 2 should be, on up the line until finally the last channel > > > > > >> > gets written to channel 0. > > > > > > > >> > I have the code set up for the ADC to run in "scan" mode, with the > > > > > >> > DMA (theoretically!) sucking the data off and putting it into memory. > > > > > > > >> > Furthermore, I have the ADC ISR set up so that on an end of > > > > > >> > conversion interrupt (which is only supposed to happen at the end of > > > > > >> > the scan in scan mode) the DMA engine gets reinitialized to point to > > > > > >> > the base of the memory array it's supposed to write to. > > > > > > > >> > Does anyone have any obvious clue to what I'm doing wrong? Does ST > > > > > >> > have any good bits of sample code that I've missed? > > > > > > > >> > Thanks in advance. > > > > > > > >> Whoops -- I meant to cross-post this to sed, 'cause there may be folks > > > > > >> over there with useful information, too. > > > > > > > > a suggestion from a quick google > > > > > >http://www.micromouseonline.com/2009/05/26/simple-adc-use-on-the-stm32/ > > > > > #axzz1yLmVUCe5 > > > > > > > That's way too simple -- my problem isn't getting the right numbers out > > > > > of the ADC. My problem is getting the right numbers out of the ADC, at > > > > > the right times, and into the right spots in memory fast. > > > > > > > The _only_ way that I can see to do multiple consecutive ADC conversions > > > > > with that part is to use the ADC scan mode and DMA -- so I pretty much > > > > > must get it working. > > > > > > > It is very frustrating to halt the processor, restart, and see all the > > > > > right numbers in all the wrong places. Scary, too, considering that I'm > > > > > controlling enough power to make things awfully toasty if I screw it up. > > > > > > I think the STM32 debug hardware has the option to stop the timer clocks > > > > when debugging. If you don't do that, perhaps your timer is triggering > > > > an ADC cycle while in the debug mode. > > > > > > Mark Borgerson > > > > > generally when you are working on stuff that controls with motors and > > > power > > > stopping the cpu is not an option. You have to use some type of > > > realtime > > > debugger to look at variables and such > > > > > used to be that you had to make your own with uart or something like > > > that, but > > > now most also have to the option to do it over the jtag or what ever > > > debug > > > interface is used > > > > The manual for the STM32F2xx mentions that the option to keep the timer > > clocks running when the CPU is halted for debugging is useful when using > > the timers to generate PWM for motor control. > > > > Mark Borgerson > > depends on how intelligent the timer is of course, but imagine a > robot > controlled by that motor, stop the cpu at the wrong time at it might > just > keep going until it hits something HARD >That kind of problem is always present when controlling motors and other mechanical systems. Real-Time debugging is difficult even with the best of hardware. That's one reason I've never been particularly interested in writing code for computer-controlled sawmills! When I was working on autonomous aerial vehicle code, there were two kinds of debugging----offline PC sims to debug algorithms, and the "record everything and analyze after the crash" for the hardware- associated problems. (The 'crash' was usually not a computer reset type crash. It was an "I was flying and now I'm not" type of crash.) Mark Borgerson
Reply by ●June 20, 20122012-06-20
On Wed, 20 Jun 2012 10:04:16 -0700, langwadt@fonz.dk wrote:> On 20 Jun., 18:36, Tim Wescott <t...@seemywebsite.com> wrote: >> On Wed, 20 Jun 2012 09:11:07 -0700, langw...@fonz.dk wrote: >> > On 20 Jun., 17:53, Tim Wescott <t...@seemywebsite.com> wrote: >> >> On Wed, 20 Jun 2012 10:51:52 -0500, Tim Wescott wrote: >> >> > I'm using an STM32F103VB, and one of the things that I'm doing is >> >> > doing a set of ADC reads which are then being transferred via DMA >> >> > to a buffer. >> >> >> > For some reason, when I'm debugging the DMA transfer gets >> >> > scrambled: channel 0 ends up where channel 1 is supposed to go, >> >> > channel 1 where channel 2 should be, on up the line until finally >> >> > the last channel gets written to channel 0. >> >> >> > I have the code set up for the ADC to run in "scan" mode, with the >> >> > DMA (theoretically!) sucking the data off and putting it into >> >> > memory. >> >> >> > Furthermore, I have the ADC ISR set up so that on an end of >> >> > conversion interrupt (which is only supposed to happen at the end >> >> > of the scan in scan mode) the DMA engine gets reinitialized to >> >> > point to the base of the memory array it's supposed to write to. >> >> >> > Does anyone have any obvious clue to what I'm doing wrong? Does >> >> > ST have any good bits of sample code that I've missed? >> >> >> > Thanks in advance. >> >> >> Whoops -- I meant to cross-post this to sed, 'cause there may be >> >> folks over there with useful information, too. >> >> > a suggestion from a quick google >> >http://www.micromouseonline.com/2009/05/26/simple-adc-use-on-the-stm32/>> >> #axzz1yLmVUCe5 >> >> That's way too simple -- my problem isn't getting the right numbers out >> of the ADC. My problem is getting the right numbers out of the ADC, at >> the right times, and into the right spots in memory fast. >> >> The _only_ way that I can see to do multiple consecutive ADC >> conversions with that part is to use the ADC scan mode and DMA -- so I >> pretty much must get it working. >> >> It is very frustrating to halt the processor, restart, and see all the >> right numbers in all the wrong places. Scary, too, considering that >> I'm controlling enough power to make things awfully toasty if I screw >> it up. >> >> > should have mentioned I was looking at the post by "tony" two thirds > down > the page, look like scan of two channels with dmaIt looks like he's doing what I'm trying; maybe he didn't debug. At any rate, I found a horrible kludge that seems to work. At the end of the ISR, I reset the DMA controller leaving room for the ADC channels _plus one_. I'm sure that when I die and I'm trying to convince St. Peter that I belong up instead of down, that this kludge will be raised as a topic of conversation: DMA.CHAN_1.CCR.bits.EN = 0; // disable DMA DMA.CHAN_1.CMAR = raw_adc_readings; // set address DMA.CHAN_1.CNDTR.bits.NDT = ADC_CHANNELS + 1; // Number of ADC channels + kludge DMA.IFCR.bits.TCF1 = 1; // Clear the transfer complete interrupt DMA.CHAN_1.CCR.bits.EN = 1; // enable DMA ADC1.SR.bits.EOC = 0; // clear interrupt -- My liberal friends think I'm a conservative kook. My conservative friends think I'm a liberal kook. Why am I not happy that they have found common ground? Tim Wescott, Communications, Control, Circuits & Software http://www.wescottdesign.com
Reply by ●June 21, 20122012-06-21
On 21 Jun., 00:34, Tim Wescott <t...@seemywebsite.com> wrote:> On Wed, 20 Jun 2012 10:04:16 -0700, langw...@fonz.dk wrote: > > On 20 Jun., 18:36, Tim Wescott <t...@seemywebsite.com> wrote: > >> On Wed, 20 Jun 2012 09:11:07 -0700, langw...@fonz.dk wrote: > >> > On 20 Jun., 17:53, Tim Wescott <t...@seemywebsite.com> wrote: > >> >> On Wed, 20 Jun 2012 10:51:52 -0500, Tim Wescott wrote: > >> >> > I'm using an STM32F103VB, and one of the things that I'm doing is > >> >> > doing a set of ADC reads which are then being transferred via DMA > >> >> > to a buffer. > > >> >> > For some reason, when I'm debugging the DMA transfer gets > >> >> > scrambled: channel 0 ends up where channel 1 is supposed to go, > >> >> > channel 1 where channel 2 should be, on up the line until finally > >> >> > the last channel gets written to channel 0. > > >> >> > I have the code set up for the ADC to run in "scan" mode, with th=e> >> >> > DMA (theoretically!) sucking the data off and putting it into > >> >> > memory. > > >> >> > Furthermore, I have the ADC ISR set up so that on an end of > >> >> > conversion interrupt (which is only supposed to happen at the end > >> >> > of the scan in scan mode) the DMA engine gets reinitialized to > >> >> > point to the base of the memory array it's supposed to write to. > > >> >> > Does anyone have any obvious clue to what I'm doing wrong? =A0Doe=s> >> >> > ST have any good bits of sample code that I've missed? > > >> >> > Thanks in advance. > > >> >> Whoops -- I meant to cross-post this to sed, 'cause there may be > >> >> folks over there with useful information, too. > > >> > a suggestion from a quick google > >> >http://www.micromouseonline.com/2009/05/26/simple-adc-use-on-the- > stm32/ > > >> #axzz1yLmVUCe5 > > >> That's way too simple -- my problem isn't getting the right numbers ou=t> >> of the ADC. =A0My problem is getting the right numbers out of the ADC,=at> >> the right times, and into the right spots in memory fast. > > >> The _only_ way that I can see to do multiple consecutive ADC > >> conversions with that part is to use the ADC scan mode and DMA -- so I > >> pretty much must get it working. > > >> It is very frustrating to halt the processor, restart, and see all the > >> right numbers in all the wrong places. =A0Scary, too, considering that > >> I'm controlling enough power to make things awfully toasty if I screw > >> it up. > > > should have mentioned I was looking at the post by "tony" two thirds > > down > > the page, look like scan of two channels with dma > > It looks like he's doing what I'm trying; maybe he didn't debug.so it is only when you debug? what are you using for debug?> > At any rate, I found a horrible kludge that seems to work. =A0At the end =of> the ISR, I reset the DMA controller leaving room for the ADC channels > _plus one_. =A0I'm sure that when I die and I'm trying to convince St. > Peter that I belong up instead of down, that this kludge will be raised > as a topic of conversation: >I've seen worse but, are you setting the dma up for circular mode? if you do that and have the plus one aren't you pretty sure it will go wrong if you are ever late with the interrupt? guess you could put a magic number at that extra location and if it ever gets overwritten panic or what ever makes most sense :P -Lasse
Reply by ●June 21, 20122012-06-21
On Thu, 21 Jun 2012 09:30:52 -0700, langwadt@fonz.dk wrote:> On 21 Jun., 00:34, Tim Wescott <t...@seemywebsite.com> wrote: >> On Wed, 20 Jun 2012 10:04:16 -0700, langw...@fonz.dk wrote: >> > On 20 Jun., 18:36, Tim Wescott <t...@seemywebsite.com> wrote: >> >> On Wed, 20 Jun 2012 09:11:07 -0700, langw...@fonz.dk wrote: >> >> > On 20 Jun., 17:53, Tim Wescott <t...@seemywebsite.com> wrote: >> >> >> On Wed, 20 Jun 2012 10:51:52 -0500, Tim Wescott wrote: >> >> >> > I'm using an STM32F103VB, and one of the things that I'm doing >> >> >> > is doing a set of ADC reads which are then being transferred >> >> >> > via DMA to a buffer. >> >> >> >> > For some reason, when I'm debugging the DMA transfer gets >> >> >> > scrambled: channel 0 ends up where channel 1 is supposed to go, >> >> >> > channel 1 where channel 2 should be, on up the line until >> >> >> > finally the last channel gets written to channel 0. >> >> >> >> > I have the code set up for the ADC to run in "scan" mode, with >> >> >> > the DMA (theoretically!) sucking the data off and putting it >> >> >> > into memory. >> >> >> >> > Furthermore, I have the ADC ISR set up so that on an end of >> >> >> > conversion interrupt (which is only supposed to happen at the >> >> >> > end of the scan in scan mode) the DMA engine gets reinitialized >> >> >> > to point to the base of the memory array it's supposed to write >> >> >> > to. >> >> >> >> > Does anyone have any obvious clue to what I'm doing wrong? >> >> >> > Does ST have any good bits of sample code that I've missed? >> >> >> >> > Thanks in advance. >> >> >> >> Whoops -- I meant to cross-post this to sed, 'cause there may be >> >> >> folks over there with useful information, too. >> >> >> > a suggestion from a quick google >> >> >http://www.micromouseonline.com/2009/05/26/simple-adc-use-on-the- >> stm32/ >> >> >> #axzz1yLmVUCe5 >> >> >> That's way too simple -- my problem isn't getting the right numbers >> >> out of the ADC. My problem is getting the right numbers out of the >> >> ADC, at the right times, and into the right spots in memory fast. >> >> >> The _only_ way that I can see to do multiple consecutive ADC >> >> conversions with that part is to use the ADC scan mode and DMA -- so >> >> I pretty much must get it working. >> >> >> It is very frustrating to halt the processor, restart, and see all >> >> the right numbers in all the wrong places. Scary, too, considering >> >> that I'm controlling enough power to make things awfully toasty if I >> >> screw it up. >> >> > should have mentioned I was looking at the post by "tony" two thirds >> > down the page, look like scan of two channels with dma >> >> It looks like he's doing what I'm trying; maybe he didn't debug. > > so it is only when you debug? what are you using for debug? > > >> At any rate, I found a horrible kludge that seems to work. At the end >> of the ISR, I reset the DMA controller leaving room for the ADC >> channels _plus one_. I'm sure that when I die and I'm trying to >> convince St. Peter that I belong up instead of down, that this kludge >> will be raised as a topic of conversation: >> >> > I've seen worse but, are you setting the dma up for circular mode? if > you do that and have the plus one aren't you pretty sure it will go > wrong if you are ever late with the interrupt? > > guess you could put a magic number at that extra location and if it ever > gets overwritten panic or what ever makes most sense :P > > > -LasseJTAG, OpenOCD and gdb for debugging. The DMA is _not_ in circular mode. I may monitor the extra location -- but I suspect that I'll just find out that it stays zero until after I halt and restart. -- Tim Wescott Control system and signal processing consulting www.wescottdesign.com
Reply by ●June 21, 20122012-06-21
On 21 Jun., 19:21, Tim Wescott <t...@seemywebsite.please> wrote:> On Thu, 21 Jun 2012 09:30:52 -0700, langw...@fonz.dk wrote: > > On 21 Jun., 00:34, Tim Wescott <t...@seemywebsite.com> wrote: > >> On Wed, 20 Jun 2012 10:04:16 -0700, langw...@fonz.dk wrote: > >> > On 20 Jun., 18:36, Tim Wescott <t...@seemywebsite.com> wrote: > >> >> On Wed, 20 Jun 2012 09:11:07 -0700, langw...@fonz.dk wrote: > >> >> > On 20 Jun., 17:53, Tim Wescott <t...@seemywebsite.com> wrote: > >> >> >> On Wed, 20 Jun 2012 10:51:52 -0500, Tim Wescott wrote: > >> >> >> > I'm using an STM32F103VB, and one of the things that I'm doing > >> >> >> > is doing a set of ADC reads which are then being transferred > >> >> >> > via DMA to a buffer. > > >> >> >> > For some reason, when I'm debugging the DMA transfer gets > >> >> >> > scrambled: channel 0 ends up where channel 1 is supposed to go=,> >> >> >> > channel 1 where channel 2 should be, on up the line until > >> >> >> > finally the last channel gets written to channel 0. > > >> >> >> > I have the code set up for the ADC to run in "scan" mode, with > >> >> >> > the DMA (theoretically!) sucking the data off and putting it > >> >> >> > into memory. > > >> >> >> > Furthermore, I have the ADC ISR set up so that on an end of > >> >> >> > conversion interrupt (which is only supposed to happen at the > >> >> >> > end of the scan in scan mode) the DMA engine gets reinitialize=d> >> >> >> > to point to the base of the memory array it's supposed to writ=e> >> >> >> > to. > > >> >> >> > Does anyone have any obvious clue to what I'm doing wrong? > >> >> >> > =A0Does ST have any good bits of sample code that I've missed? > > >> >> >> > Thanks in advance. > > >> >> >> Whoops -- I meant to cross-post this to sed, 'cause there may be > >> >> >> folks over there with useful information, too. > > >> >> > a suggestion from a quick google > >> >> >http://www.micromouseonline.com/2009/05/26/simple-adc-use-on-the- > >> stm32/ > > >> >> #axzz1yLmVUCe5 > > >> >> That's way too simple -- my problem isn't getting the right numbers > >> >> out of the ADC. =A0My problem is getting the right numbers out of t=he> >> >> ADC, at the right times, and into the right spots in memory fast. > > >> >> The _only_ way that I can see to do multiple consecutive ADC > >> >> conversions with that part is to use the ADC scan mode and DMA -- s=o> >> >> I pretty much must get it working. > > >> >> It is very frustrating to halt the processor, restart, and see all > >> >> the right numbers in all the wrong places. =A0Scary, too, consideri=ng> >> >> that I'm controlling enough power to make things awfully toasty if =I> >> >> screw it up. > > >> > should have mentioned I was looking at the post by "tony" two thirds > >> > down the page, look like scan of two channels with dma > > >> It looks like he's doing what I'm trying; maybe he didn't debug. > > > so it is only when you debug? what are you using for debug? > > >> At any rate, I found a horrible kludge that seems to work. =A0At the e=nd> >> of the ISR, I reset the DMA controller leaving room for the ADC > >> channels _plus one_. =A0I'm sure that when I die and I'm trying to > >> convince St. Peter that I belong up instead of down, that this kludge > >> will be raised as a topic of conversation: > > > I've seen worse but, are you setting the dma up for circular mode? if > > you do that and have the plus one aren't you pretty sure it will go > > wrong if you are ever late with the interrupt? > > > guess you could put a magic number at that extra location and if it eve=r> > gets overwritten panic or what ever makes most sense :P > > > -Lasse > > JTAG, OpenOCD and gdb for debugging. > > The DMA is _not_ in circular mode.did you have that before?> > I may monitor the extra location -- but I suspect that I'll just find out > that it stays zero until after I halt and restart. >it should tell you something about whether it is the dma or the adc that gets confused -Lasse
Reply by ●June 25, 20122012-06-25
Il 20/06/2012 17:51, Tim Wescott ha scritto:> For some reason, when I'm debugging the DMA transfer gets scrambled:Maybe you left a dma or adc memory watch opened? Reading a register can trigger some event, and it will be triggered even if you left a dma or adc regs watch opened. L
Reply by ●June 4, 20132013-06-04
>I'm using an STM32F103VB, and one of the things that I'm doing is doing a>set of ADC reads which are then being transferred via DMA to a buffer. > >For some reason, when I'm debugging the DMA transfer gets scrambled: >channel 0 ends up where channel 1 is supposed to go, channel 1 where >channel 2 should be, on up the line until finally the last channel gets >written to channel 0. > >I have the code set up for the ADC to run in "scan" mode, with the DMA >(theoretically!) sucking the data off and putting it into memory. > >Furthermore, I have the ADC ISR set up so that on an end of conversion >interrupt (which is only supposed to happen at the end of the scan in >scan mode) the DMA engine gets reinitialized to point to the base of the >memory array it's supposed to write to. > >Does anyone have any obvious clue to what I'm doing wrong? Does ST have >any good bits of sample code that I've missed? > >Thanks in advance. > >-- >My liberal friends think I'm a conservative kook. >My conservative friends think I'm a liberal kook. >Why am I not happy that they have found common ground? > >Tim Wescott, Communications, Control, Circuits & Software >http://www.wescottdesign.com >I just got an email on this asking how I resolved it -- so I guess I should revive this dusty old thread and answer my own question. I can't be entirely sure with the passage of time, but I believe that this is the pertinent bit of code, found in my ADC ISR: DMA.CHAN_1.CCR.bits.EN = 0; // disable DMA DMA.CHAN_1.CMAR = raw_adc_readings; // set address DMA.CHAN_1.CNDTR.bits.NDT = ADC_CHANNELS + 1; // Number of ADC channels + kludge DMA.CHAN_1.CCR.bits.EN = 1; // enable DMA This ISR triggers off of the ADC end-of-conversion, _not_ the DMA: I don't know if that's necessary to the fix, or if it just happened to make things work. I'm pretty sure (I certainly hope!) that this end-of-conversion interrupt happens at the end of the sequence -- the reader should check his documentation to make sure. The pertinent setup (well, some -- there's a bazillion bits to set) is: ADC1.CR1.bits.EOCIE = 1; // interrupt on conversion end ADC1.CR1.bits.SCAN = 1; // scan ADC1.CR2.bits.DMA = 1; // use DMA ADC1.CR2.bits.ALIGN = 1; // left alignment ADC1.CR2.bits.EXTSEL = 0x04; // Trigger on Timer 3 TRGO event. -- Tim Wescott http://www.wescottdesign.com --------------------------------------- Posted through http://www.EmbeddedRelated.com
