2011-08-30 01:51 AM
2011-08-30 04:01 AM
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, Hal2011-08-30 05:59 AM
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, Hal2011-08-31 02:14 PM
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, Karsten2011-08-31 03:06 PM
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.2011-09-01 06:27 AM
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, Hal2011-09-05 02:01 PM
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, Karsten2011-09-06 07:43 AM
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