STM32F1 debugging problems

[gxti]

I'm trying to get my first ARM project off the ground, using a STM32F103C6. I had some early success, getting the LEDs to light, then PWM configured, even switching to the external crystal and 72MHz PLL. But now I'm trying to get the UART to speak and it's become hell. Small changes to the code, like swapping lines of code, result in the thing not booting at all, and the debugger just makes things worse. If I configure the UART output pin as a GPIO and toggle it I can see it on the scope, but when I configure it for UART the line stays high and doesn't change. This suggests that the UART is indeed connected (it idles high) but isn't much use.

At the moment, my program lands in the MemManage exception handler. According to the ARM docs, since I'm not using a memory protection unit the only cause of this is trying to execute a not-executable code section, probably the stack. I don't have any way to get the faulty program address because the debugger fouls things, but I do know it's hitting MemManage because I can turn on a LED from the handler. If I attach gdb, that's when the weirdness starts. I can single-step through startup.s for a while but eventually it hangs and when I press Ctrl-C I'm now in the HardFault handler. If I put some code in the HardFault handler to retrieve the calling program address I get a nonsense address entirely outside the memory map, but it could be a problem with the code to get the address. This clearly smells like something pooped on the stack but I can't think of how to diagnose it when my tools don't work.

Tools I'm using: STM32F4 Discovery (as a ST-link adapter), openocd 0.6.0, gdb 7.2. The good news is that, unlike last time I tried ARM, this toolset seems to be able to reliably program the chip. Not so much with the Bus Blaster, which failed 9 times out of 10.

Anyone recognize the problem, or can recommend some known-good software for programming and debugging STM32? Preferably free, but at this point I'd pay a few hundred dollars for something very good. I want to get out of PIC land and into the happy place of 32-bit MCUs with full debuggers but I'm already at the end of my rope and I've only just begun...

[andersm]

Stack corruption is the likely answer. Enable warnings in your compiler, pay attention to all your array indexing and pointer arithmetic, and make sure you don't use uninitialized variables. If your toolchain doesn't do it already, install dummy infinite loop handlers on all unused interrupts.

I've used the GCC+GDB+OpenOCD+FT2232 combo without too much trouble. Note that you really have to compile with -O0 or -O1 at most when debugging. If you're on Windows you could try the Keil evaluation version, just make sure your JTAG adapter is compatible.

[jeremy]

I don't have the answer for you, but I learned a very good lesson when I started with STM32 chips. Make sure you read the errata! The whole damn thing! Micros are extremely complex devices, and the designers are human just like you.

I'm not saying there is a silicon bug that is causing your error, but I hope you aren't intending to use hardware I2C with that chip That one cost me many hours.

[Christe4nM]

As for your question on which IDE to use: for ARM based micros I use KEIL's uVision (also called MDK ARM). Programming, flashing, and debugging went without problems. I've used it among other micros with both the STM32F4-Discovery and STM32L-Discovery.

uVision is free: they only ask you to leave your name/email, but you can fake that if you wish.
Link: https://www.keil.com/demo/eval/arm.htm

One final comment, I've experienced that the MDK-ARM files ST provides with the firmware package contain the wrong settings for 'flash & debug'.   On request I can post the correct settings that worked for me, but I don't want to go off topic too much.

[TinkeringSteve]

the Keil uVision eval someody recommended... is, last version I know et least, crippled, it let's you program only so much KB of flash.
And IMHO, if they'd had software in stoneage, Keil would be from that time.
While it does let you look at everything you'd want to look at in an embedded situation, the feel when using the "IDE" is like with Borland C++ 2.1 from 1992 or so. Forget about decades of development of features to boost productivity (and if it's only a logical menu structure - or project file vs. settings file structure, hah).

It would be the last thing on earth I'd personally use. Especially if you then consider the price of the non-crippled version.
Also, last versions I knew did not support anything but Keil's special horrendously overpriced debuggers... forget ST-Link then.

For very small projects I currently use CooCox CoIDE, a very cut-down eclipse-based platform. All clutter removed, so in case you instinctively hide under a stone when you hear "eclipse", have no fear!
CoIDE has no C++ support.
For the supported cortex processors, it's pretty hassle-free, to get some small projekt up & running.
The versions after 1.3, though,. give me problems debugging my F100 with an st-link, but 1.3 does not yet support the M4. SO I can't say much, since I haven't looked into that.

For bigger projects, where I use C++, I use the non-commercial version of Rowley Crossworks, around 150 bucks.
It has it's quirks, but mostly works and even I got support in the forums by Rowley employes upon problems, although the non-comm license states "no support", IIRC.
It is lightyears closer to "just works" than any of the 100.0% open source toolchains I've tried so far (still have nightmares from debugger setup...)
But the editor sucks big hairy ones, so I use MS visual C++ express for editing, and Crossworks for compiling & debugging. (note that MSVC does not cupport C99, if that matters)
Rowley provide their own RTOS with that IDE, and own libraries for the cortex MCUs, I don't use either to not make my software dependent on such product.
But one thing I might use is their library to have printf send text through the SWD HW debugger, i.e. no extra UART needed to have debug text output.

