• State Verified Answer
  • Replies 9 replies
  • Subscribers 63 subscribers
  • Views 1783 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 244396
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nRF52840 does not enumerate as USB CDC unless power cycled after download and run from IAR Workbench but works correctly when using Ozone

rzd

Hi,

We have a custom board that uses an nRF52840.  All our development is done on Win 10 based PCs.  Our custom board is connected to our Win 10 based PC via USB and when everything is working then we get a virtual COM port connection to our board. Our normal build and debug environment is the IAR Workbench.  We use both the latest 8.42.2 version and older versions and we have the same problem.  We use J-Link SWD adapters to attach to our board. The J-Link FW is updated to the latest version that was released on 2020Jan07. The reset line from the J-Link is connected to the nRF but it makes no difference for the problem described below if the rest line is or is not connected.  We do not provide power to our board from the J-Link.  The J-Link is connected to VTREF and the J-Link is always able to see the correct voltage on VTREF.

Our normal workflow is to compile, download and debug, then run (i.e. press F5) from within the IAR Workbench.  However when we do this the nRF is not enumerated on the USB bus.  The nRF starts running and the code is executed but the USB driver from the SDK is stuck in an error loop showing a USB Event is not ready error. (Note: I will try to get the exact error and add it to this posting later.)   We have to power cycle our board in order for it to be enumerated and detected by the PC.  Power cycling is done with the J-Link connected.  After we power cycle then we attach the IAR debugger to a running application and we can debug without any issues.

When we use the Segger Ozone debugger (V3.10d and also an older version) then we can take the same exact .hex or .out files and select "Download & Reset".  Then when we select run from the debugger our device is enumerated on the USB bus without any problem.  We do not have to add the additional step of power cycling our board.

This leads me to believe that the problem is due to the way that IAR is resetting or more correctly not resetting the nRF after it downloads and programs the binary into flash.

In the IAR Debugger "Setup" tab we have "Run to main" selected. We tried disabling this option and we still have the same problem.  The "Download" tab has "Use flash loader(s)" selected. 

Looking for some help to resolve this IAR configuration problem because it is impacting our workflow and causing extra delays every time we download new code to the nRF.

Thanks,

Raz

  • +1 in reply to rzd

    Hi Raz,

     

    rzd said:
    Any ideas what could be going on?

    My apologies. The older SDK checked for a specific revision (rev 1) and didn't account for a future revision, which the newer SDKs have in place.

    Here's the implementation in SDK v16, \modules\nrfx\drivers\src\nrfx_usbd_erratas.h, as an example:

    static inline bool nrfx_usbd_errata_type_52840_eng_b_or_later(void)
{
    return (nrfx_usbd_errata_type_52840() && (*(uint32_t const *)0x10000134UL >= 0x1UL));
}

static inline bool nrfx_usbd_errata_187(void)
{
    return (NRFX_USBD_ERRATA_ENABLE && (nrfx_usbd_errata_type_52840_eng_b_or_later()
                                        || nrfx_usbd_errata_type_52833()));
}
     

     

    Kind regards,

    Håkon

  • 0 in reply to Håkon Alseth

    Hi Hakon,

    I downloaded the SDK 16 code after I sent my comments above and I saw the new code.  I was wondering about the reason for the big difference so thank you for clearing this up.  It seems like there were a lot of changes made when going from version 15 to 16 so we will need to carefully evaluate how we migrate to version 16.

    BTW, one thing that is strange is the fact that the old code ran correctly when I used the Segger Ozone.  I wonder what Segger do in their init code that made the SDK 15 code work.  In any case we already modified the code and now everything is stable.

    Thanks again for the great support.

    Raz

  • +1 in reply to rzd

    Hi Hakon,

    How do I mark this problem as resolved and close the issue in your system?

    Thanks,

    Raz

  • +1 in reply to rzd

    Hi Raz,

     

    rzd said:
    BTW, one thing that is strange is the fact that the old code ran correctly when I used the Segger Ozone.  I wonder what Segger do in their init code that made the SDK 15 code work.  In any case we already modified the code and now everything is stable.

    Segger Ozone is a pure elf debugger, so it uses the same exact output as IAR uses, but; it might do different "enter debug mode" procedures, where this issue do not occur. Its hard to say what is different between the two debug methods, but it seems that there are indeed differences.

     

    rzd said:
    How do I mark this problem as resolved and close the issue in your system?

    First off, I am glad to hear that your issue has been resolved! If you find mark one of the answers given here as "verified answer" (More -> Verify answer), it'll be closed in the system. I have recently noticed that you might have to refresh the page (F5) before this is visible, which I've reported back to the web admins.

     

    Kind regards,

    Håkon

Related