* We advise that on this target you keep STARTUP_FROM_RESET undefined whilst....

Comments

5 comments

  • Avatar
    Jason Beens

    Just make an entry in your preprocessor definitions for STARTUP_FROM_RESET when you are building a release configuration.  This works well enough on the 2148, 2138 and 2106 platforms that we use.  Difference between the debug and deployed configurations is unavoidable.  The only way to keep the configurations identical would be to ship the device to the field with a JTAG debugger attached, or to somehow debug without a target adapter.  A good suite of system integration testing will let you find differences between your development and deployment builds, should they exist.  In my experience, the CrossWorks environment has provided a "what you see is what you get" experience with those LPC processors.  Any problems we encountered were ulitmately shown to be the result of quality issues on our side of the equation.  Use the recommended approach, and it will work fine. 

    0
    Comment actions Permalink
  • Avatar
    Paul Robert Gaastra

    Thanks Jason.  As I said, I haven't spent much time trying to understand what's going on.  I am not very quick on the uptake. 

    All I know is that with the identical hardware using Eclipse and the debug plugin with my Olimex USB Tiny and my Olimex LPCP2103 pcb I could debug away and then disconnect the board from the USB-Tiny and the board would still work from power up with the same code. 

    0
    Comment actions Permalink
  • Avatar
    Paul Curtis

    The whole point of the STARTUP_FROM_RESET is that it is a safety belt.  Some LPC2000 devices can disable the JTAG port, and when ARMs crash, they can also take out the JTAG debug port.  Given the code goes straight from reset to user code that crashes, for instance, there is no way to recover that part now.  It's dead.  You can, on the LPC2000, try to erase it over the ISP interface, but some target boards and many customer boards do not have this capability.

    There are other problems too which I could mention, such as DMA, which interact badly with JTAG programming schemes.

    In short, if you want to turn on your board and see your code run, set STARTUP_FROM_RESET when you're confident it doesn't crash.  Don't develop with STARTUP_FROM_RESET defined, or else you could nuke your dev board with no means of recovery.

    0
    Comment actions Permalink
  • Avatar
    Andreas Kaiser

    Since this JTAG issue seems to be basically a timing issue, as the debugger has to catch up with the hardware after a reset, I've got the impression that a time delay loop instead of an endless loop should be sufficient, but still allow startup without debugger attached, just a bit delayed.

    0
    Comment actions Permalink
  • Avatar
    Paul Curtis

    A delay loop would be just as good, yes.

    0
    Comment actions Permalink

Please sign in to leave a comment.