unexpected sd_app_evt_wait() returning

RE: unexpected sd_app_evt_wait() returning

Susheel Nuguru — Tue, 04 Jun 2019 14:42:08 GMT

If your application does not need any events from softdevice, then clearing the pend register should work just fine

RE: unexpected sd_app_evt_wait() returning

Torsten Robitzki — Tue, 04 Jun 2019 13:30:11 GMT

Hi Susheel,

might be, that I never noticed the increased power consumption.

I simply cleared the pending SWI2 interrupt directly behind the call to `NVIC_ClearPendingIRQ()`. This seems to work. From the source in nrf_sdh.c, it seems that the IRQ handler does nothing but to call a list of dynamically registered handlers that are interested in SD state changes. And as this list is empty in my application, I think this should be ok.

best regards,

Torsten

RE: unexpected sd_app_evt_wait() returning

Susheel Nuguru — Tue, 04 Jun 2019 13:18:27 GMT

Torsten,

This is not a bug in SDK or SD.

The SD has always clearly mentioned that any BLE activity events generated in the softdevice are communicated to the application through SWI2 interrupt. In the earlier projects when you used our softdevice, you must have SWI2 interrupt handler implemented somewhere to call sd_ble_evt_get in a loop to pull the events from the softdevice. It is completely application responsibility to enable SWI2 interrupt and call sd_ble_evt_get in a loop until your application pulled all events. It has always been like this with the softdevice architecture since knew softdevice.

RE: unexpected sd_app_evt_wait() returning

Torsten Robitzki — Tue, 04 Jun 2019 11:29:47 GMT

Hi Susheel,

Thank you for the quick analysis. I'm going to apply the workaround you've mentioned. Would you consider this to be a bug in the SD or in the documentation? Will there be a fix for this?

I'm using SD since version 6 and so far never stumbled over an issue like this.

While analyzing this, I found this SDH module. I don't use it, because it doesn't provide any service, that I could use to fulfill my requirements but uses resources. I didn't even tried it out, because I would have to add an include path with the name "experimental" in it, which seemed to be not right for a project that once should go into production.

Again, thanks for all the great support! Nordic has the best support I've ever experienced and every time I can change the mind of my customers, I try to convince them to use chips from Nordic.

I will let you know if the fix works for me.

Best regards,

Torsten

RE: unexpected sd_app_evt_wait() returning

Susheel Nuguru — Tue, 04 Jun 2019 11:14:09 GMT

Hi Torsten,

I figured out the problem you have. Looking at NVIC ISER and ISPR after connection

I can see that the SWI2 interrupt is not enabled and hence is always in the pending state. The reason is that you have not enabled it since you never initialized SDH module nrf_sdh_enable_request in the SDK. If you do not want to have this module then you need to include the implementation of the SWI2_EGU2_IRQHandler and enable this interrupt using NVIC_EnableIRQ so that all BLE events are passed to the application. Right now the softdevice is trying to tell the application that the connected event has arrived and the application has no way to pull it out since it has not enabled or implemented the SWI2_EGU2_IRQHandler.

Please look into the nrf_sdh module implemenation in the SDK and pull these modules into your project and call softdevices_evt_irq_enable (atleast to enable this IRQ and service them)

RE: unexpected sd_app_evt_wait() returning

Susheel Nuguru — Tue, 04 Jun 2019 10:05:45 GMT

that worked. I am compiling it now and will debug it today

RE: unexpected sd_app_evt_wait() returning

Torsten Robitzki — Tue, 04 Jun 2019 08:34:14 GMT

Hi Susheel,

I'm quite sure because I've deleted the zip file. But I was a little bit surprised, by the speed (and problem-less) of the upload. I've renamed the zip file now.

Upload was, again quite fast. It should not contain a build_52 folder.

RE: unexpected sd_app_evt_wait() returning

Susheel Nuguru — Tue, 04 Jun 2019 08:29:33 GMT

Hi Torsten,

Are you sure that you attached the correct zip? the one you attached now and the previous zip contents are same

RE: unexpected sd_app_evt_wait() returning

Torsten Robitzki — Tue, 04 Jun 2019 08:04:42 GMT

Please find a new zip-file, with a Makefile in the root directory. You have to change the NRF_SDK variable at line 5 of the Makefile, to match the location of your NRF SDK. Once SD and firmware are flashed and a generic GATT client connected to the device (advertises the name Torrox), pin 26 will toggle, once per call to `sd_app_evt_wait()`.

RE: unexpected sd_app_evt_wait() returning

Torsten Robitzki — Tue, 04 Jun 2019 07:18:23 GMT

Ok, no problem. I will provide you simple makefile.

RE: unexpected sd_app_evt_wait() returning

Susheel Nuguru — Tue, 04 Jun 2019 07:14:52 GMT

that doesn't work Torsten, I already tried that makefile. it still seems to use the cmake executables, but changing those hardcoded paths and compiler paths did not help much.

RE: unexpected sd_app_evt_wait() returning

Torsten Robitzki — Tue, 04 Jun 2019 06:41:17 GMT

