[SOLVED] IRQ input configuration lost following debugger halt

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

  • [SOLVED] IRQ input configuration lost following debugger halt

    Hi

    My application runs on a K60, and I'm able to debug using the excellent Ozone tool. However, I'm experiencing something unexpected when I halt a debugging session;

    My application configures certain inputs from their default state to act as IRQ sources for external peripherals, which all work as expected following initial startup. If I then halt the debug session (e.g. hitting a breakpoint), these inputs appear to get reset to their default settings, and therefore no longer operate as IRQ sources once the session is resumed.

    This may have nothing to with Ozone/J-Link, but I wanted to first check to see if it might be happening by design, in which case whether I'm supposed to cater for this somehow...

    Many thanks

    David

  • Hi David,
    We will check if J-Link does not restore some registers correctly.

    Could you please tell us which registers are being affected?

    Best regards,
    Fabian
    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 Fabian

    Thanks for your prompt response

    It's the Port Control and Interrupt (PORT) registers that are being affected

    The attached image indicates my particular use-case. Initially, execution is halted and PortA[10] is set to the required value. Single-stepping to the next line sees PortA[10] having been reset to default.

    Hope this is helpful-

    Kind regards

    David
    Images

    • PinConf.png

      103.7 kB, 1,732×1,049, viewed 413 times

  • Hello David,

    Thank you for providing additional information.
    The J-Link DLL will try to automatically configure the trace pins (also located on Port A) if you have pin tracing enabled. Unfortunately it is not implemented as a read modify write which cancels out your application settings.
    This will be of course corrected.

    As a workaround for now we recommend to use the K66 JLinkScript from our example project for the emPower board:
    wiki.segger.com/Tracing_on_NXP…2M0_(SEGGER_emPower_Board)

    There in the Project you will find a JLinkScript file. Simply include this in your Ozone project just like in the example project and everything should work as expected as the JLinkScript init will override the DLL behaviour and do a read modify write as you can see in your script source.

    Sorry for any inconvenience caused.

    Best regards,
    Nino
    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 Nino

    Thank you for looking into this so quickly and for your explanation.

    I'm still a little puzzled as to why this trace pin configuration is happening at all, since I haven't explicitly enabled trace pins (assuming that this would be done via Project.SetTraceSource ("Trace Pins") in the .jdebug project)- Does the DLL attempt to configure the trace pins regardless of whether they've been specified?

    In any case, having taken the OnTraceStart() function from your example and added it to my JlinkScript I note that that the IRQC field of the port pin is now being retained, however the MUX pin function is still being altered (and left as alt7). Since I'm not interested in using trace pins, removing the body of the OnTraceStart() function (i.e. leaving an empty function simply to override the DLL's implementation), appears to leave my port pins in the state the application has set them, which appears at the moment to be a working solution

    I'd be grateful if you'd confirm that this empty OnTraceStart() function is a viable workaround

    Kind regards

    David

    The post was edited 2 times, last by dnfuss ().

  • Hello,


    dnfuss wrote:

    I'm still a little puzzled as to why this trace pin configuration is happening at all, since I haven't explicitly enabled trace pins (assuming that this would be done via Project.SetTraceSource ("Trace Pins") in the .jdebug project)- Does the DLL attempt to configure the trace pins regardless of whether they've been specified?
    Trace pins are only active if enabled by the user in the Ozone project settings under Tools->Trace Settings.
    Do you still see this issue if this setting is set to None?


    dnfuss wrote:

    I'd be grateful if you'd confirm that this empty OnTraceStart() function is a viable workaround
    Yes that is a viable workaround as it overrides the default behaviour of the DLL.
    However if you do not enable it with any software tool they should never be configured.

    Should you still see this behaviour after explicitly disabling it in Ozone could you provide a J-Link log file for reference?
    wiki.segger.com/Enable_J-Link_log_file#Ozone

    Best regards,
    Nino
    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 Nino

    Ah- Perhaps the issue is explained by the fact that I'm using the Trace Buffer (as distinct from Trace Pins), which appears to also enable Trace Pins -Is there a way of enabling/disabling Trace Pins independent of Trace Buffer?

    Regards

    David

  • Hi David,

    Thank you for the additional information.
    Yes selecting trace buffer will also trigger whatever config is saved in the OnTraceStart function as per definition that function may be used for ETB or Trace pin init steps.

    But to improve the behaviour we will adapt the default config on DLL side so it will distinguish what trace type is selected and do the corresponding initialization.
    So for existing setups nothing will change, but for setups like yours you will not need the "empty" OnTraceStart workaround to use the trace buffer and configure the pin registers as you want in your application.

    Best regards,
    Nino
    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 Nino

    That sounds like an elegant solution, thank you.

    May I enquire as to whether that will make it into the next J-Link DLL release? If so, I might hold off applying the workaround to our various jlink scripts...

    Kind regards

    David

  • Hi David,

    Next release will have the short term fix where the trace pin init only touches the registers it actually needs via read modify write.
    So as long as you do not use the trace pins for other functions you should have no issues.

    Long term we will improve it as described above so no trace pin init is done whatsoever if ETB tracing is on. But this requires some more complex changes and testing, so it might not make it into the next release.

    Best regards,
    Nino
    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.