Sending large data in BLE

RE: Sending large data in BLE

Håkon Alseth — Fri, 14 Aug 2020 09:33:03 GMT

Hi,

[quote user="Leo26781"]2020-08-12T14:47:11.181Z DEBUG modem << ASSERTION FAIL [err == 0] @ WEST_TOPDIR/zephyr/subsys/bluetooth/host/hci_core.c:369
2020-08-12T14:47:11.221Z DEBUG modem << k_sem_take failed with err -11 "[/quote]

This is related to the host (nrf91) not being able to communicate with the hci controller (nrf52).

Did you update the hci_uart from ncs v1.3.0 as well?

In ncs v1.3.0, there's an added reset line between the two nRFs, so each time you reset the nRF9160, it also resets the nRF52 on boot up. This is enabled by default when using boards nrf9160dk_nrf9160ns and nrf9160dk_nrf52840.

Kind regards,

Håkon

RE: Sending large data in BLE

Leo26781 — Wed, 12 Aug 2020 15:03:31 GMT

Hi ,

yeah , I tried that too like a cloning into a new folder and did not work. the ninja version i'm using 1.10.0. May be I need to wait for the next version.

BTW , i found the workaround. I mean once we click "Configure ", the configuration is saved in the .config. If I close the SES and open again, I'm able to build the project.

Also the error

2020-08-12T14:47:11.181Z DEBUG modem << ASSERTION FAIL [err == 0] @ WEST_TOPDIR/zephyr/subsys/bluetooth/host/hci_core.c:369
2020-08-12T14:47:11.221Z DEBUG modem << k_sem_take failed with err -11 "

Keeps repeating. But when I reflash the hci_uart , it does not come. when I run my app , it comes. Not sure running my app corrupts the HCI or something ? Any idea to debug ?

With regards,

Saravanan.

RE: Sending large data in BLE

Håkon Alseth — Mon, 10 Aug 2020 10:48:09 GMT

Hi,

This looks to be a problem (corner-case) with ninja:

https://gitlab.kitware.com/cmake/cmake/-/issues/20274

Could you try to use another build folder and see if the problem disappears?

Kind regards,

Håkon

RE: Sending large data in BLE

Leo26781 — Mon, 10 Aug 2020 04:07:00 GMT

Hi ,

I was able to solve that by reflashing twice . Now I'm trying to reconfigure the MTU size by comfiguring the Zephyr OS using menuconfig in SES. after configuration, I'm not able to build it:

"Changed board to secure nrf9160dk_nrf9160 (NOT NS)
-- Configuring done
-- Generating done
CMake Error:
Running

'C:/ProgramData/chocolatey/bin/ninja.exe' '-C' 'D:/Workspace/nordic/Master/nrf/samples/nrf9160/lte_ble_gateway/build_nrf9160dk_nrf9160ns' '-t' 'recompact'

failed with:

ninja: error: failed recompaction: Permission denied

CMake Error:
Running

'C:/ProgramData/chocolatey/bin/ninja.exe' '-C' 'D:/Workspace/nordic/Master/nrf/samples/nrf9160/lte_ble_gateway/build_nrf9160dk_nrf9160ns' '-t' 'restat' 'build.ninja'

failed with:

ninja: error: failed recompaction: Permission denied

CMake Generate step failed. Build files cannot be regenerated correctly.
Project load failed
Reported error: solution load command failed (1)

Any idea ?

With regards,
Saravanan

RE: Sending large data in BLE

Håkon Alseth — Fri, 07 Aug 2020 08:14:19 GMT

Hi,

It looks like its not able to successfully interface the nRF52840 device.

Did you recompile hci_uart for board "nrf9160dk_nrf52840" and flash this one as well?

The nRF9160 should be able to reset the nRF52840 device on boot up.

Kind regards,

Håkon

RE: Sending large data in BLE

Leo26781 — Fri, 07 Aug 2020 07:10:23 GMT

Hi ,

I updated to v1.3.0 release. I followed this link:

http://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/samples/nrf9160/lte_ble_gateway/README.html.

I flashed the Bluetooth-HCI-UART , and then flashed the lte_ble_gateway.

When I reboot , my board resets with the following error:

2020-08-07T07:03:04.824Z DEBUG modem << *** Booting Zephyr OS build v2.3.0-rc1-ncs1 ***
2020-08-07T07:03:04.827Z DEBUG modem << LTE Sensor Gateway sample started
2020-08-07T07:03:04.831Z DEBUG modem << Initializing Bluetooth..
2020-08-07T07:03:04.834Z DEBUG modem << Establishing LTE link (this may take some time) ...
2020-08-07T07:03:14.821Z DEBUG modem << ASSERTION FAIL [err == 0] @ D:/Workspace/nordic/ncsmaster/zephyr/subsys/bluetooth/host/hci_core.c:370

Am I missing anything ?

With regards,

Saravanan

RE: Sending large data in BLE

Håkon Alseth — Wed, 05 Aug 2020 11:28:35 GMT

Hi,

[quote user="Leo26781"][/quote]

I checkout v1.3.0 now.

Is that fine ?

Yes, that is fine. That is the latest stable release as of now.

Cheers,

Håkon

RE: Sending large data in BLE

Leo26781 — Tue, 04 Aug 2020 14:30:08 GMT

Hi ,

Yes doing that now. can you ping me the latest version. I checkout v1.3.0 now.

Is that fine ?

RE: Sending large data in BLE

Håkon Alseth — Tue, 04 Aug 2020 14:02:49 GMT

Hi,

Can you try rebasing to a newer ncs version to see if the issue still occurs there?

