pm_init failed because pds_init() returned NRF_ERROR_STORAGE_FULL

RE: pm_init failed because pds_init() returned NRF_ERROR_STORAGE_FULL

Hieu — Mon, 21 Nov 2022 12:00:40 GMT

That's great. Shall we consider this case closed then? 🙂

If you can just verify your latest comment or any of our comments that suggest erasing the flash, that would be great.

RE: pm_init failed because pds_init() returned NRF_ERROR_STORAGE_FULL

brianreinhold — Mon, 21 Nov 2022 11:16:03 GMT

Well, erasing the memory using nRFConnect for Desktop first solved the issue. The BP service example now runs as it should.

RE: pm_init failed because pds_init() returned NRF_ERROR_STORAGE_FULL

Hieu — Mon, 21 Nov 2022 10:10:45 GMT

Erase all will erase your MBR, but your DK won't become useless.

For applications using SoftDevice like yours, the SoftDevice hex files come with the MBR.
For baremetal no-connectivity applications, the device doesn't need the MBR to work. Our examples for such cases include both no-MBR (blank) and MBR options.

When I have an application that reads from flash, if it is malfunctioning, the first thing I try is erasing flash.
That is unless I want to get to the bottom of the issue. Although if erasing flash fix it, it means the junks on flash memory is what break things.
Of course, that is also unless if I want to do specific tests that require data on the flash memory.

RE: pm_init failed because pds_init() returned NRF_ERROR_STORAGE_FULL

brianreinhold — Fri, 18 Nov 2022 16:08:16 GMT

I am looking at the memory map displayed by the programmer in nFRConnect for Desktop. I see three small bands high up in flash. The two highest start at 0xFD0000 and 0xFF0000 and a free band at 0xFE0000.

I think that middle zone is the one free page.

When I install my app (that works) those two bands are still there but I write at a lower address and that space is free. I have very simple flash requirements - I read and write pairing keys and stored measurement data at app start and app shutdown. So their is no conflict with BTLE. Removes a few layers as well since everything ends up calling SoftDevice.

If I select 'erase all' what will happen to the MBR? I don't want to make my DK useless.

RE: pm_init failed because pds_init() returned NRF_ERROR_STORAGE_FULL

Hieu — Fri, 18 Nov 2022 15:33:31 GMT

[quote user="brianreinhold"]First, do we have the same version of Segger?[/quote]

Seems like we do

[quote user="brianreinhold"]in the file fds.c only finds one page (of the three possible) that it can use, The other two pages are noted as 'The page contains non-FDS data, do not use". The method will return a failure if less than 2 pages are found. I dont know why it does this and what it means or if it has something to do with the start address of 0xfd0000.[/quote]

This finding matches what I have been guessing might causes what you observed. I can think of two probabilities:

1. There are some existing data in the region FDS is trying to control that causes FDS to malfunction.

2. Your nR52840 chip has gone bad in some way.

As #2 is quite unlikely, I have been asking you about erasing flash, which should solve #1.

Could you install nrfjprog and give it a try? If you don't like using command line, you can also use the Programmer "sub-"app in nRF Connect for Desktop.

[quote user="brianreinhold"]My application still works but it writes to flash directly and does not use fds[/quote]

There are some benefits to using FDS. However, if you are confident and comfortable with your own approach, and if it is working, that is fine.

RE: pm_init failed because pds_init() returned NRF_ERROR_STORAGE_FULL

brianreinhold — Fri, 18 Nov 2022 12:13:15 GMT

I have not installed the command line tools.

First, do we have the same version of Segger?

SEGGER Embedded Studio for ARM
Release 6.40 Build 2022102501.51567
Windows x64

© 2014-2022 SEGGER Microcontroller GmbH
© 1997-2022 Rowley Associates Ltd.

segger-as: version 2.11
segger-cc: version 15.0.0
segger-ld: version 4.36.0
segger-rtl: version 4.20.0

GCC/BINUTILS: built using the GNU ARM Embedded Toolchain version 11.3.Rel1 source distribution

Clang/LLVM: built using the version 15.0.0 source distribution

Since I dont have the infrastructure installed yet to do the command line work I decided to run through the debugger and see if I could come up with anything. The problem arises because the method

static fds_init_opts_t pages_init(void)

in the file fds.c only finds one page (of the three possible) that it can use, The other two pages are noted as 'The page contains non-FDS data, do not use". The method will return a failure if less than 2 pages are found. I dont know why it does this and what it means or if it has something to do with the start address of 0xfd0000.

My application still works but it writes to flash directly and does not use fds