Hi Susheel,

there is a working directory (build_nrf52) that should contain a Makefile generated by cmake. So, if you have an arm_none_eabi_gcc in your path, just using that Makefile should be sufficient. If that doesn't work for you, I will provide a hand written makefile.

RE: unexpected sd_app_evt_wait() returning

Susheel Nuguru — Tue, 04 Jun 2019 06:34:52 GMT

Hi Torsten,

Sorry for delays. I tried to compile your project with no success. I am not an expert in cmake things but it looks like my working environment is not set correctly for it. Seems like cmake is taking clang as default compiler even after my efforts to set the compiler related ENV variables to point to arm-none-eabi-xxxx binaries.

Is there any other way to compile your project?

RE: unexpected sd_app_evt_wait() returning

Torsten Robitzki — Thu, 30 May 2019 13:06:08 GMT

Hi Simon,

find attached a copy of the checkout branched, that I's stripped down, to a bare minimum. You will find a prebuild binary under ./build_nrf52/source/firmware

To build the binaries from sources, change to the build_nrf52 folder and execute cmake with the cache variable NRF_SDK set to the location of your nrf SDK. For example:

cmake -DNRF_SDK=~/CMSIS/nRF5_SDK_15.2.0_9412b96/ ..

If you have `arm-none-eabi-gcc' and make installed, you should be able to directly flash the example with the make target `firmware.flash`.

Let me know if I left out needed details or if you have any questions regarding the code.

Best regards,

Torsten

RE: unexpected sd_app_evt_wait() returning

Simonr — Thu, 30 May 2019 07:21:54 GMT

Hi Torsten

I set this case to private, so you can upload the .zip file here. Private cases can only be seen by Nordic engineers and will be treated with confidentiality.

Best regards,

Simon

RE: unexpected sd_app_evt_wait() returning

Torsten Robitzki — Wed, 29 May 2019 15:08:26 GMT

Hi Simon,

I've stripped the application down, to a hand full of files. The application now basically just sets up the GATT data base and starts adverting. Again, as soon as a GATT client connects, the pin (pin 26) starts to toggle very frequently.

I've prepaired a zip file containing a cmake project build folder containing the binary. How can I send you the zip file?

best regards,

Torsten

RE: unexpected sd_app_evt_wait() returning

Simonr — Wed, 29 May 2019 13:31:53 GMT

Hi Torsten

As you might have guessed, I have had some assistance from Susheel on this case, and as you proposed. It seems like the next step would be to strip down your project so we can try to reproduce it here on our end. We're guessing that you're entering a critical region at some point in your code and just never exit, as this seems to be the only reason for the SWI2 to be disabled like this.

Best regards,

Simon

RE: unexpected sd_app_evt_wait() returning

Torsten Robitzki — Wed, 29 May 2019 10:16:03 GMT

Hi Susheel,

the code, I use to capture ISER and ISPR is really as shown above. I even moved the setting of the debug-pin behind the capturing to make sure that this doesn't cause any modifications of registers.

So yes, SWI2 is pending, but disabled. The only reason, why this could cause a WFI instruction to not suspend the CPU, would be that the SEVONPEND is set (which is not done by my application and which is neither set before calling `sd_app_evt_wait()` nor after `sd_app_evt_wait()` returns).

I’m quite sure, that the pending event is 0x400000 and thus the SWI2_EGU2_IRQn is the cause for the returning of `sd_app_evt_wait()`, because if I clear that pending flag directly after `sd_app_evt_wait()` returns, the next calls to `sd_app_evt_wait()` will then not return immediately.

When using `sd_app_evt_wait()`, `sd_app_evt_wait()` starts to return immediately, after I connect (BLE) to the application. When I replace `sd_app_evt_wait()` by __WFI(), __WFI() will return immediately even before I connect to the application. If I replace __WFI(), by „__SEV(); __WFI(); __WFI();“, the second __WFI() will put the CPU to sleep, as expected (during startup, after connection, during the connection) and the application works still as expected.

I applied the workaround for PAN_87 to find the cause, why a single __WFI() is not sufficient, but to no avail.

To make sure, that there is no interrupt handler served with high frequency, I created an annotated list file of my application and walked through the interrupt vector table. I really found just the two application interrupt handlers (all others where defaults from the nordic startup file, that all just spin). I disabled the interrupts and removed the handlers (which would cause the default handler to be called), but found no difference in the behavior of the application.

What could I try next? I could branch my software and strip it down to as small as possible to let you have a look at it? Maybe the quite old chip version on the Chip on the Eval board could be an issue? I could move to SD 6.1.1, but according to the release notes, there was no bigger changes. Anything else?

best regards,

Torsten

BTW: Thank you for the time you all put into helping me!!!

RE: unexpected sd_app_evt_wait() returning

Susheel Nuguru — Wed, 29 May 2019 06:59:17 GMT

also ISER[ 0 ] is 0x2000905 tells me that SWI2 interrupt is disabled.

IF ISPR = 400000 at that time, and your main is in loop calling sd_app_evt_wait, then it will not go to sleep. Try replacing sd_app_evt_wait with __WFE() iin a loop and see if you see the difference.

RE: unexpected sd_app_evt_wait() returning

Susheel Nuguru — Wed, 29 May 2019 06:53:11 GMT

[quote userid="4223" url="~/f/nordic-q-a/47671/unexpected-sd_app_evt_wait-returning/189196"] I've used 50000, 50010 and 55000. `ISPR[0]` is always `0x400000` and `ISPR[1]` is always 0. [/quote]

Torsten,

I think this thread took a different direction with the information you gave above. When you sniff this registers immediately after waking up from main thread, it should have told you which application interrupt source is waking the chip. Most likely it is the FPU that is the culprit as application tend to configure to use FPU instruction, but do not handle the FPU exeptions since they the FPU excpetions are not enabled by default, making them reside in the pending state for ever and telling the sd_app_evt_wait not to go to sleep.

Are you sure the ISPR values you gave are correct? The beviour you see with wakeup and this ISPR value does not add up.

RE: unexpected sd_app_evt_wait() returning

Torsten Robitzki — Tue, 28 May 2019 11:54:36 GMT

Hi Simon,

the only interrupts that are enabled by my application are `SPIM2_SPIS2_SPI2_IRQn` and `UARTE0_UART0_IRQn`. Both are configured with priority 7 and have quite short running IRQ handlers.

My best guess was, that the SEVONPEND flag in the SCB->SCR would have been set, but it was not set (according to the debugger). But maybe `sd_app_evt_wait()` set the flag before issuing a WFE instruction and restores the flag (just wild guessing)?

There is nothing, that my application blocks on, except `sd_app_evt_wait()` (in a single place). The application is still quite easy to overview and there is nothing else in the application, that behaves strange or weird.

I have a custom `assert()` function in my application and I'm using `assert` quite often. So, I added a test for the SWI2_EGU2 pending flag in the ISPR register in the assert macro implementation. I added asserts before and after a call to `sd_app_evt_wait()` and find, that after `sd_app_evt_wait()` returns, the pending flag is set, after a BLE client connects to the application.

I further added asserts to the end of my IRQ handlers. But still, the first time, that assert finds the SWI2_EGU2 pending flag being set, is after the call to `sd_ble_evt_get()`.

There is an `sd_app_evt_wait()` implementation in the SDK (which is according to my debugger, not in use), that simply issues the __wfe compiler intrinsic. What does the Softdevice version of `sd_app_evt_wait()` looks like?

best regards,

Torsten

RE: unexpected sd_app_evt_wait() returning

Simonr — Tue, 28 May 2019 10:45:24 GMT

I am a bit confused here. The ISPR bits say that SWI2 interrupt is pending, but ISER says that this interrupt is disabled. SWI2 interrupt needs to be enabled in the NVIC level for the application to be able to pull the BLE events. How did this interrupt get disabled?

There are only two ways that this can occur. Either you have suspended the SoftDevice somewhere, or the SoftDevice handler is suspended. Could you please check if you've done this somewhere in the application?

Best regards,

Simon

RE: unexpected sd_app_evt_wait() returning

Torsten Robitzki — Tue, 28 May 2019 07:13:11 GMT

Hi Simon,

the value of ISER[ 0 ] is 0x2000905 and the value of ISER[ 1 ] is 0x9. I had a look into the Softdevice Documentation, for the list of restricted peripherals. There, SWI2_EGU2_IRQn is listed as open, but with a footnote 7, which states:

 Interrupt will be set to pending state by the SoftDevice on SoftDevice Event Notification, but the application may also set it to pending state.

So I guess, that the SD uses SWI2_EGU2 as mean to notify the main thread to wake up. I just cleaned the pending flag directly after `sd_app_evt_wait()` returned and the application seems to work fine (on a first glance). I would expect `sd_app_evt_wait()` to reset the pending flag, and thus to make it transparent for the user, how the SD communicates with `sd_app_evt_wait()`. I've never noticed this behavior in previous versions of the SDK / SD.

Could, simply resetting the pending flag be a valid solution to my problem?

There are no other sleep functions used in the application. `sd_app_evt_wait()` is the only function, where the main thread goes to sleep and it is only called from the main loop.

best regards,

Torsten

RE: unexpected sd_app_evt_wait() returning

Simonr — Tue, 28 May 2019 06:28:39 GMT

Hi Torsten

I've checked this out with my colleagues, and we would like you to check NVIC->ISER registers as we suspect SWI2 is enabled somewhere, which causes the SWI2_EGU2_IRQn.

Another solution would be that the application is trying to go to sleep somewhere else than the main.c file. Can you confirm whether or not you are calling a sleep function somewhere else?

Best regards,

Simon

RE: unexpected sd_app_evt_wait() returning

Torsten Robitzki — Mon, 27 May 2019 12:27:06 GMT

I'm on a DK (PCA10040 V0.9.0), with some GPIOs and mainly SPIs and Timers in use. From the SDK, only system_nrf52.c, gcc_startup_nrf52.S and the softdevice is in use. SDK Version is 15.2.0_9412b96.