Build and Run with SEGGER Embedded Studio (SES) v6.20a on nRF5 SDK 17.1.0 and S140 7.2.0 on nRF52840

RE: Build and Run with SEGGER Embedded Studio (SES) v6.20a on nRF5 SDK 17.1.0 and S140 7.2.0 on nRF52840

Edvin — Wed, 30 Mar 2022 09:24:55 GMT

Hello Casper,

As long as you don't have any sensitive information in this ticket, it is perfectly fine to open it to public. As you say, it may help someone with similar problems.

I don't have the possibility to open private tickets to public (only the other way), so you would need to do that.

Best regards,

Edvin

RE: Build and Run with SEGGER Embedded Studio (SES) v6.20a on nRF5 SDK 17.1.0 and S140 7.2.0 on nRF52840

Casper Kronborg Pedersen — Tue, 29 Mar 2022 13:42:38 GMT

Hi Edvin,

Thank you for getting back to me so quickly.
Ok, as long as the issue is just caused by SES not resetting the chip properly then there should be nothing to worry about for the final product as you say.

Thank you for the .bat file.

Would it make sense to make this thread public again in case anyone else is having similar experiences?

Br. Casper

RE: Build and Run with SEGGER Embedded Studio (SES) v6.20a on nRF5 SDK 17.1.0 and S140 7.2.0 on nRF52840

Edvin — Tue, 29 Mar 2022 13:30:07 GMT

Hello Casper,

After discussing this with a colleague, we concluded that the issue is not related to the nRF, the SoftDevice or the SDK. It looks like a bug in the Segger Embedded Studio's debugging firmware. The build and run doesn't reset the nRF properly, but it is trying to do some "hack" by only resetting the vector table and start the execution again, without actually resetting the chip. The reason this is only triggering now (after your port), and not in the old SDK, and as far as I know (but I may be wrong), not in the other non-freertos examples has to do with timing differences in how the threads are started.

I agree that it is a bug, and an inconvenience, but I don't think Nordic will reach out to Segger and ask for a patch. It should not cause any issues during production, or for the final product.

As you say, the issue is not present "the first time you press build and run", and the reason for this is that this time, SES will actually program the chip, and then reset it properly after. The second time you press build and run, it will just read the flash to see that it is already programmed, and then it will do the buggy reset thing.

For your convenience, you can add this .bat file to your usbd_ble_uart_freertos folder, and run it whenever you want to flash your new FW.

devzone.nordicsemi.com/.../flash.bat

