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.
Yes, we route the nRESET pin to the SWD connector. Yesterday our oscilloscope was busy but today I'm going to check if the nRESET pin is toggled or not toggled by the two different debuggers. Yesterday I already tried different Reset options in the J-Link Setup tab but today I will do a more thorough test with the oscilloscope on the nRESET line.
We are not loading Softdevice but we still have the extra option you show below. Should we remove this option when Softdevice is not loaded?
Some additional information. I checked the nRESET line behavior with an oscilloscope. Both Segger Ozone and IAR do not toggle the nRESET and yet when using Ozone everything works just fine. I configured IAR to toggle the nRESET line and it still did not solve the problem. I tried disabling the "Extra Option" in IAR and it did not make any difference.
This screen shot shows the location where the error occurs:
I don't know if you can see the above so hopefully this one is more clear:
Below are screen captures of the nRF52840 registers as they are initialized by Ozone and below that by IAR immediately after downloading the binary into the nRF. The big difference is in the cycle count. I don't know what Ozone is doing differently than IAR on startup but it is executing a lot more code. And again, just to be clear I use the exact same .out file with Ozone and with IAR. I build the code only in IAR Workbench.
Based on some comments that I saw on the IAR website I also tried to disable the "Use flash loader(s)" option but that did not help.
Any recommendations how I should attempt to debug this? Do you have an IAR project with USB that I can try to run on my board? I would need the project file which I think includes all the settings for Workbench.
BTW, I also tried to use an IAR I-jet adapter instead of a J-Link and I get the exact same problem with the IAR Workbench. I cannot run Segger Ozone on the I-jet to compare but I think it is quite clear now that the problem is due to something in the IAR configuration.