Btw: Crossworks runs on Linux and Mac OS, besides windows.

[gxti]

I attempted to evaluate CrossWorks once, it was not extraordinarily pleasant, but that was before I got the STlink and it just didn't want to talk to my BusBlaster. Not that I blame it. By the time the STlink showed up, there were 3 days left on my evaluation and I didn't spend enough time to get it working. I may attempt to evaluate it again.

Regarding the stack corruption, some experimentation I did this morning suggested that it was faulting even before main() got called. I'll see if I can instrument startup.s very early and debug by turning pins on and off :| Perhaps something wrong with my linker script, but I made it by copying one from the standard library and changed the ram/flash sizes and top-of-stack. At this point I have top-of-stack set to 2K even though I have 10K of RAM, just in case. The startup.s is similarly from the standard library.

[andersm]

Since you wrote that you had gotten code working it shouldn't be an issue, but double-check that all code is compiled and linked as Thumb-2 and not ARM or regular Thumb.

the Keil uVision eval someody recommended... is, last version I know et least, crippled, it let's you program only so much KB of flash.

That's why it's an evaluation version. However their high level of integration and good debugging support means it's easy to get started. Once you've outgrown the evaluation version your knowledge should be at a level making your range of choices much wider.

[gxti]

Apparently I have two problems (not surprising). Number one is that openocd is buggy, I'll have to give Crossworks another try instead. Number two, and by far the more confusing, is that the PLL was causing the heisenbugs. Not a smashed stack but rather a non-deterministic timing problem! I wasn't waiting for the PLL to become ready before switching system clocks, which according to the reference manual means it'll switch as soon as it is ready. This means that whenever it became ready, which has some uncertainty to it, the clock switched and then everything crashed for reasons I've yet to ascertain. If I deliberately wait for the PLL to ready, it crashes immediately. Things work if I back down to 64MHz instead of the maximum 72MHz so I've got some more digging to do, but at least I'm past the "oh god why is it failing kill me now" stage. I know APB1 has a max speed of 36MHz but I've been setting its prescaler to 2 all along, so it must be something else. Any tips and tricks for starting a 72MHz PLL?
Here's what I've got:

Code: [Select]

int main()
{
        /* Peripheral clocks */
        RCC_PCLK1Config(RCC_HCLK_Div2);
        RCC_ADCCLKConfig(RCC_PCLK2_Div8);
        RCC_APB1PeriphClockCmd(
                        RCC_APB1Periph_TIM2 |
                        RCC_APB1Periph_TIM3 |
                        0, ENABLE);
        RCC_APB2PeriphClockCmd(
                        //RCC_APB2Periph_ADC1 |
                        RCC_APB2Periph_AFIO |
                        RCC_APB2Periph_GPIOA |
                        RCC_APB2Periph_GPIOB |
                        RCC_APB2Periph_TIM1 |
                        RCC_APB2Periph_USART1 |
                        0, ENABLE);

        /* System clock */
        RCC_HSEConfig(RCC_HSE_ON);
        RCC_WaitForHSEStartUp();
        setup_gpio();
#if 1
        RCC_PLLConfig(RCC_PLLSource_HSE_Div1, RCC_PLLMul_9);
        RCC_PLLCmd(ENABLE);
        while (!RCC_GetFlagStatus(RCC_FLAG_PLLRDY)){}
        GPIO_SetBits(GPIOB, LED_GRN);
        RCC_SYSCLKConfig(RCC_SYSCLKSource_PLLCLK);
        while (RCC_GetSYSCLKSource() != 0x08) {}
        GPIO_SetBits(GPIOB, LED_RED);
#else
        RCC_SYSCLKConfig(RCC_SYSCLKSource_HSE);
#endif

[gxti]

Got it! Had to turn on a prefetch buffer for the flash program memory. Apparently it's required even at  48mhz, guess I was just lucky for 64MHz to work.

For posterity:

Code: [Select]

        FLASH_PrefetchBufferCmd(FLASH_PrefetchBuffer_Enable);
        FLASH_SetLatency(FLASH_Latency_2);
Now onto the real code. Thanks for your suggestions, I sense some Crossworks in my future.

[andyturk]

Apparently I have two problems (not surprising). Number one is that openocd is buggy, I'll have to give Crossworks another try instead. Number two, and by far the more confusing, is that the PLL was causing the heisenbugs. [...]

Are you sure you're having problems with openocd? It can be a pain to configure for custom hardware, but with the exception of one problem with the stlink-v1 implementation, I've had great success with it. I use it daily to to program/debug an STM VLDiscovery board that I've hacked to use an F103. Prior to that, I used it with an F4Discovery board.

I can't help much with clock initialization, which is tricky from the start. Seems like the thing to do is find some OEM code and use it without modification until you understand all the issues. I'm using Chibios (www.chibios.org), and it takes care of the low level initialization. It has pretty good STM32 support, so at the least you could use it as another reference implementation.

[gxti]

All I know is I can step for a few instructions, then it hangs. When I press Ctrl-C it usually puts me back on whatever line I was trying to step from but sometimes I get dumped into my HardFault handler, and I can try again. So I'm not sure it's openocd's fault, but I don't know enough to diagnose further. My config is trivial:

Code: [Select]

source [find interface/stlink-v2.cfg]
source [find target/stm32f1x_stlink.cfg]
reset_config srst_only srst_nogate
I'm interested in playing with a RTOS at some point but for this project it doesn't seem necessary at all. I'll try to remember that one, though. Thanks.

[andyturk]

There's an openocd section on the Sparkfun forum. Looks like someone got a similar setup to yours working (with some effort): https://forum.sparkfun.com/viewtopic.php?f=18&t=33398

[andyturk]

Here's another reference to some interesting STM32 clock configuration...

http://www.micromouseonline.com/2012/03/10/using-the-stm32f4-internal-oscillator/?doing_wp_cron=1347326241.3028800487518310546875

[gxti]

In case it wasn't clear, I had the 72MHz PLL working. Was doing quite well on the software side until I realized I chose poorly for a non-critical op-amp, apparently TL072 requires something like 4 volts of rail clearance but I needed to go to nearly zero. Oops.

But now after a small green-wire mod not really near the MCU (moving the Vss on the TL072 to -5V instead) I seem to have blown something up... it seems to run normally (PWMs running, UART outputting data), but the programmer won't talk to it and it runs quite hot to the touch. 180mA consumed on the 3.3v rail which is over the 150mA absolute max, although I have other things on the rail that probably add up to > 30mA so it should still be within bounds. I don't recall what the power consumption was before I green-wired. But other than not being able to program it at all and being hotter than I remember everything seems to be operating, so I'm quite confused. Perhaps a problem with the programmer, will reboot everything and try again when I get home.

Maybe I'll put together a second unit. I always buy a complete set of parts for at least 2 of every PCB I design unless it's hideously expensive :-)

