STM32F4 Discovery stuck waiting for PLL in uVision simulation

[Mark Edwards]

Posted on November 07, 2013 at 01:30

Hi

I am migrating a project to the STM32F4 Discovery and have managed to strip the Template program down to it�s minimum components as a base but have come up against a strange problem.I can run the original Template program (and the cut down version) OK but when I try to run them under Keil�s uVision Simulator mode they get stuck waiting for the PLL to come ready. Is there any way to fix this or should I just rem that out whilst using the debugger?Another anomaly running simulator is the need to allocate the memory 0x40000000, 047FFFFFF (which I think is part of the IO memory space) to read write but I got around that by allocating it in the debug.ini file.uVision V4.72.10.0 #stm32f4-discovery-pll-error-65

[Tesla DeLorean]

Posted on November 07, 2013 at 02:14

http://www.keil.com/dd/chip/6103.htm

Use real hardware, its cheap and available.

[Mark Edwards]

Posted on November 08, 2013 at 19:53

???

Of course I have the hardware (a really impressive board for the price) and as I said running the code on the board doesn’t throw up the problems I get running it under the simulator. Rem’d out all the PLL waits and the debugger seems to work OK although I haven’t got the USART IRQ’s to work yet so perhaps there’s another problem. I am about to run your sample code and if that doesn’t work under the simulator I will try it on the board and see if it’s the sim that’s the problem. I have also tried it under the latest uVision5 with the same results. Where possible I use the sim as it means I don’t need to have the board plugged in (wearing out the Flash, each time I make a minor fix and I can work on the train without having to have the board plugged in) while I am debugging the code. Another gripe is that uVision doesn’t have the user friendly overview screens (under Peripherals) for things like GPIO, USART, etc  but only gives the raw System Viewer options  with the F4xx which were so useful when working with the F1xx.

[Tesla DeLorean]

Posted on November 08, 2013 at 20:26

I am about to run your sample code and if that doesn?t work under the simulator I will try it on the board and see if it?s the sim that?s the problem. I have also tried it under the latest uVision5 with the same results.

Keil's stated the simulation is absent key features, per earlier cite, so I'm not sure how helpful it's going to be. You'd want to push into your support contact at Keil if these feature(s) are critical. As someone who grew up erasing EPROM's under UV lamps, I think >10K erase cycles, with an erase under a minute, this isn't going to be a limiting factor. As I recall uv3 had a nicer peripheral view, but beyond a quick glance to double check settings it's rather invasive in the debugging process as it interferes with internal states.

[Mark Edwards]

Posted on November 08, 2013 at 23:40

“As someone who grew up erasing EPROM's under UV lamps�?

LOL. Been there. Done that.

OK, the problem seems to be with uVision.

Using the hardware, all is OK (Thanks for the code, Clive), using the Simulator in uVision the TC bit in USART_SR doesn’t get set, which means the program can’t continue past the test.

I really hope Keil gets the problems sorted, as it’s a major pain for me, not to be able to run the code under the simulator (which worked so well using the STM32F103).

[Tesla DeLorean]

Posted on November 09, 2013 at 19:30

Given the length of time Keil has been in this state, and the myriad of part variations (memory, peripheral, etc) I don't see this being remedied. Those with specialized needs for simulation/emulation have other avenues, and a better gate level understanding of the core and attached peripherals. Perhaps something to broach with sales when the support contract comes up for renewal? Pushing back into Keil's support/sales is the best way to effect change, or at least understand if your issue has any traction.

While I can see the value of simulation, it too often falls short of how the hardware actually behaves, leading to people to come to me with ''well it works in the simulator'' type admonishments, which usually elicits a response from me that they should step out of the reality distortion field, and explain to me what's wrong with the simulator.  Around here we try to evaluate functionality of C code on a PC, and build a harness at the hardware abstraction level, and provide stimulus from scripts and files. The TC flag of the USART is something I'd avoid unless you need to know when the last bit left the wire, rather than when the holding buffer is empty as the first bit shifts out, ie changing baud or other settings, or switching an RS485 driver. Routines should typically front test the status for TXE, rather than back test for TC, or service the USART from a buffer on a TXE interrupt. The TC and error flags are also susceptible to reads of DR, which is where the debugger can interfere with reality as it doesn't have a magic method of accessing registers without changing internal states.