• State Verified Answer
  • Replies 1 reply
  • Subscribers 90 subscribers
  • Views 1468 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 283724
Options

Zephyr kernel config debug guidance

astomi

Hello,

I am working on a project which is based on nrf52840 and Zephyr.

Current prototype uses Adafruit nrf52840 sense board with spi based display attached.

I am new to Zephyr, but done a gazillion similar projects using Eclipse based or proprietary IDEs and different RTOSes.

I have custom board and display driver 'in-tree' defined.

My test code example is 'blinky" - meaning - no display driver instantiation - just a dead piece of code (presumably) included into Zephyr kernel image.

All my configurations compile fine using latest Nordic Connect SDK. 

Long story short - if I enable 'CONFIG_DISPLAY=y' in my prj.conf, everything still compiles fine but target is becoming 'dead' = debug with J-link attached doesn't work,  board reset results in timeouts, debug suspend in cpu_idle. When 'CONFIG_DISPLAY=y' is disabled, blinky example runs fine.

So, my question is - hope you can shed some light on it -how to debug kconfig output (kernel configuration) or/and instrumentation options please.

Thanks.

Alex

Parents
  • +1

    And here is the answer.

    In my case it was a hardware issue triggering infinite loop of busy pin state check within controller init routine. My build configuration did not include extra debug info which is required to debug drivers - this is why debug did not work. Also, if breakpoint is not set in advance, debugger on launch just waltz away as far as it can go, as opposed to halting at the beginning.

    What remains unexplained why driver initialisation code gets executed even when a/ corresponding device is set to "disabled" in dts, and b/ no calls to  device_get_binding() are made. It doesn't feel logical but I guess it is what it is.

    To answer my kconfig question - in a situation like this build output does not contain any clues, apart maybe extra device handle that hinted me to check driver itself.

    Cheers,

    Alex

Reply
  • +1

    And here is the answer.

    In my case it was a hardware issue triggering infinite loop of busy pin state check within controller init routine. My build configuration did not include extra debug info which is required to debug drivers - this is why debug did not work. Also, if breakpoint is not set in advance, debugger on launch just waltz away as far as it can go, as opposed to halting at the beginning.

    What remains unexplained why driver initialisation code gets executed even when a/ corresponding device is set to "disabled" in dts, and b/ no calls to  device_get_binding() are made. It doesn't feel logical but I guess it is what it is.

    To answer my kconfig question - in a situation like this build output does not contain any clues, apart maybe extra device handle that hinted me to check driver itself.

    Cheers,

    Alex

Children
No Data
Related
Terms of service