Stuck with example[SOLVED]

[frankfrank953]

Posted on May 10, 2010 at 15:27

Stuck with example[SOLVED]

[frankfrank953]

Posted on May 17, 2011 at 13:50

OK cracked it, the ASM and linker file are now sorted and I have a running system again, now with the latest V3.3 libraries.

If anyone wants examples of  this setup for gcc so that you can use Eclipse and Yagarto toolchain PM me and I can email. Thanks for feedback guys.

[Andrew Neil]

Posted on May 17, 2011 at 13:50

''gcc is a wonderful beast but takes some configuring''

I think it was Jack Ganssle who said, ''so-called 'free' software is only actually free if you don't value your time''

[frankfrank953]

Posted on May 17, 2011 at 13:50

And then there are people who use Microsoft for their operating system......

Lots of people have time to waste, we all do it in different ways but just don't realise it ;o)

[daemonmaker]

Posted on May 17, 2011 at 13:50

Marc:

I'm experiencing exactly the same problem you describe here. Right down to the APBAHBPrescTable being corrupt. Can you please tell me how you corrected the issue? TIA, Dustin

[Tesla DeLorean]

Posted on May 17, 2011 at 13:50

I'm experiencing exactly the same problem you describe here. Right down to the APBAHBPrescTable being corrupt. Can you please tell me how you corrected the issue?

Please provide some more details of your code and tool chain. If things get corrupt as you execute code, it is usually because the stack is descending into the heap/static memory, or you have some other wild writes occuring. The quickest was to get messed up is to have stupidly large local allocations within subroutines, works great on Windows, works less well on an STM32 when you've only allocated 512 bytes or a few KB to the stack. Set your Debug/JTAG to monitor the memory area that is getting trashed, and add some breakpoints, instrumentation or single step until you see it getting changed. Write an obvious test pattern in the area so changes are obvious.

[daemonmaker]

Posted on May 17, 2011 at 13:50

Hi Clive1:

I'm using an Olimex STM32-H103 (http://www.olimex.com/dev/stm32-h103.html). I started with the blinky example (http://www.olimex.com/dev/soft/arm/ST/Eclipse-GCC-project-for-STM32F103.zip). Then I updated the ST Peripheral library to v3.3.0. All that works. Now I am trying to configure the USART. The problem is as follows: When I try to transmit data from the H103 the code ends up in an infinite loop on the line:USART_GetFlagStatus(USARTy, USART_FLAG_TXE) == RESET When I debug the issue with GDB over JTAG I see that the call to RCC_GetClocksFreq() returns a structure in which only SYSCLK_Frequency is set (i.e. all the other members of the struct are set to 0). I've tracked this back to the fact that the APBAHBPrescTable is corrupt. Furthermore it is corrupt from the get go (i.e. the moment the main routine starts the table contains the wrong data). I tried your suggestion to Marc of setting the stack size. That may very well be the issue. However when I attempt to compile the project with those changes I receive a syntax error on the first line of the code you supplied. I suspect your using something other than gcc and as such I am in the process of learning how to write the equivalent code for gcc. I was hoping that in the mean time Marc could tell me what he did to fix his issue as it's extremely likely that I'm experiencing the same problem. I hope I've included enough detail but please let me know if there is any other information that might be helpful. Thanks, Dustin

[daemonmaker]

Posted on May 17, 2011 at 13:50

I just noticed that the blinky example sets up the vector table in main.c as follows:

unsigned int * myvectors[4] __attribute__ ((section(''vectors''))) = {   (unsigned int*) 0x2000800, // stack pointer   (unsigned int*) main, // code entry point   (unsigned int*) nmi_handler, // NMI handler (not really)   (unsigned int*) hardfault_handler // hard fault handler (let's hope not) }; If I understand this correctly then it is placing the stack at address 2K. But my binary is a little over 4K. The end effect being that the stack is somewhere in the middle of my binary in memory. Am I interpreting this correctly? I tried setting the stack pointer to 0x20005000. While this changed the content of memory the table is still not right. Any suggestions? TIA, Dusitn