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

Question

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

Håkon Alseth · Accepted Answer

Hi Raz, 
 
 It looks like you are using an older version of the SDK, and running into this errata: 
 https://infocenter.nordicsemi.com/topic/errata_nRF52840_Rev2/ERR/nRF52840/Rev2/latest/anomaly_840_187.html?cp=4_0_1_0_1_21 
 
 This errata workaround has been implemented in SDK v15 and newer. 
 Could you try manually implementing this workaround and see if the issue disappears? 
 
 Kind regards, 
 Håkon

Håkon Alseth · Answer

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
rfx\drivers\src
rfx_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

rzd · Answer

Hi Hakon, 
 How do I mark this problem as resolved and close the issue in your system? 
 Thanks, 
 Raz

Håkon Alseth · Answer

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

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

Top Replies

core_v2_widget.Hide()