• State Not Answered
  • Locked Locked
  • Replies 4 replies
  • Subscribers 22 subscribers
  • Views 5857 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

uVision crashes on debugger start

Ralf Hochhausen

Hi,

I'm using the MDK v4.21 with the ULink2 for debugging. My problem is, that the uVision crashes as soon as I press the debugging button to start debugging. I use the uVision only for debugging my software via a *.elf (dwarf2) input file. The software is compiled externally via a makefile. I found out, that the debugger does not crash when I disable the "Load Application at Startup" option in the Debug tab within the configurations. As soon as I enable this option, the debugger crashes. The device that I use is the STM32F103ZE on a STM3210E eval board. Crahsing does not depend on the interface (JTAG/SW).

I was already able to debug with my setup. I'm not sure what I have changed that can caused the crashes. When I load a small demo elf-file from the STM Discovery board the environment does not crash.

Any hints what could be the reason for these crashes? Which further informations are needed to find the reason?

Thank you,
Ralf Hochhausen

Here are some more detailed infos about my environment:

IDE-Version:
µVision V4.21.0.0
Copyright (C) 2011 ARM Ltd and ARM Germany GmbH. All rights reserved.

License Information:
BSH BSH
BSH
LIC=KRMIR-H85IY-45PKD-6D2UY-UULUB-2UWX9

Tool Version Numbers:
Toolchain: MDK-ARM Standard: 8 user Version: 4.21
Toolchain Path: BIN40\
C Compiler: Armcc.Exe V4.1.0.713
Assembler: Armasm.Exe V4.1.0.713
Linker/Locator: ArmLink.Exe V4.1.0.713
Librarian: ArmAr.Exe V4.1.0.713
Hex Converter: FromElf.Exe V4.1.0.713
CPU DLL: SARMCM3.DLL V4.21
Dialog DLL: DARMSTM.DLL V1.62
Target DLL: BIN\UL2CM3.DLL V1.90
Dialog DLL: TARMSTM.DLL V1.60

Parents
  • 0 in reply to Ralf Hochhausen

    Hi Ralf,

    It seemed at first that the problem was related to the STM32F207 but at some point we saw it crop up on another part, I think it was a newer STM32L152 but I can't quite remember. We also saw some dependency on the code itself, small demo projects worked but larger projects did not.

    I think you're right, the debug module is largely the same but we did notice that the 152s and 207 have a different way of setting up trace mode so there are at least some minor differences.

    Andrew

Reply
  • 0 in reply to Ralf Hochhausen

    Hi Ralf,

    It seemed at first that the problem was related to the STM32F207 but at some point we saw it crop up on another part, I think it was a newer STM32L152 but I can't quite remember. We also saw some dependency on the code itself, small demo projects worked but larger projects did not.

    I think you're right, the debug module is largely the same but we did notice that the 152s and 207 have a different way of setting up trace mode so there are at least some minor differences.

    Andrew

Children