2015-12-16 01:20 AM
I've been trying to upgrade the firmware on my STM32F105 project by using DFU through USB. The problem is that I need to read ADC using DMA for both the boot code (to check whether some switches are set right to allow DFU), and in my main application. What is the best and safest way to ensure that the destination memory locations for the DMA are the same in both the boot ans application projects. I'm pretty sure that this is what is stopping things working at the moment.
I currently declare the array as follows: __IO uint16_t ADCConvertedValue[5]; The line in the DMA initialisation, using standard peripheral libraries is: DMA_InitStructure.DMA_MemoryBaseAddr = (uint32_t)&ADCConvertedValue; Any thoughts?2015-12-16 03:37 AM
I've realised that the memory location is in CMAR1, so I'm going to try getting at it through that. Any thoughts still welcome.
2015-12-16 05:32 AM
The most robust solution would be for the bootloader to teardown it's configuration of the DMA/ADC before it hands off control.
If you want a fixed memory address you'd probably want to use a pragma/attribute arrangement, along with a suitable scatter file or linker script. If there are other common things you could carve some space out of the RAM allocation, and place the structure outside the linker's reach and access it with a fixed pointer. Perhaps at least 16 bytes. Review the documentation for your tool-chain.2015-12-17 08:54 AM
Thanks Clive,
Your first suggestion seems to be holding up well. Disabling and de-initialising both ADC and DMA in the bootloader before jumping, then reinitialising from scratch in the application is working every time. Everything else I tried seemed to upset the circular buffer, so different ADC channels ended up in different memory locations every time I started up.