RE: pm_init failed because pds_init() returned NRF_ERROR_STORAGE_FULL

Hieu — Thu, 17 Nov 2022 22:25:25 GMT

[quote user="vthieu"]I do remember accidentally flashing my application leave my bootloader intact during one of my earlier DFU tests though, which suggest the entire flash is not erased. I will double check that by my next reply.[/quote]

I just double check this, and it does look like the application downloading via Segger Embedded Studio will only erases the flash region that the application and the SoftDevice would take.

You can check this by flashing a bootloader example on to the kit, then flash a normal BLE application. Readback of the flash memory should show that the bootloader is still there, even though we don't expect it to.

RE: pm_init failed because pds_init() returned NRF_ERROR_STORAGE_FULL

Hieu — Thu, 17 Nov 2022 20:50:54 GMT

[quote user="brianreinhold"]when I looked in the file I noted that there was no size entry in that statement. Interesting. It must have been added in the SDK update.[/quote]

Yes, it is mentioned in the Release Note of nRF5 SDK v17.1.0.

Observation of unaligned memory layout:
Certain SES projects that use section variables have been observed
to create memory sections that do not end on a word-aligned address.
This has caused issues when the hex file has been processed by a hex file utility tool
like mergehex.exe, which can produce a corrupted hex file.
The issue has been fixed in the SES section-placement file (flash_placement.xml)
by setting the memory section size attribute to 4.

[quote user="brianreinhold"]IN any case, I built and ran the BPS example and got the same error as I did with the latest SDK. Since this has always worked with the previous versions of SES I have had, it must be something that SES has done when it came out with its update.[/quote]

This bugs me a lot. Could you please flash these following hex files? I built them with SES v6.40, v6.34, v5.42a, and tested them on my nRF52840 DK. They should work.

devzone.nordicsemi.com/.../3060.ble_5F00_app_5F00_bps_5F00_pca10056_5F00_s140_5F00_ses_5F00_5_5F00_42a.hex
devzone.nordicsemi.com/.../0825.ble_5F00_app_5F00_bps_5F00_pca10056_5F00_s140_5F00_ses_5F00_6_5F00_40.hex
devzone.nordicsemi.com/.../3377.ble_5F00_app_5F00_bps_5F00_pca10056_5F00_s140_5F00_ses_5F00_6_5F00_36.hex
devzone.nordicsemi.com/.../1234.ble_5F00_app_5F00_bps_5F00_pca10056_5F00_s140_5F00_ses_5F00_5_5F00_42a_5F00_release.hex

If any of those don't work, please readback your flash memory for any of these and send the result me.

Here is a reference flash command with nrfjprog. The --chiperase option is important to make sure the entire flash is in a known state

nrfjprog.exe -f nrf52 --program .\ble_app_bps_pca10056_s140_ses_5_42a.hex --verify --chiperase --log

RE: pm_init failed because pds_init() returned NRF_ERROR_STORAGE_FULL

brianreinhold — Thu, 17 Nov 2022 11:04:49 GMT

I tried using the SDK I have been using for the entire development of this standard which is nRF5_SDK_17.0.2_d674dde with the new SES. I have been using that SDK along with the nRF51 (nrf_SDK_12.3.0 using Keil) for almost two years. I have built and run the BP example along with several of the other health device examples in 17.0.2 using both SES and Keil and have not had a problem (outside of too big of a HEX file for my space limited Keil).

When used with the new SES I get the same error with that printf related c file so I removed the file from the project. I did not get the error with the 'size' entry in the flash placement xml file to my surprise but when I looked in the file I noted that there was no size entry in that statement. Interesting. It must have been added in the SDK update.

IN any case, I built and ran the BPS example and got the same error as I did with the latest SDK. Since this has always worked with the previous versions of SES I have had, it must be something that SES has done when it came out with its update.

RE: pm_init failed because pds_init() returned NRF_ERROR_STORAGE_FULL

Hieu — Tue, 15 Nov 2022 17:21:03 GMT

[quote user="brianreinhold"]I have no intentionally erased flash before installing anything new. I see it gets done when I download the flash but it has typically been automatically done by SES (or Keil).[/quote]

I was hoping that the flash gets erased so that it is clean, preventing any chance that data from previous applications/test interfere with the FDS's work.

You are right that there is an Erase step while flashing with SES. I do remember accidentally flashing my application leave my bootloader intact during one of my earlier DFU tests though, which suggest the entire flash is not erased. I will double check that by my next reply.

On my end, I have tried the ble_app_bps example with the nRF52840 DK and the nRF52 DK, both works. I did not experience the init() issues that you had.

