AnsweredAssumed Answered

STM32 can't do simmulation properly with Jlink in debug mode,Keil μv4?

Question asked by cuneo.john on Dec 18, 2014
Latest reply on Dec 20, 2014 by Clive One

Hello,

 

I'm working on a project using my custom built development board. The MCU I'm using is a Cortex-M3, STM32F105RBT6. I download my program using JTAG method via a Jlink.

Everything seems to be fine except that after I hit the magnifying glass icon and entered debug mode in Keil μv4  (the program would usually be burned into the MCU smoothly and rapidly, by that I mean well within 15 seconds, at 1000KHz JTAG clock rate, which suggests there doesn't seem to be a major connection problem), and I hit the F5 key, expecting the program to run until it encounters a break-point, it doesn't. It stops all by itself without any notable warning or error message.

I've put a close loop at the beginning of my main () to see at what point do I "lose" my program as suggested by someone else from keil forum, but it seems the whole simulation stops before it even reaches the main (), let alone executing that loop.

If I load up the Jlink graphical interface, the status bar at the bottom would usually reads:

JLINK_Go
JLINK_IsHalted (running)
JLINK_ReadingMemory
JLINK_ReadReg (Done)

Of course I can see all that by lowering the JTAG clock to 5kHz.Or else everything would just go super fast.

 

Now come to think of it, The program I wrote kinda interfered with the JTAG connection by possibly initializing the alternative function clock of those JTAG pins (so the interference happens after the MCU was booted up, not when downloading of course). I verified that by downloading it to another development board manufactured by certain company for reference sake . It turned out that it has exactly the same issue after I downloaded the program, entered debug mode and hitted F5. If I download another program that I wrote earlier of which I am sure has no interference whatsoever with the JTAG connection, everything went just fine in debugging mode.

But here is the most frustrating part: I tried to download the aforementioned "non-interfering" program into my custom built board, hoping this "self-stopping" problem could be eliminated which would rule out a hardware error, and it turned out the problem remains! In other words, my earlier, "non-interfering" program also stops all by itself right after F5 being pressed in debugging mode.

Somehow, it seems, the problem is both hardware and software and they are "collaborating" with each other, almost pure coincidentally (I certainly have no intention of causing the problem myself). To concisely put it:

Not my board + my problematic software = problem.
My board + my non-problematic software = problem.
Not my board  + my non-problematic software = everything is fine.

I've checkboxed and optioned the whole chip to be wiped clean every time before a new program to be downloaded instead of just erasing just sectors, and the purpose of that is to rule out "residue" code from last time, which of course would be a logical thing to do.

So, can please some one be kind enough to give me some advices or clues? I'm kinda lost on this one.

Thank you for your time and attention.

Outcomes