Cart New Account Login

HomeAbout usProductsSupportForumsBlogCustomer Service

search inside this forum
Debugging from first instruction
Massimiliano P. Apr 15, 2015 at 01:21 PM (13:21 hours)
Staff: Takao Y.

  • Hi,
    I am using a Multilink Universal FX with a Kinetis KL05 by KDS on Linux. As soon as I program the chip, I get an hard fault. If I reset and run the firmware, everything works fine. The fault occurs only after the flash programming.
    I'd like to investigate this, but even if I place a breakpoint on __thumb_startup() (which ought be the code execution starting point), the execution doesn't halt. On the other hand if I reset and restart, the execution hits the breakpoint.
    Is it possible to halt the excecution and proceed instruction by instruction to catch the problem right after the flash programming? Thank you.

    Best

    Massimiliano




    Comments

  • Greetings,

    Could you run a simple test for me. Could you create a new KL05 project and make no modifications. Try debugging this simple project. Does it work? If so, then there is something in your code causing this fault. If it does not work, then there is something wrong in the P&E's implementation and we will have to try to replicate this problem.


    Takao Yamada

  • Hi Takao,
    thank you for your prompt reply.
    Actually I am pretty sure I'm doing something wrong because other projects work as expected, also I managed to get an empty project to stop on __thumb_startup. The question was about how do I employ the debugger to find what I did wrong, sorry for not having been more clear.

    My case involves an image built from two firmwares - a bootloader and an application firmware. The execution starts in the bootloader and then is transferred to the application firmware.
    I checked in the memory dump and verified that the boot block at 0x00000000 is correct (sp=0x20000C00 and pc=0x000001b1). The bootloader elf symbols are used so __thumb_startup points, as expected, to 0x000001b1).
    In the "startup" tab of the debug configuration, "Set breakpoint at" I tried both 0x01b1 and __thumb_startup, but got no result.

    Also I tried to debug the bootloader alone and it worked.
    So my question is - is there any condition for which the execution skips a breakpoint or immediately jump into the interrupt vector? Thank you.

    Best

    Massimiliano

  • Greetings,

    Which interrupt vector are you starting at? This could be a clue.

    If you try stepping do you ever get to the location of where you placed your breakpoint? Do you constantly find yourself getting reset back to the start and never being able to move forward? This could be the fault of the watchdog. If you do not have it disabled in your code, then the watchdog is causing resets periodically.


    Takao Yamada

  • Hi Takao,
    after quite an intensive investigation, I found what I did wrong. In the processed hexfile (the one composed by the bootloader and the application firmware) the CS:IP line was missing. In this way the debugger couldn't assign the correct address to the program counter. After a reset the PC is reloaded from the flash address 0x00000004.
    Apparently the debugger loaded the PC with 0x00000000 and started the execution.

    Best

    Massimiliano

Add comment


   Want to comment? Please login or create a new PEMicro account.







© 2017 P&E Microcomputer Systems Inc.
Website Terms of Use and Sales Agreement