• State Verified Answer
  • Locked Locked
  • Replies 5 replies
  • Subscribers 91 subscribers
  • Views 1971 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 285159
Options
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Zephyr NVS Sample Not Functioning Properly

jake11212

I am attempting to build and run the Zephyr NVS sample (https://docs.zephyrproject.org/latest/samples/subsys/nvs/README.html) on the 52840 using the nRF connect extension for VS code.  The build I selected in VS code was nrf52840dk_nrf52840 as this is the closest option but I am using a custom board with a 52840 not the development kit so I wasn't sure if this was an issue.  The build works and flashes correctly but I just get an infinite loop of:

00> [00:00:00.256,225] <dbg> fs_nvs.nvs_recover_last_ate: Recovering last ate from sector 0
00> [00:00:00.262,695] <inf> fs_nvs: 3 Sectors of 4096 bytes
00> [00:00:00.262,725] <inf> fs_nvs: alloc wra: 0, f78
00> [00:00:00.262,725] <inf> fs_nvs: data wra: 0, c4
00> [00:00:00.256,225] <dbg> fs_nvs.nvs_recover_last_ate: Recovering last ate from sector 0
00> [00:00:00.262,695] <inf> fs_nvs: 3 Sectors of 4096 bytes
00> [00:00:00.262,695] <inf> fs_nvs: alloc wra: 0, f70
00> [00:00:00.262,695] <inf> fs_nvs: data wra: 0, c8
00> [00:00:00.256,256] <dbg> fs_nvs.nvs_recover_last_ate: Recovering last ate from sector 0
00> [00:00:00.262,725] <inf> fs_nvs: 3 Sectors of 4096 bytes
00> [00:00:00.262,725] <inf> fs_nvs: alloc wra: 0, f60
00> [00:00:00.262,725] <inf> fs_nvs: data wra: 0, cc
00> [00:00:00.256,286] <dbg> fs_nvs.nvs_recover_last_ate: Recovering last ate from sector 0
00> [00:00:00.262,756] <inf> fs_nvs: 3 Sectors of 4096 bytes
00> [00:00:00.262,756] <inf> fs_nvs: alloc wra: 0, f58
00> [00:00:00.262,756] <inf> fs_nvs: data wra: 0, d0

....

This doesn't seem to be an error, but the code just gets stuck here and never initializes as the example does. I was able to step through the code using ozone and it seems to follow a correct initialization, but it does not output any of the printk statements for some reason so I'm not sure about the status at different points.

Is there a reason it is getting stuck here, and how can I fix this?

Parents
  • 0

    Hello!

    As I assume your board's layout is not identical to the nRF52840 DK, you will probably have to define your own board and build for that.

    You can read about how to do that here.

    Best regards,

    Einar

  • 0 in reply to Einarh

    I am using an overlay file to remap the pins I need and things are programming successfully so I think the build is working fine.  The sample was originally built for the nrf51dk_nrf51422 board in the sample so I assume that the main change would have to be changing the location of the flash memory in the device tree from the 51dk to the 52840dk, but this seems to be handled when choosing the 52840dk_52840 build so I didn't think I needed to change this.  Are there other changes that need to be made?  

    For example the flash partition is determined by the FLASH_AREA_OFFSET variable at line 40 in main, and this changes based on the devicetree.  Since this is handled by the build configuration I assumed I wouldn't need to make any changes.

Reply
  • 0 in reply to Einarh

    I am using an overlay file to remap the pins I need and things are programming successfully so I think the build is working fine.  The sample was originally built for the nrf51dk_nrf51422 board in the sample so I assume that the main change would have to be changing the location of the flash memory in the device tree from the 51dk to the 52840dk, but this seems to be handled when choosing the 52840dk_52840 build so I didn't think I needed to change this.  Are there other changes that need to be made?  

    For example the flash partition is determined by the FLASH_AREA_OFFSET variable at line 40 in main, and this changes based on the devicetree.  Since this is handled by the build configuration I assumed I wouldn't need to make any changes.

Children
  • +1 in reply to jake11212

    Hi!

    I've now tested the NVS sample on an nRF52840 DK, and everything worked as it should, which points to the problem having to do with porting the sample to your board.

    Looking at the timestamps in your log there though, it looks like your board is in fact rebooting for each iteration like it's supposed to, and the timestamps look very similar to what I'm seeing from my DK.

    Perhaps the sample is working as it's supposed to except for the printk calls?

    You could try to redirect printk to the logging system. Try to add these lines to prj.conf:

    CONFIG_LOG_PRINTK=y
    CONFIG_LOG_PROCESS_THREAD_STACK_SIZE=2048
    CONFIG_LOG_BUFFER_SIZE=32768
    CONFIG_LOG_STRDUP_BUF_COUNT=256
     
    And this to main.c:
    #include <logging/log.h>
    #define LOG_MODULE_NAME app
    LOG_MODULE_REGISTER(LOG_MODULE_NAME);
    Then see if you get more info printed through the log.
     
    Best regards,
    Einar
  • 0 in reply to Einarh

    That was the issue it seems to be working normally now thank you!  Is there anything specifically that may be causing the issue with printk?  I was planning to add NVS functionality to a different project and I fear it will break printk in that project.  Is there any drawback of redirecting to logging in that project as well or is there a different fix for the printk issue?

  • 0 in reply to jake11212

    Good to hear you had progress!

    I don't believe it's NVS functionality that is breaking printk for you, as they work fine alongside each other on my DK.

    Have you tested that you're able to use printk with your custom board at all?

    And I assume you're sending the log messages through uart, or have you set up something else?

    -Einar

Related
Terms of service