We probably have to try a few boring steps now:

- Can you erase your entire flash with nrfjprog or nRF Connect Desktop and retry?

- Can you download a brand-new copy of nRF5 SDK v17.1.0 and retry?

If none of the above works, it really might just be your hardware having a problem. It should be rare, but it is a real possibility. Do you have a different development hardware to try with?

Finally, it is a real shame you had to call off your answer due to the issue with the BPS example. It is great that you tried to verify your answer before you post it. I just want to let you know that we really value community engagement, so I hope that you would keep it up.

I don't know how to put it. I might sound like the typical support guy trying to butter you up to appease you. But for what it's worth, I do personally genuinely wish for the community to be more active like 5-7 years ago, when I was just a community member.

Not that the company does not share the same wish above. They do. But I hope you get my point.

And to that end, I will do all within my ability to support you.

RE: pm_init failed because pds_init() returned NRF_ERROR_STORAGE_FULL

brianreinhold — Tue, 15 Nov 2022 16:42:06 GMT

The 'size=04' and the SES c file conflict with printf are easy to work around as long as you know about them.

The storage full error message is not. I have no intentionally erased flash before installing anything new. I see it gets done when I download the flash but it has typically been automatically done by SES (or Keil). I only have the free version of Keil so I can test my project with log level 0 but not the SDK BP project. It's too big.

But I do have the latest SDK (downloaded a few months ago) and I did not really notice any issues since my project continued to work. It wasn't until I tried to answer someone else's question who was a newbie with SES and the SDK so I was going to suggest just getting an example to build and run. I was writing down the steps as I tried it myself and ran into these problems. THe first two I explained but the last one made me decide to delete my 'answer' and ask a question in turn.

RE: pm_init failed because pds_init() returned NRF_ERROR_STORAGE_FULL

Hieu — Tue, 15 Nov 2022 15:42:11 GMT

It is good that your project is working well. I still recommend that you use SES v5.42a because that is what nRF5 SDK v17.1.0 was tested with. We cannot guarantee that things will work correctly for newer version of SES.

For examples, we have exactly your current complaint.

The size="0x4" piece were added as a workaround solution to older SES compilation issues. And for SES v5.42, it works. However, in newer versions of SES, that property has a different impact on the compiling, and caused your build issue.

On the other hands, the change that caused the SEGGER_RTT_Syscall_SES.c was entirely from SEGGER, and many who use SES and RTT are impacted, not just nRF5 SDK users.

Both of those are completely out of our control. You can also easily imagine that some update to compiler in the future can break one of the features. So, I understand your disturbed feeling, but I hope you can understand why things are that way now.

Regarding the ble_app_bps example, I tried today on the nRF52840 DK, and had no issue. I don't have SES v6.40 handy, but I tried with both SES v5.42a and SES v6.36.

Are we sure your SDK is as new and not modified in anyway?

Have you erased the flash memory before your test?

RE: pm_init failed because pds_init() returned NRF_ERROR_STORAGE_FULL

brianreinhold — Mon, 14 Nov 2022 21:53:03 GMT

Actually MY project works fine with the new SES (with the SEGGER_RTT_Syscalls_SES.c removed). However my project uses only SoftDevice for all BTLE APIs and flash read/write APIs including pairing.

What I tried to do just for the fun of it is just build the Blood Pressure example project out of the box doing nothing but opening the project in the SDK in SES. I had to take care of SEGGER_RTT_Syscalls_SES.c and also a second issue (mentioned above) before the project would build. But when I installed the build on the DK I got those errors in the pm_init() which was unexpected.

So in the end there is no problem with my project but it was disturbing to me that I could not build and run the example BP project. I did not try any other examples.

RE: pm_init failed because pds_init() returned NRF_ERROR_STORAGE_FULL

Hieu — Mon, 14 Nov 2022 21:42:54 GMT

Greetings brianreinhold,

Could you please share more info about your project? Are you upgrading an old project to v17.1.0?

On my end I just tried the ble_app_bps example on my nRF52 DK. It didn't have any problem. Just to be sure, I will try on a nRF52840 DK when I get hold of one tomorrow.

Regarding the IDE, I am afraid the recommendation is to stay with Segger Embedded Studio v5.42a, which the nRF5 SDK v17.1.0 was tested with. Of course, if you have a strong reason to work with the newest SES, please share.

By the way, what kind of project are you working on? Are you maintaining a project created by an older version of the nRF5 SDK, or are you starting a new project?

Are you aware that the current in-active-development SDK nRF52 and newer nRF chips is a different SDK named nRF Connect SDK?

Best regards,

Hieu