There has been a lot of fixes in ncs/zephyr since that release.

Kind regards,

Håkon

RE: Sending large data in BLE

Leo26781 — Tue, 04 Aug 2020 13:39:39 GMT

Hi ,

The following are the version , I'm using :

nrf - version - v1.0.0

RE: Sending large data in BLE

Håkon Alseth — Tue, 04 Aug 2020 10:17:17 GMT

Hi,

[quote user="Leo26781"]In this line[/quote][quote user="Leo26781"]if (conn->state != BT_CONN_CONNECTED) {[/quote]

This does not correspond to the att.c that is located in zephyr (ncs tag v1.2.0 or v1.3.0). Which revision of ncs are you using?

Could you share a bit more about what your application is doing (source code) ?

Kind regards,

Håkon

RE: Sending large data in BLE

Leo26781 — Tue, 04 Aug 2020 04:46:15 GMT

Hi Hakon ,

I traced the second fault - 0x351be(I added some prints and the offset is changed) and it points to the following:

$ arm-none-eabi-addr2line.exe -e zephyr.elf 0x351be
D:/Workspace/nordic/ncs/zephyr/subsys/bluetooth/host/att.c:1960

In this line

if (conn->state != BT_CONN_CONNECTED) {

BT_WARN("Not connected");
return NULL;
}

BTW if we see in the above logs , it gets connected and MTU is requested. MTU request was pending , then there is multiple connect and MTU request ?

But from Android app , they try to connect only once.

Any idea why is this behaviour ?

RE: Sending large data in BLE

Håkon Alseth — Mon, 03 Aug 2020 09:03:49 GMT

You can check the map file (buildfolder/zephyr.map) or do an addr2line lookup there as well:

arm-none-eabi-addr2line.exe -e zephyr.elf 0x351e0

However; if you have recompiled, and changed the .elf file, this is likely not valid anymore. So, let it run and get the "new" faulting address and see what it shows.

Kind regards,

Håkon

RE: Sending large data in BLE

Leo26781 — Fri, 31 Jul 2020 15:30:31 GMT

Hi Hakon ,

Is there any way to debug the first fault. How to debug that ? I mean stack trace or something like that ?

RE: Sending large data in BLE

Håkon Alseth — Fri, 31 Jul 2020 06:36:27 GMT

Hi,

This is the failing address in the second fault:

0x351e0

0x20026d0c is the RAM location of the thread it was executed from.

Kind regards,

Håkon

RE: Sending large data in BLE

Leo26781 — Fri, 31 Jul 2020 02:25:58 GMT

Hi Hakon,

In the second fault , it shows the following:

$ arm-none-eabi-addr2line.exe -e zephyr.elf 0x20026d0c
reent.c:?

And yes the everytime I change the source , I do a Clean Solution , then BUIld Solution. So I guess source and elf matches.

Also is there any way we can see the thread stack usage or something like that or debug this ?

RE: Sending large data in BLE

Håkon Alseth — Thu, 30 Jul 2020 14:41:46 GMT

Hi Leo,

But, in the first fault this is printed:

[quote user=""]2020-07-30T07:41:04.125Z DEBUG modem << Current thread ID = 0x20020a48
2020-07-30T07:41:04.127Z DEBUG modem << Faulting instruction address = 0x20029374[/quote]

This could be a overflow into that region, so it could be something that is located higher up that is actually causing the issue.

In the next fault, this is printed:

[quote user=""]2020-07-30T07:45:30.985Z DEBUG modem << Current thread ID = 0x20026d0c
2020-07-30T07:45:30.986Z DEBUG modem << Faulting instruction address = 0x351e0[/quote]

Does this one tell you anything related the fault?

Note that if you recompile or change the source in any way, the .elf file will change/reorder your addresses, so it is important that the firmware and .elf file always match each other.

Kind regards,

Håkon

RE: Sending large data in BLE

Leo26781 — Thu, 30 Jul 2020 13:33:46 GMT

Hi ,

Yes I tried addr2line:

$ arm-none-eabi-addr2line.exe -e zephyr.elf 0x20020a48
D:\Workspace\nordic\ncs\nrf\samples\nrf9160\lte_ble_gateway\build_nrf9160_pca10090ns/../src/ble_peripheral.c:41

There have a k_thread declared like this:

static struct k_thread my_thread_data;

#define STACKSIZE 4096

static K_THREAD_STACK_DEFINE(threadstack, STACKSIZE);

And I start the thread like this:

led_tid = k_thread_create(&led_thread, threadstack,
K_THREAD_STACK_SIZEOF(threadstack),
led_blink_thread,
NULL, NULL, NULL,
LED_PRIORITY, 0, K_SECONDS(7));

Not sure whether am I missing something . Also it crashes always in the same place.

BTW the heap size are as follows:

CONFIG_HEAP_MEM_POOL_SIZE=16384
CONFIG_MAIN_STACK_SIZE=8192

I guess this size is more than enough

With regards,

Leo

RE: Sending large data in BLE

Håkon Alseth — Thu, 30 Jul 2020 12:44:39 GMT

Hi,

Its hard to say what is failling here, but you can try to resolve the address using "arm-none-eabi-addr2line":

arm-none-eabi-addr2line -e build/zephyr.elf 0xFAILINGADDR

This should give you a indication on where the fault occurred.

It seems that you are first receiving a usage-fault, then on the next reboot; a hard fault. Is the fault and address where it faults changing between each reboot?

If yes; Can you try to adjust your stack/heap size, by doubling them? via. configs CONFIG_MAIN_STACK_SIZE and CONFIG_HEAP_MEM_POOL_SIZE.

Kind regards,

Håkon