This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Why does the nRF52840 fail to boot into its application after powering on over a USB interface if that USB interface does not connect to a computer?

Subject pretty much explains the problem.  One can just get power from a USB interface, but if I plug our nRF52840 into such an interface, it does not appear to boot into its application.  I see the main LED blinking rapidly.  When I subsequently plug that board into a USB interface on a computer, it starts the application.

These nRF52840 boards should work and boot into their application regardless of whether the USB interface connects to a computer.  The application may be a mobile app, and if so, it should not have to be connected to a PC.  Instead, it should work off a battery pack with a USB port.

Parents
  • Hi,

    I tested a example from the SDK and it worked fine when i plugged the DK to a standard wall charger. Are you running an application that uses the USB peripheral? 

  • By "SDK" I assume you mean a Nordic SDK.  What example did you use?  My application only uses the USB as a serial port.  And I have one application that does NOT use the serial port.

    And without a way to access the board over the USB/Serial port, analyzing problems becomes more difficult, since some external dongle would be required.  They are expensive ($300 to $1000) and for what I am doing, the serial port is much better, as I need to issue commands to verify connectivity to other devices over the 2.4 GHz radio.

  • Robert Lasater said:
    By "SDK" I assume you mean a Nordic SDK.  What example did you use?

    Blinky example.

    Robert Lasater said:
    And I have one application that does NOT use the serial port.

     And it doesn't use the USB peripheral at all and it still doesn't work? Are you using a DK or a custom board?

  • Regret delay in responding; I needed to make some progress with a project.

    I have a few questions.

    First, I downloaded the Nordic SDK, nRF5_SDK_17.0.2_d674dde.  I found a "blinky" app, but do not see any instructions for building it.  I am a bit reluctant to start trying different things out, since one of my nRF52840 no longer boots properly.

    Second, I want to understand why an app might fail to boot if the USB port is only providing power.  Most apps write log entries to the serial port.  These are invaluable for tracing and debugging, and can give insight when something is not working correctly.  If an app writes to the USB serial port, and USB only provides power, will that app fail?

  • Hi,

     

    Robert Lasater said:
    First, I downloaded the Nordic SDK, nRF5_SDK_17.0.2_d674dde.  I found a "blinky" app, but do not see any instructions for building it.  I am a bit reluctant to start trying different things out, since one of my nRF52840 no longer boots properly.

     Depends on what development environment you would want to use. The SDK already have folders for IAR, SES, µVision and GCC. There is already a pre compiled hex that can be flashed to the board. You'll find it in the hex folder. 

    Robert Lasater said:
    Second, I want to understand why an app might fail to boot if the USB port is only providing power.  Most apps write log entries to the serial port.  These are invaluable for tracing and debugging, and can give insight when something is not working correctly.  If an app writes to the USB serial port, and USB only provides power, will that app fail?

    Could be numerous reasons, one is that the USB peripheral is waiting to be enumerated by the computer during initialization. If you don't use the USB interface for communication then it doesn't make sense to use it for debugging. I  would instead suggest that you use an external debugger to debug the application running on the DK. Note that the nRF52DK has an external debugger, so if you have two you could connect the debugger on the second DK to the first for debugging the application. 

    regards

    Jared

  • Jared: I don't see away to reply directly to your reply, or otherwise continue the discussion.  Nevertheless I don't think I was clear enough, and thus need to respond.

    An application for the nRF52840 will likely have code to trace or log at key points.  If any attempt to access the USB interface as a serial port causes the application to reboot if that USB interface does not lead to a CPU, then the application developer has to come up with a build process/ make target that eliminates all logging, and also all printf's. While feasible, that is a bit of a hassle.

    This is why I keep asking about what causes an application on the nRF52840 to fail and reboot.

    >If you don't use the USB interface for communication then it doesn't make sense to use it for debugging.

    Sorry, I don't agree with this.  See above.

    >I  would instead suggest that you use an external debugger to debug the application running on the DK.

    But does that not require a dongle?  They are not inexpensive and they can have a learning curve. Plus, tracing an application can have advantages over a dongle, since with tracing you may have a better chance of seeing problems when the application is interacting with something external, say over its radio.

    >Note that the nRF52DK has an external debugger, so if you have two you could connect the debugger on the second DK to the first for debugging the application.

    Can you please provide more detail here?

    Thanks.

Reply
  • Jared: I don't see away to reply directly to your reply, or otherwise continue the discussion.  Nevertheless I don't think I was clear enough, and thus need to respond.

    An application for the nRF52840 will likely have code to trace or log at key points.  If any attempt to access the USB interface as a serial port causes the application to reboot if that USB interface does not lead to a CPU, then the application developer has to come up with a build process/ make target that eliminates all logging, and also all printf's. While feasible, that is a bit of a hassle.

    This is why I keep asking about what causes an application on the nRF52840 to fail and reboot.

    >If you don't use the USB interface for communication then it doesn't make sense to use it for debugging.

    Sorry, I don't agree with this.  See above.

    >I  would instead suggest that you use an external debugger to debug the application running on the DK.

    But does that not require a dongle?  They are not inexpensive and they can have a learning curve. Plus, tracing an application can have advantages over a dongle, since with tracing you may have a better chance of seeing problems when the application is interacting with something external, say over its radio.

    >Note that the nRF52DK has an external debugger, so if you have two you could connect the debugger on the second DK to the first for debugging the application.

    Can you please provide more detail here?

    Thanks.

Children
  • Robert, 

    So let me rephrase myself. If the USB peripheral is used, meaning that the peripheral itself is used not only for powering the nRF but actually used in the application. Then the application might fault if the initialization  process isn't done correctly. My understanding is that you're not just using the USB for powering the nRF but also using it for logging by using it as a serial port. I therefore suspect that the application is failing when you only connect it to a power source, but try to later write to the serial port in your application. Depending on how a error is handled, the nRF will reset and reboot the application when it hits the error handler. If my understanding of your application is not correct then please share more details regarding your application. 

    An application for the nRF52840 will likely have code to trace or log at key points.  If any attempt to access the USB interface as a serial port causes the application to reboot if that USB interface does not lead to a CPU, then the application developer has to come up with a build process/ make target that eliminates all logging, and also all printf's. While feasible, that is a bit of a hassle.

    Why would you write to the serial port if it's not connected to something on the other side? 

    But does that not require a dongle?  They are not inexpensive and they can have a learning curve. Plus, tracing an application can have advantages over a dongle, since with tracing you may have a better chance of seeing problems when the application is interacting with something external, say over its radio.

    What platform are you using? Is it a DK, Dongle or a Custom board? Either way, if you have a DK then you could the J-link onbard to debug your DUT. See here.

Related