[Torrentula]

qxti, could you post your OpenOCD config file (+ the STlinkV2 config)?

I am currently trying to use OpenOCD with my STM32F4-Discovery board (I've only used st-util / gdb before).

Thanks!

[free_electron]

By giving the opamp a negative voltage it is possible it outputted a transient pulling a pin of the stm32 below ground... And that will laatch up the device. You probably fried it...

[gxti]

The latest version of openocd (0.6.0) comes with a board file for STM32F4Discovery, so if you're programming the discovery board itself then your board.cfg can just be "source [board/stm32f4discovery.cfg]"

This is the config I'm using for a STM32F1 with the discovery as a swd adapter:

Code: [Select]

source [find interface/stlink-v2.cfg]
source [find target/stm32f1x_stlink.cfg]
reset_config srst_only srst_nogate
You can change the "f1x" to "f2x", etc.

[Torrentula]

Alright, thanks!

[gxti]

By giving the opamp a negative voltage it is possible it outputted a transient pulling a pin of the stm32 below ground... And that will laatch up the device. You probably fried it...

The mcu is connected to the opamp's input, not output, and only through 2 RC filters with a total of 110K of resistance. So unless there was some funny business with ESD diodes, there's no way that could leak through. More likely I plugged the wrong supply voltage in at some point, or brushed a wire against something unfriendly. Since swapping out the chip I haven't had any hardware problems.

[TinkeringSteve]

Since you wrote that you had gotten code working it shouldn't be an issue, but double-check that all code is compiled and linked as Thumb-2 and not ARM or regular Thumb.

the Keil uVision eval someody recommended... is, last version I know et least, crippled, it let's you program only so much KB of flash.

That's why it's an evaluation version.

Not every eval version of every product is crippled in functionality, smartass, so that should be mentioned if you advertise for it, otherwise I'd call you misleading.

However their high level of integration and good debugging support means it's easy to get started. Once you've outgrown the evaluation version your knowledge should be at a level making your range of choices much wider.

Their "high level of integrationand and good debugging support" is not better than many other IDEs out there, but their prices, forcing to use their overpriced debugging hardware, and annoying sort of copy protection for a rather crappy software (considering the price) makes me recommend people to think at least twice if it's really worthwhile to even try a ride on that horse.

Btw., even embedded beginners (but not programming beginners) can outgrow the eval version pretty fast. And if it's not even because of code size, but static data for some sort of applications.
I personnally wouldn't even touch software with a code size limit, with tweezers. "Nah, next candidate, please".

As for getting started quickly, for stm32,  I have not seen anything that comes close to CooCox CoIDE.