(change it if you want to flash the debug build instead.

You can then run it from a command line in that folder.

Best regards,

Edvin

RE: Build and Run with SEGGER Embedded Studio (SES) v6.20a on nRF5 SDK 17.1.0 and S140 7.2.0 on nRF52840

Casper Kronborg Pedersen — Tue, 29 Mar 2022 07:50:20 GMT

Ok.

Yes, we have only experienced this after using "Build and Run."

Maybe it is an important detail that rolling back SES to v4.16 removes issue.

[quote user="Casper Kronborg Pedersen"]We then tried rolling back SES all the way to 4.16. This makes the files I sent you work, as well as our two projects that are being ported. [/quote]

Br. Casper

RE: Build and Run with SEGGER Embedded Studio (SES) v6.20a on nRF5 SDK 17.1.0 and S140 7.2.0 on nRF52840

Edvin — Mon, 28 Mar 2022 17:23:23 GMT

That would be through me.

I can ask them, but please be aware that they are currently working on the Softdevice Controller, which is the BLE stack for the nRF Connect SDK, so it may take some more time than usual to get an answer.

Just to clarify, you have not seen this using any other method than the "build and run" with Segger Embedded Studio, right?

BR,

Edvin

RE: Build and Run with SEGGER Embedded Studio (SES) v6.20a on nRF5 SDK 17.1.0 and S140 7.2.0 on nRF52840

Casper Kronborg Pedersen — Mon, 28 Mar 2022 08:26:52 GMT

Hi Edvin,

Sorry for getting back to you so late.

I would like to ask your SoftDevice team what they think about this, and if they think it could potentially be a symptom of some larger problem, or if we should not worry about it?

Do you know where I can can get in contact with the SoftDevice team?

Br. Casper

RE: Build and Run with SEGGER Embedded Studio (SES) v6.20a on nRF5 SDK 17.1.0 and S140 7.2.0 on nRF52840

Edvin — Thu, 24 Mar 2022 14:18:47 GMT

Hello Casper,

I am terribly sorry. For some reason, I have missed the "build and run". Looking at this ticket now, that is actually quite embarrassing. I guess I just read it as "build and run", as in build it, and flash it, and one way to do so is to press "F5", which I usually do.

I see that in SDK 17.1.0, this seems to happen with the ble_app_hrs_freertos example as well.

However, I can only see it using the "build and run" button from SES. Not when compiling with SES, and then flashing using e.g. nrfjprog. I am not completely sure what's happening, but I suspect it has to do with the clock. I see that if I comment out your "nrf_drv_clock_init()", then it hardfaults once, and then starts running normally. I suggest that you keep the nrf_drv_clock_init(), but use something other than SES to flash your application, or use the run and debug.

Seeing as this only is triggered in SES, I am not sure it will be a huge issue. If you mean otherwise, I can contact our softdevice team and try to figure out why the softdevice is not starting, but I suspect there is just some timing issue between the program and the reset being issued by SES.

Best regards,

Edvin

RE: Build and Run with SEGGER Embedded Studio (SES) v6.20a on nRF5 SDK 17.1.0 and S140 7.2.0 on nRF52840

Casper Kronborg Pedersen — Mon, 21 Mar 2022 13:36:22 GMT

devzone.nordicsemi.com/.../nRF5_5F00_SDK_5F00_17.1.0_5F00_ddde560_5F00_ckp.zip

RE: Build and Run with SEGGER Embedded Studio (SES) v6.20a on nRF5 SDK 17.1.0 and S140 7.2.0 on nRF52840

Casper Kronborg Pedersen — Mon, 21 Mar 2022 13:18:13 GMT

Hi Edvin,

[quote user="Edvin Holmseth"]from your log it seems that it returns 08 from the initial run, unless the line "app: USBD BLE UART example started is not the first thing that is printed when you run your application (If there are more logs above that).[/quote]

I made sure to show you all of the LOG output.

[quote user="Edvin Holmseth"]What Hardware are you using? nRF52840 DK?[/quote]

Yes, I have used two separate nRF52840-DK's to ensure that it is not a faulty board.

[quote user="Edvin Holmseth"]did you actually try to download the file that you uploaded here?[/quote]

Yes, fresh download and extract of both SDK and the files I sent you.

[quote user="Edvin Holmseth"]Have you tried to run it on another DK (another nRF52840 DK), and/or another computer? [/quote]

I have had two colleagues run it on their PC's with the same results using both the files I sent you and our own two projects that uses the SDK and s140. They downloaded fresh SDK 17.1.0 and the files I sent you were shared locally but as zipped.

[quote user="Edvin Holmseth"]Seeing as you are trying to port a project/application, please make sure that you do not copy any files outside the folder that you sent me from the old SDK. [/quote]

That is taken into account. We have two separate projects that are being ported and we are two who checked the .emProject files to make sure that the inclusion of files is strictly 17.1.0 and that we are using fresh unzips.

[quote user="Edvin Holmseth"]You can also try to delete and reinstall SES (there are some files that are not part of the SDK as well, that you may have changed). [/quote]

Something that might be causing the problem: We then tried rolling back SES all the way to 4.16. This makes the files I sent you work, as well as our two projects that are being ported. Hoorah!

As soon as we upgrade SES back to 5.64 or 6.20a, the error reappears... Even after fresh unzips of files and SES installs. This has been reproduced on two separate computers.

However, sticking with a very old version of SES could be painful and does not seem like the solution..

From the images you send me it seems like you are always in debug view using the "Build and Debug" option with SES. Here the error will not appear.

Have you tried actually using "Build and Run" and doing so multiple times in a row?

A detail I did not mention was that the initial "Build and Run" always runs without issue.

Br. Casper

Btw: I will upload my entire SDK with the examples removed if they are too big to upload.

EDIT: Additional info, just using the RESET button on the DK also makes the code run without issue.

RE: Build and Run with SEGGER Embedded Studio (SES) v6.20a on nRF5 SDK 17.1.0 and S140 7.2.0 on nRF52840

Edvin — Mon, 21 Mar 2022 09:09:10 GMT

Hello,

I added the line "nrf_sdh.c line 214, err code %02x", err code" outside the if, since it didn't trigger otherwise:

from your log it seems that it returns 08 from the initial run, unless the line "app: USBD BLE UART example started is not the first thing that is printed when you run your application (If there are more logs above that).

Let us take two steps back. What Hardware are you using? nRF52840 DK? did you actually try to download the file that you uploaded here? (don't copy it from your already existing project folder, but download it and unzip it) and copy it into an unmodified SDK v17.1.0. Do you still see the same? If so, I find it very strange that we see different behavior if we are running the same FW on the same HW and get two different outcomes. Have you tried to run it on another DK (another nRF52840 DK), and/or another computer?

Seeing as you are trying to port a project/application, please make sure that you do not copy any files outside the folder that you sent me from the old SDK.

If you try to unzip the file that you uploaded here into another unmodified SDK, and it still works. Please try to think if there are any details that you didn't mention that you did, other than compiling and running the sample in SES. Even if you think it is not of importance, it may make a difference, such as copying some old files from the old SDK because you thought they were needed.

You can also try to delete and reinstall SES (there are some files that are not part of the SDK as well, that you may have changed).

If that doesn't lead anywhere, perhaps you can try to zip your entire SDK and upload it here. You may need to delete the rest of the examples if the file is too big to upload on DevZone.

BR,
Edvin

RE: Build and Run with SEGGER Embedded Studio (SES) v6.20a on nRF5 SDK 17.1.0 and S140 7.2.0 on nRF52840

Casper Kronborg Pedersen — Fri, 18 Mar 2022 10:58:19 GMT

About the additional load file, I did check that as well:

Br. Casper

RE: Build and Run with SEGGER Embedded Studio (SES) v6.20a on nRF5 SDK 17.1.0 and S140 7.2.0 on nRF52840

Casper Kronborg Pedersen — Fri, 18 Mar 2022 10:52:56 GMT

To get the nrf_sdh_ble_default_cfg_set() function to output any NRF Logs from within I had to enable NRF_SDH_BLE_LOG_ENABLED in sdk_config.h. I also set the Log Level to 4 to get all outputs. As you will see, this provided additional information.

"Build and Debug" - With Extra NRF LOGS:

"Build and Run" - With Extra NRF LOGS:

Sorry for the many large images and me continuously posting, but I hope this helps clearing things up.

Br. Casper

RE: Build and Run with SEGGER Embedded Studio (SES) v6.20a on nRF5 SDK 17.1.0 and S140 7.2.0 on nRF52840

Casper Kronborg Pedersen — Fri, 18 Mar 2022 10:45:56 GMT

[quote user="Edvin Holmseth"]Is the issue still that sd_ble_cfg_set() returns NRF_ERROR_INVALID_STATE?[/quote]

No, it is nrf_sdh_enable_request(), specifically in the nrf_sdh.c file in line 214. Here is a screenshot of an additional log line I just added:

[quote user="Edvin Holmseth"]Are you sure you don't call ble_stack_init() twice in your project? Or that you call nrf_sdh_ble_default_cfg_set() from several places?[/quote]

[quote user="Edvin Holmseth"] Check from your log by adding some logging inside that call to see whether it is called one or two times. [/quote]

I just checked the project to see the amount of times each function is found.
I will add in the log output reply below where I have added the extra log messages inside those function calls.

RE: Build and Run with SEGGER Embedded Studio (SES) v6.20a on nRF5 SDK 17.1.0 and S140 7.2.0 on nRF52840

Casper Kronborg Pedersen — Fri, 18 Mar 2022 10:16:04 GMT

Hi Edvin,

[quote user="Edvin Holmseth"]FYI, Segger will flash the softdevice for you, as long as it is specified in project settings -> Loader -> Additional_load_file[0].[/quote]

I was aware that SES was flashing the SoftDevice since the Output log tells me so, but thank you for telling me :) I only used the nRF Connect For Desktop to avoid using SES for flashing as a test.

I just want to quickly show what I am getting when using "Build and Debug":

"Build and Run":

I am using a fresh SDK and the file I sent you. I am just quickly posting this to clarify before I recheck the exact point of failure so you can see the behavior I am experiencing.

Br. Casper

EDIT: Additional information. I am using REV 2.0.0, 2020.2 of the nRF52840-DK.

RE: Build and Run with SEGGER Embedded Studio (SES) v6.20a on nRF5 SDK 17.1.0 and S140 7.2.0 on nRF52840

Edvin — Fri, 18 Mar 2022 09:53:49 GMT

FYI, Segger will flash the softdevice for you, as long as it is specified in project settings -> Loader -> Additional_load_file[0].

I get this when I added one line of printing before entering the task scheduler:

Other than that, I didn't modify the file that you sent at all, except clicking "rebuild solution".

Is the issue still that sd_ble_cfg_set() returns NRF_ERROR_INVALID_STATE? Are you sure you don't call ble_stack_init() twice in your project? Or that you call nrf_sdh_ble_default_cfg_set() from several places? Check from your log by adding some logging inside that call to see whether it is called one or two times. And check that sd_ble_default_cfg_set() is not called after sd_ble_enable() is called. And also check that the correct softdevice is located in the folder that the loader is fetching the softdevice from. It doesn't matter what softdevice you manually program before you press "build and debug" because Segger Embedded Studio will still program the file found in "Additional_load_file[0]".

BR,

Edvin

RE: Build and Run with SEGGER Embedded Studio (SES) v6.20a on nRF5 SDK 17.1.0 and S140 7.2.0 on nRF52840

Casper Kronborg Pedersen — Fri, 18 Mar 2022 07:27:30 GMT

Hi Edvin,

Were you able to reproduce the scenario after trying what I wrote earlier?

[quote user="Casper Kronborg Pedersen"]

Did you try and flash the S140 7.2.0 .hex file and the .hex file that is built with the files I sent you and then:

Flash both SDK and example project hex files with nRF Connect for Desktop Programmer
Then open the .emProject file with SES 5.64 and selecting the "Build and Run" option while checking the log output?

[/quote]

Br. Casper

RE: Build and Run with SEGGER Embedded Studio (SES) v6.20a on nRF5 SDK 17.1.0 and S140 7.2.0 on nRF52840

Casper Kronborg Pedersen — Wed, 16 Mar 2022 07:57:47 GMT

Yes, I did download and unzip a clean SDK 17.1.0, and unzipped the file I sent you to the very same location.
Then I got the output I wrote before in green.

Did you try and flash the S140 7.2.0 .hex file and the .hex file that is built with the files I sent you and then:

Flash both SDK and example project hex files with nRF Connect for Desktop Programmer
Then open the .emProject file with SES 5.64 and selecting the "Build and Run" option while checking the log output?

Br. Casper

RE: Build and Run with SEGGER Embedded Studio (SES) v6.20a on nRF5 SDK 17.1.0 and S140 7.2.0 on nRF52840

Edvin — Tue, 15 Mar 2022 14:36:42 GMT

You can download the unmodified SDK here:
https://www.nordicsemi.com/Products/Development-software/nRF5-SDK

RE: Build and Run with SEGGER Embedded Studio (SES) v6.20a on nRF5 SDK 17.1.0 and S140 7.2.0 on nRF52840

Edvin — Tue, 15 Mar 2022 14:35:57 GMT

Did you try to use SES with a clean install of the SDK? Download and unzip the SDK, and unzip the file that you sent me into the very same location that you described in the unmodified SDK.

RE: Build and Run with SEGGER Embedded Studio (SES) v6.20a on nRF5 SDK 17.1.0 and S140 7.2.0 on nRF52840

Casper Kronborg Pedersen — Tue, 15 Mar 2022 08:49:22 GMT

Hi Edvin,

I just installed SES v5.64

I then erased the flash on the nRF52840-DK, and used nRF Connect for Desktop Programmer to write S140 v7.20 and the usbd_ble_uart_freertos example.

The issue still persists for me though when using "Build and Run" with SES v5.64.

I can still make the code run by using "Build and Debug" with SES v5.64 or by using "nRF Connect for Desktop Programmer" to flash the nRF52840-DK as before.

Br. Casper

RE: Build and Run with SEGGER Embedded Studio (SES) v6.20a on nRF5 SDK 17.1.0 and S140 7.2.0 on nRF52840

Casper Kronborg Pedersen — Tue, 15 Mar 2022 08:34:28 GMT

Hi Edvin,

I just unzipped a fresh SDK 17.1.0, deleted the existing usbd_ble_uart_freertos example and unzipped the file I sent you. Then I selected Build and Run after making sure the nRF52840-DK already holds the S140 v7.2.0 with nRF Connect.

This is the output I get:

<info> app: USBD BLE UART example started.

<debug> nrf_sdh: State request: 0x00000000

<debug> nrf_sdh: State change: 0x00000000

<info> app: SDH Enable: 8

<info> app: SDH Config: 0, Ram Start: 20002AE8

<info> app: BLE Enable: 8

<debug> nrf_sdh_freertos: Creating a SoftDevice task.

<debug> nrf_sdh_freertos: Enter softdevice_task.

However, I am noticing that you are using SES v5.64, and I am using SES v6.20a. I will try and investigate if a rollback of my IDE could solve the issue.

Br. Casper

EDIT: Did not answer your question

[quote user="Edvin Holmseth"]

In my case, line 214 in nrf_sdh.c is:

Fullscreen

ret_code = sd_softdevice_enable(&clock_lf_cfg, app_error_fault_handler);

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

ret_code = sd_softdevice_enable(&clock_lf_cfg, app_error_fault_handler);

Is that the case for you as well?

[/quote]

Yes this is the same line for me.

RE: Build and Run with SEGGER Embedded Studio (SES) v6.20a on nRF5 SDK 17.1.0 and S140 7.2.0 on nRF52840

Edvin — Tue, 15 Mar 2022 08:10:28 GMT

In my case, line 214 in nrf_sdh.c is:

ret_code = sd_softdevice_enable(&clock_lf_cfg, app_error_fault_handler);

Is that the case for you as well?

Also, in my case, this returns NRF_SUCCESS when I compiled and ran your project. If you get something else, perhaps you can try to unzip the file that you just sent me into an unmodified SDK17.1.0, in case you changed something without being aware of it. See if it still returns NRF_ERROR_INVALID_STATE.

Note:

It didn't compile right away, with some weird compiler error. When I used "Rebuild solution" it compiled without errors.

Best regards,

Edvin

RE: Build and Run with SEGGER Embedded Studio (SES) v6.20a on nRF5 SDK 17.1.0 and S140 7.2.0 on nRF52840

Casper Kronborg Pedersen — Mon, 14 Mar 2022 11:33:29 GMT

Hi Edvin,

Migration Guides:

I did look at migration guides from 15.3.0 to 16.0.0 and then from 16.0.0 to 17.0.2 of the SDK.

RAM and FLASH:

I have used the RAM and flash placements from the usbd_ble_uart_freertos example and that allowed the project to build after migration. However, I did not know that the RAM settings were dependent on the specific use case of S140.

Error in my statement in the "Update" post:

I thought that I had gotten an example from the SDK working without any issues, however I must have been tired as I simply did not get the LOG output with the errors... So I never had a working example project from the SDK.

Sharing an example to run on a nRF52840-DK that reproduces the error:

I have used the usbd_ble_uart_freertos example from SDK 17.1.0, and enabled all NRF logging for the SoftDevice, as well as added my own outputs to the ble_stack_init() function and added that to a .zip library.

To get it to run, you should be able to go to:

<SDK Location on your PC>\nRF5_SDK_17.1.0_ddde560\examples\peripheral\

And unpack the .zip file. I built the version for pca10056, SES and S140 located here:

<SDK Location on your PC>\nRF5_SDK_17.1.0_ddde560\examples\peripheral\usbd_ble_uart_freertos\pca10056\s140\ses

As I wrote in the original post, the error only shows when using the "Build and Run" option in SEGGER Embedded Studio.

From what I can see, it is Line 214 in nrf_sdh.c that returns NRF_ERROR_INVALID_STATE.

Hope this is something you can work with.

Br. Casper

devzone.nordicsemi.com/.../usbd_5F00_ble_5F00_uart_5F00_freertos.zip

EDIT:
To make it build I assume you also need to change a line in retarget.c like I had to.
retarget.c line 100 changed to:
#if defined(__SES_VERSION) && (__SES_VERSION >= 34000) && !defined(__SEGGER_RTL_VERSION)

RE: Build and Run with SEGGER Embedded Studio (SES) v6.20a on nRF5 SDK 17.1.0 and S140 7.2.0 on nRF52840

Edvin — Fri, 11 Mar 2022 14:24:47 GMT

[quote user="Casper Kronborg Pedersen"]Could this mean that the difference might lie in defines in the sdk_config.h header file?[/quote]

It could be, but my main suspicion, and why I asked about the NRF_LOG_WARNING lines is that when you change the softdevice, it will typically require some other memory settings than what it did in the old SDK. I will change this ticket to private now.

[quote user="Casper Kronborg Pedersen"]

Are any changes needed to that file to make things work as intended when updating the SDK version?

[/quote]

You should see the migration guide for the SDK versions between 15.3.0 and 17.1.0.

If you took the project file from the old SDK, then you need to make sure that you upload the new SoftDevice from the new SDK, and you probably need to change flash start address, flash size, ram start address and ram size to match your new SoftDevice.

For Flash, just see what flash start address and size the other examples in the SDK that uses the same softdevice uses, while for RAM, you need to monitor the log, or debug and set breakpoints at those points to see if it wants you to change the RAM settings. The reason I can't just tell you what to set is that it depends on the application you are running, the number of services and characteristics, the connection parameters that you intend to use, the MTU size, the number of supported simultaneous connections and so on.

Best regards,

Edvin

RE: Build and Run with SEGGER Embedded Studio (SES) v6.20a on nRF5 SDK 17.1.0 and S140 7.2.0 on nRF52840

Casper Kronborg Pedersen — Fri, 11 Mar 2022 13:36:05 GMT

Update:

I found this thread which enabled me to build the usbd_ble_uart_freertos_pca10056_s140 SDK example from SDK 17.1.0 by changing line 100 in retarget.c.

Then I tried the following on an nRF52840-DK:

I removed all features from the SDK example that are not used in our own project and then I was able to start s140 without doing power cycles, using the debugger or any of the other methods.
Then I removed all features and initialization in the main() function except nrf_log and s140 from our own project and used the exact same sequence of function calls as in the SDK example. But the problem still exists.

Could this mean that the difference might lie in defines in the sdk_config.h header file?

I am running with the same sdk_config.h as before the change from SDK 15.3.0 to 17.1.0.

Are any changes needed to that file to make things work as intended when updating the SDK version?

I am currently investigating the differences between the files.

Br. Casper