Strange ADC and DMA problem

karsten23 · ‎2011-08-30

Posted on August 30, 2011 at 10:51

The original post was too long to process during our migration. Please click on the attachment to read the original post.

raptorhal2 · ‎2011-08-30

Posted on August 30, 2011 at 13:01

The ADC clock is limited to 14 MHz. See 11.1 of the RM0008 All Densities Reference Manual. That probably explains why you only get one byte of conversion data.

Cheers, Hal

raptorhal2 · ‎2011-08-30

Posted on August 30, 2011 at 14:59

The following advice is true for the STM32 no matter what the application:

Use the following sequence for starting up the processor

Initialize HSE or HSI

Initialize peripheral clocks

Initialize NVIC

Initialize GPIO

Initialize peripherals

Your NVIC initialization is out of sequence. I am not familiar with your development environment, so I can't tell if your listed code is complete, or partial, and your HSE/HSI is initialized elsewhere.

Cheers, Hal

karsten23 · ‎2011-08-31

Posted on August 31, 2011 at 23:14

Hi,

thanks for your input.

I restructured the code and ordered it like you proposed (Roughly I did that before but for peripherals which I switch on and off via compile flags I wanted to have the clock and gpio init in the source but thats not important anyway).

Also I now use ''RCC_PCLK2_Div6'' which should result in an ADC-clock of 12MHZ.

Sadly neither had any influence on the system. I still only get byte size ADC values and if i leave out the while loop the checksum compare still failes.

I would be grateful for any other ideas!

Thanks in advance!

Bye,

Karsten

karsten23 · ‎2011-08-31

Posted on September 01, 2011 at 00:06

Partially this is working now...

The ''byte'' size problem was fixed by fixing the following copy and paste error:

''dmaInit.DMA_PeripheralDataSize = DMA_PeripheralDataSize_HalfWord;''

not

''dmaInit.DMA_PeripheralDataSize = DMA_MemoryDataSize_HalfWord;''

Still as soon as i allow calling of ''ADC_SoftwareStartConvCmd(ADC1, ENABLE);'' I get the checksum/binary compare errors.

raptorhal2 · ‎2011-09-01

Posted on September 01, 2011 at 15:27

Only 2 or 3 pins are being set to GPIO_Mode_AIN instead of 4. Perhaps you have fixed that already. This is unlikely to be the source of the strange behavior.

If your DMA is writing to flash, it should immediately trigger a fault, since flash writing isn't enabled in your program. Do you have ISRs to handle unexpected faults?

If you are convinced DMA writing to flash is the problem, reprogram to convert one set of values and stop. Single step with your debugger to see if you can spot the problem.

When is the checksum test done ? If this is a loader checksum, your code shouldn't be executing yet. If your code is doing the checksum, perhaps we need to look at that for errors.

Cheers, Hal

karsten23 · ‎2011-09-05

Posted on September 05, 2011 at 23:01

Hi.

thanks for your input and sorry for the delay.

The missing pins are due to the fact that 2 of my 4 ''pins'' are virtual ones - or better - internal channels of the cortex (power reference and temperature). Those do not need to be set up - as far as I know...

The hard-fault and my dummy IrqHandler are never called (at least not because of that problem... ;) ).

I fear my idea with the flash and dma might have been wrong. After a successfull flash of the device I can go as often through the ''endOfConversion'' Interrupt as I want to without any bad things happening to the flash area. The flash gets corrupted sometime else. It only happens if the DMA is inside the code and only after that code has been executed but not WHILE or directly AFTER the code is/was executed.

Without DMA I can reprogramm the device without a power-cycle as often as I want and debug and work with the device. If I switch on the DMA I need to power-cycle the header-board before reprogramming, because only after a switch-on + off procedure the binary check will succeed.

Currently I can work with the device and get useful ADC results as long as I always power-cycle the device before flashing it. This is annoying but at least I can work with it.

BUT as I do not know why those strange things happen, I'm concerned that I cannot have faith in my SW+HW toolchain - maybe other strange things happen also, without being recognized currently... more subtle... :(

Regards,

Karsten

raptorhal2 · ‎2011-09-06

Posted on September 06, 2011 at 16:43

You seem to have a typo in void isr AcdEOC(void). Is the pointer set to Acd or Adc, or did you fix that in the restructuring?

My next suggestion is to remove all proprietary code to make an ADC/DMA test case. If the problem still repeats, post the complete test case code and perhaps we can spot something. If it doesn't repeat, then you know you need to look elsewhere.

Cheers, Hal