JLink Edu broken? Possibility for testing the device?

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • JLink Edu broken? Possibility for testing the device?

    Is there a possibility to test an jlink edu to test for malfunction?

    I've been using the jlink edu since months and it was really great. But suddenly the device failed: all programms I wrote got stuck in the hardfault handler of the controller. Stepping throug the code, I noticed, that the odyssey begins after the init in the startup code.
    Nothing went wrong with the hardware, from one day to an other I couldn't debug anymore.

    System is:

    Win7/32
    emIDE 2.14
    STM32F103RB Olimex H103 Evalboard (but this error occurs on other boards too)
    jlink V4.80f

    Can anybody help?

  • Hi,

    I do not really think that your EDU is broken...
    If it can communicate with the device and even program the flash, J-Link is working fine.
    Do you have another board around for testing?

    Stepping throug the code, I noticed, that the odyssey begins after the init in the startup code.

    Another hint that it has nothing to do with the EDU hardware...

    Are you sure that you changed nothing on the target-application side?


    Best regards
    Alex
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/
    Or you can contact us via e-mail.

  • Hi Alex,
    "

    I do not really think that your EDU is broken...

    If it can communicate with the device and even program the flash, J-Link is working fine.
    That sounds good...
    Do you have another board around for testing?
    Yes, I have two other boards and I tried them before too (in case the proc would be defective..). But the failure was reproducible.
    Are you sure that you changed nothing on the target-application side?
    Hmm, sure I did changes in the source code, but nothing in the linker file or setups.

    Finally I tried a new installation of the toolchain, but this made the same results :(

    Kai

  • Hi,

    Could you send a sample project for the STM32F103 which can be used to reproduce the problem you are seeing?


    - Alex
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/
    Or you can contact us via e-mail.

  • Hi Alex,
    see attached file. It is the basic setup for a simple datalogger.

    Strange was, that, as I setup a new very simple project, it works, so the debugger istn't really not defective, it seems to me.
    But loading any existing project, it turns on from start... ;(
    So there must be a bug in the source or settings, but I really have no idea, where to have a a look for. And on the other side, all those projects worked well till last weekend.. then they stopped working all at one time.

    Regards
    Files

    • FS_Test.zip

      (601.84 kB, downloaded 574 times, last: )

  • ... and the jlink edu IS defective... ;( ;( ;(

    a friend of mine work's with the "big" jlink's and he tested it in his enviroment... though he don't touch the hard fault handler, the debugger don't respond anymore there.
    He'll lend me his this evening to crosscheck, if it would work again.....

  • Hi,

    I gave your project a quick try and also end up in the HardFault handler.
    So, is my J-Link also defective? I do not think so....

    Why don't you debug this problem? Because this is what J-Link is for...

    I have put a "return" into the HardFault handler and set a breakpoint on it.
    Now I Let the target hit the breakpoint and leave the HardFault handler by instruction-stepping out of it via Alt + F11.
    Now I see that the application crashed in

    C Source Code

    1. void xvprintf ()


    The exact place within xvprintf() where it crashes differs from session to session, but usually it is a

    C Source Code

    1. *fmt++


    So, I am still pretty confident that not J-Link is the problem here, but your application code.
    I give no guarantee that the problem is really caused by the xvprintf() since the stack may already be overwritten and so messed up, when the HardFault handler is entered, that a proper call-stack may not be shown properly.
    Take a simple project that does nothing except a generic Cortex-M3 startup + incrementing a counter in main() and I promise you:
    You will not get into the HardFault() handler.

    see attached file. It is the basic setup for a simple datalogger.

    Are you kidding me? This is anything but not a simple project.
    It contains a "filesystem", complete SystemInit, printfs, ...
    There are multiple, possible error sources.


    Best regards
    Alex
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/
    Or you can contact us via e-mail.

  • Hello Alex,
    thanks for the hint... but it seemed strange to me, that projects which worked fine all time long, suddenly didn't anymore.
    Take a simple project that does nothing except a generic Cortex-M3 startup + incrementing a counter in main() and I promise you:

    You will not get into the HardFault() handler.
    That was, what I wrote above, and yes, you're right, I didn't ran into the fault handler... but anything more could chuck me out, and I really don't know, what... sometimes only a simple memset call can ran the target out into wilderness. So the thought was really a hardware defect.

    Sorry for wasting your time.

  • Hi,

    My suggestions:
    Initialize the RAM with a test value before running through any low-level init etc.
    If you get to the HardFault handler, check the RAM contents if they give any hint that an array near the stack was written out of its boundaries and overwrote stack contents etc.
    Strip down the project until it works, then take in part by part to check when it stops working.


    - Alex
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/
    Or you can contact us via e-mail.