Hello, first please kindly understand that I know perfectly well that Engineering problems are usually very comprehensive issues which may not be the caused by one single IDE, hardware or software alone but I really don't have a better idea of where to turn to for solutions or suggestions. And at least on face value, this whole situation that I'm facing right now looks like I can get some very constructive pieces of advice from this forum than any other.
So, here goes the description of this problem:
I'm working on a project using my custom built development board. The MCU I'm using is a Cortex-M3 one, STM32F105RB series to be more precise. I download 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 (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 isn't 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.
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.
So I'm here looking for clues, but besides that, here is some more input, a possible cause if you will.
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 . 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 fault, 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 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 completely at my wits' end, I don't know where to begin.
Thank you for your time and attention.
Do you have the same crystal frequency on your board and the reference board? If not, then you might possibly overclock your own board when the program starts to set up the PLL configuration.
One way to handle issues with JTAG in regards to this kind of problems is to have the program start with a minimum of hardware initialization and then enter a delay loop. First after the delay loop, it can start to set up PLL, additional clocking etc. This gives you time to break the program while it is busy with the loop and then single-step into the hw initialization code and see where you lose the board.
Per;
Forgive me for high-jacking this post to say thank you very much for the excellent suggestion for debugging start up debugging problems.
Bradford
Thank you Per Westermark, I tried that but it didn't work. I put a loop at the very, very beginning of the main () function (as "beginning" as I could before any other function). It looks as if it didn't even reach the main ()function so the loop couldn't be executed at all.
And Yes, I am sure that both boards have the same xtal frequency.
Still waiting further, more suggestions and thanks anyway...
Hi,
is the project running on a "standard" board (i.e. MCB, ST Discovery)? Can you create a project that you can snd to Keil Support?
Then I could have a look at that.
BR, /th.
Hello Buhr, sorry for the late reply.
No, the project isn't running on a "standard" board. It's customized, self-made.
I don't think it's necessary to send you the project, because the whole matter has just twisted into a new direction: both projects are now running fine on my reference board, or "standard" board if you will. To be perfectly honest, I don't remember changing anything to the reference board other than downloading both programs a few times. It sort of fixed itself, which is quite confusing as it acts like something organic.In other words, I'm not fairly, at least 90% sure that it is a hardware problem.
Both project still have the same old problem on my custom board, I can send the jpg picture (or png for that matter) of my hardware schematic to the keil support, although at the moment I'm not sure where exactly should I send the file.
Thank you for your help and reply.
John
http://www.keil.com/support/contact.asp