• State Verified Answer
  • Replies 3 replies
  • Subscribers 70 subscribers
  • Views 1141 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 292517
Options

nrf52805 not reaching main function

alecamar

When trying to debug the "hello world" zephyr sample application in VS Code, the system seems to never hit the main function.

Any breakpoints set in "main" are never hit, and if the debugger is stopped, it always displays "cpu_idle.S:158" as the current instruction.

To make sure the system is not constantly restarting, a breakpoint was also placed in the first line of "z_arm_prep_c", and it is, in fact, it is only hit once (when restarting the MCU)

The solution proposed in "">devzone.nordicsemi.com/.../hello_world-debug-problem-on-nrf52840dk" also doesn't help in this case.

V2.0.0 of the nRF Connect SDK is being used along with an unmodified custom board definition created for the NRF52805 SoC

Parents
  • +1

    Found the cause/solution. I am leaving this here in case someone else has the same problem:

    As of right now, any application that uses the zephyr RTOS (i.e. everything using the new SDK) requires the 32KHz clock to be supplied externally by default. The  _nrf_clock_control_lf_on function, which is run on startup, waits until this clock is locked, which will never happen if you don't have it.

    Therefore, just select a different input to the 32KHz clock source ("RC Oscillator" or "Synthesized from HFCLK")

Reply
  • +1

    Found the cause/solution. I am leaving this here in case someone else has the same problem:

    As of right now, any application that uses the zephyr RTOS (i.e. everything using the new SDK) requires the 32KHz clock to be supplied externally by default. The  _nrf_clock_control_lf_on function, which is run on startup, waits until this clock is locked, which will never happen if you don't have it.

    Therefore, just select a different input to the 32KHz clock source ("RC Oscillator" or "Synthesized from HFCLK")

Children
Related