STM32F103 strange behavior

stm32

I'm working with an STM32F103 device and am experiencing some strange behavior that I'm not so sure about where start with when it comes to debugging it.
I previously asked a question regarding DMA problems with this device that I never quiet resolved. I've come back to look at this, but now suspect my DMA problems are related to something else.
I'm working on a custom board that, at the moment is just the STM32F103 device connected over SPI to an STM32F405 discovery board. SPI works fine in polling mode and now I'm attempting to get SPI and DMA working again. My problem is that I can get it work intermittently but it seems to be dependent on initialisation of variables. For example, I can get SPI working with DMA well if I initialise some variable in my main() function.
EG:

int main(void) {
    uint32_t spiBase = 0;
    // etc, etc
}

However, if I then initialise another variable under this one DMA will stop working.
I'm really at a bit of a loss on how to go about debugging a problem like this!
Currently, I'm using the arm-none-eabi-gcc compiler with a Makefile I grabbed and modified that was originally intended for STM32F405 devices (from here: (http://liviube.wordpress.com/2013/04/22/blink-for-stm32f4-discovery-board-on-linux-with-makefile/), along with Texane's st-link utility.
It is entirely probable that my Makefile or linker configuration is a bit screwy!
Can anyone offer any advise on where I might start with strange problems like this?!

Best Answer

I may have figured this out. I have been using ST standard peripheral library to configure and use the SPI and DMA controllers (among others). I noticed that the SPI configuration registers were inconsistent depending on the declaration of variables at the start of main(). As an experiment I set the SPI config registers explicitly, eg as SPI1->CR1 = 0b0000100100110011. And everything works fine! I'm honestly still a bit confused as to why this might be a problem. I have been setting up the ST code as such: Under main() I declare

SPI_InitTypeDef     SPI_InitStructure;

Then further on down the track I initialise the SPI peripheral 

SPI_I2S_DeInit(SPI1);
SPI_InitStructure.SPI_Direction = SPI_Direction_2Lines_FullDuplex;
SPI_InitStructure.SPI_Mode = SPI_Mode_Slave;
SPI_InitStructure.SPI_DataSize = SPI_DataSize_16b;  //SPI_DataSize_8b; 
SPI_InitStructure.SPI_CPOL = SPI_CPOL_High;                     // SCK idle high
SPI_InitStructure.SPI_CPHA = SPI_CPHA_2Edge;                    // second transition -> SCK Idle high => capture on rising edge of clock
SPI_InitStructure.SPI_NSS = SPI_NSS_Hard;                       // SS must be low during entire SPI transaction
SPI_InitStructure.SPI_FirstBit = SPI_FirstBit_MSB;                
SPI_Init(SPI1, &SPI_InitStructure);

But still there are shenanigans. Anyway, I will update if I make any more discoveries. I think I might abandon the ST peripheral library for initialisation, etc. Thanks again

Related Topic