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

[StephanMair]

Posted on December 18, 2014 at 01:47

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.

[Tesla DeLorean]

Posted on December 18, 2014 at 05:01

If you hit stop where is the CPU?

Don't ''run to main'', uncheck that and step through the code from the beginning. Check that your clocks are starting, that the PLL locks. Most of this code is in, or called by, SystemInit() in system_stm32f1xx.c. Check the flash wait states, check the stack size. The SystemInit is called in startup_stm32f1xx.s, and is done before the runtime initializes via __main, and long before your main() function. Do you do anything that puts the device into a low power state, or reconfigures the GPIO associated with the SWD/JTAG connection?

[StephanMair]

Posted on December 19, 2014 at 14:42

Sorry for a late reply and thank you Clive, I know I can count on you to give me some tips. I'm caught in another project and am rather busy for the time being, I'll most definitely try to at least check most of your suggestions and get back to you as fast as I can.

Right now I can tell you that after the CPU stops, it stops at a fixed position, but it differs from simulation to simulation, the most notable instances would be: 0x20000004 780D      LDRB     r5,[r1,#0x00] (the above disassembly line appears to be the most common stop-point) and sometimes: 0x00009850 FFFFFEF6  DCD      0xFFFFFEF6   ; ? Undefined It's weird that it should behave so randomly.

[Tesla DeLorean]

Posted on December 19, 2014 at 14:49

0x20000000 suggests is running from RAM, or has jumped there.

[StephanMair]

Posted on December 20, 2014 at 01:30

Actually yes, I jumper-ed it there by setting boot0 and boot1. Because I was under the possibly false impression that Only ''boot from RAM'' can allow me to use breakpoints? I've tried ''boot from Flash'', the program can run smoothly (doesn't stop by itself) but I can not use breakpoints. I can add breakpoints in debug mode but the MCU never stops at those breakpoints, which is weird.

[Tesla DeLorean]

Posted on December 20, 2014 at 03:13

I don't have a problem using break-points in flash from Keil, but I'm not setting dozens of them either. The STM32 has a DWT (Debug Watchpoint Trace) unit which includes a hardware address comparator, rather than placing BKPT instructions in place of valid code.

Perhaps you should identify why it's not getting to the break-pointed code, because that's more plausible than it's ignoring them. If you have a problem identifying flow, you could use GPIO/LED to indicate progress, or output debug information via a USART or the SWV/SWO channel (Serial Debug printf). The Hard Fault handler is a good place to put diagnostic code, rather than a while(1), as broken systems often end up there.