direction_finding_connectionless_tx - MPU problem/stack

RE: direction_finding_connectionless_tx - MPU problem/stack

Simonr — Thu, 22 Aug 2024 08:00:15 GMT

Hi Avi

I think the synchronization and CTE might not be able to finish that quick, so every 2 seconds might be tight, but switching between them might be possible. Note that you will also need to have room for your application with the two advertising sets on the nRF52833, so you need to test if the application can fit on the RAM and Flash memory that the nRF52833, but it should be possible to switch between the two, yes. Check out the MPSL timeslots for how NCS handles such things.

Best regards,

Simon

RE: direction_finding_connectionless_tx - MPU problem/stack

Avi — Tue, 20 Aug 2024 12:07:03 GMT

I understand.

Will it be possible to switch transmissions?

i.e. every 2 odd seconds AOA (1,3,5,7 ...)

and every 2 even seconds, BLE5 long range (0, 2,4,6...)

RE: direction_finding_connectionless_tx - MPU problem/stack

Simonr — Tue, 20 Aug 2024 12:00:33 GMT

Glad to hear you were able to figure that out.

I'm afraid using Coded PHY (long range) and AOA will not be possible as the continuous tone extension sent during AOA is not compatible with the repeat of transmissions done in Coded PHY (long range).

Best regards,

Simon

RE: direction_finding_connectionless_tx - MPU problem/stack

Avi — Sun, 18 Aug 2024 20:15:30 GMT

Thanks, I was able to get the correction of the code from UBLOX, indeed it was a specific data that had to be sent.

Another related question, is it possible to combine a BLE5 long range with the transmission of the Eddystone/AOA?

Can you show an example based on the original code of NCS?

RE: direction_finding_connectionless_tx - MPU problem/stack

Simonr — Thu, 15 Aug 2024 14:03:08 GMT

Hi Avi

Okay. I see this is only the source code for the tag, and not the scanner/antenna array, where I assume the filter would be. Please contact U-Blox to make sure there is no filter like this. You can try changing the device name to the same as in the U-Blox tag code with CONFIG_BT_DEVICE_NAME="u-blox C209 DF Tag" to see if there's maybe some check on the central side only scanning for devices named DF tags.

There is no Eddystone transmission in the NCS sample, so this must be something U-blox has added. This UUID could also be what the central is filtering.

static uint8_t uuid[EDDYSTONE_INSTANCE_ID_LEN];

Best regards,

Simon

RE: direction_finding_connectionless_tx - MPU problem/stack

Avi — Wed, 14 Aug 2024 10:17:51 GMT

I am using the same nrf52833 device for both the UBLOX code and the code from Nordic. So it is not a "UBLOX device".

As for the UBLOX code, I am not aware of any filter.

The UBLOX code is provided at: https://github.com/u-blox/c209-aoa-tag

It is a connectionless transmission

In UBLOX code, I get also a eddystone transmission. Is it also part of the Nordic code?

Thanks

Avi

RE: direction_finding_connectionless_tx - MPU problem/stack

Simonr — Wed, 14 Aug 2024 10:12:30 GMT

My guess for why you don't see it on the UBlox antenna is that there is some filter on the receiver side set to only pick up and accept transmissions from UBlox devices, so you need to find out what filters it is using. UBlox should probably know what these are. Also, do the UBlox code also work in a connectionless setup and don't connect to the device?

Best regards,

Simon

RE: direction_finding_connectionless_tx - MPU problem/stack

Avi — Tue, 13 Aug 2024 12:26:57 GMT

After increasing the stack size, it started to run:

Update CTE params...success
Periodic advertising params set...success
Enable CTE...success
Periodic advertising enable...success
Extended advertising enable...success
Get extended advertising address...success
Started extended*** Booting nRF Connect SDK v2.7.0-5cb85570ca43 ***
*** Using Zephyr OS v3.6.99-100befc70c74 ***
Starting Direction Finding periodic advertising Beacon Demo
Bluetooth initialization...[00:00:00.257,324] <inf> bt_hci_core: HW Platform: Nordic Semiconductor (0x0002)
[00:00:00.257,354] <inf> bt_hci_core: HW Variant: nRF52x (0x0002)
[00:00:00.257,385] <inf> bt_hci_core: Firmware: Standard Bluetooth controller (0x00) Version 3.6 Build 99
[00:00:00.257,995] <inf> bt_hci_core: Identity: C0:12:9B:D4:B8:63 (random)
[00:00:00.258,026] <inf> bt_hci_core: HCI: version 5.4 (0x0d) revision 0x0000, manufacturer 0x0059
[00:00:00.258,056] <inf> bt_hci_core: LMP: version 5.4 (0x0d) subver 0xffff
success
Advertising set create...success
Update CTE params...success
Periodic advertising params set...success
Enable CTE...success
Periodic advertising enable...success
Extended advertising enable...success
Get extended advertising address...success
Started extended advertising as C0:12:9B:D4:B8:63 (random)

Here is my prj.conf:

CONFIG_BT=y
CONFIG_BT_DEVICE_NAME="DF Connectionless Beacon App"

CONFIG_BT_EXT_ADV=y
CONFIG_BT_PER_ADV=y
CONFIG_BT_BROADCASTER=y

# Enable Direction Finding Feature including AoA and AoD
CONFIG_BT_DF=y
CONFIG_BT_DF_CONNECTIONLESS_CTE_TX=y
CONFIG_LOG=y
CONFIG_LOG_BACKEND_RTT=y

CONFIG_MAIN_STACK_SIZE=8192

But I dont see any reception by the AOA antenna made by UBLOX (B10). I can receive tags with UBLOX code which are programmed into the same nrf52833dk

UBLOX told me that I can use Nordic tx tag with the code from the ncs - as I am doing now. But there is no recpetion

What can be the reason?

RE: direction_finding_connectionless_tx - MPU problem/stack

Avi — Tue, 13 Aug 2024 12:08:06 GMT

00> [00:00:00.249,267] <dbg> mpu: region_init: [2] 0x20003740 0x150b000a
00> [00:00:00.249,298] <dbg> bt_hci_core: hci_tx_thread: Started
00> [00:00:00.249,298] <dbg> bt_hci_core: hci_tx_thread: Calling k_poll with 1 events
00> [00:00:00.249,328] <dbg> mpu: mpu_configure_region: Configure MPU region at index 0x2
00> [00:00:00.249,328] <dbg> mpu: region_allocate_and_init: Program MPU region at index 0x2
00> [00:00:00.249,359] <dbg> mpu: region_init: [2] 0x20004e80 0x150b000a
00> [00:00:00.249,420] <dbg> os: setup_thread_stack: stack 0x20003a80 for thread 0x20000988: obj_size=1280 buf_start=0x20003ac0 buf_size 1216 stack_ptr=0x20003f80
00> [00:00:00.249,450] <dbg> mpu: mpu_configure_region: Configure MPU region at index 0x2
00> [00:00:00.249,450] <dbg> mpu: region_allocate_and_init: Program MPU region at index 0x2
00> [00:00:00.249,481] <dbg> mpu: region_init: [2] 0x20003a80 0x150b000a
00> [00:00:00.249,511] <dbg> mpu: mpu_configure_region: Configure MPU region at index 0x2
00> [00:00:00.249,542] <dbg> mpu: region_allocate_and_init: Program MPU region at index 0x2
00> [00:00:00.249,542] <dbg> mpu: region_init: [2] 0x20004e80 0x150b000a
00> [00:00:00.249,633] <dbg> mpu: mpu_configure_region: Configure MPU region at index 0x2
00> [00:00:00.249,664] <dbg> mpu: region_allocate_and_init: Program MPU region at index 0x2
00> [00:00:00.249,664] <dbg> mpu: region_init: [2] 0x20003400 0x150b000a
00> [00:00:00.248,962] <dbg> mpu: region_init: [2] 0x20006ec0 0x150b000a
00> [00:00:00.249,786] <err> os: ***** MPU FAULT *****
00> [00:00:00.249,816] <err> os: Stacking error (context area might be not valid)
00> [00:00:00.249,816] <err> os: Data Access Violation
00>
00> [00:00:00.249,816] <err> os: MMFAR Address: 0x20003438
00> [00:00:00.249,847] <err> os: r0/a1: 0x95de2e74 r1/a2: 0x9ede1e6b r2/a3: 0xc21aabe9
00> [00:00:00.249,877] <err> os: r3/a4: 0x0902ecd0 r12/ip: 0xff37f464 r14/lr: 0x2953c887
00> [00:00:00.249,877] <err> os: xpsr: 0x21000000
00> [00:00:00.249,908] <err> os: Faulting instruction address (r15/pc): 0x00014c98
00> [00:00:00.249,938] <err> os: >>> ZEPHYR FATAL ERROR 2: Stack overflow on CPU 0
00> [00:00:00.249,969] <err> os: Current thread: 0x20000448 (unknown)
00> [00:00:01.373,321] <err> os: Halting system

RE: direction_finding_connectionless_tx - MPU problem/stack

Simonr — Tue, 13 Aug 2024 11:08:02 GMT

Please provide some details on the error you're seeing. Can you upload the logging file so we can take a look at exactly what this MPU error says and what the stack size error says.

Most likely what is wrong is that you need to increase the CONFIG_MAIN_STACK_SIZE or CONFIG_BT_RX_STACK_SIZE in your prj.conf file.

Best regards,

Simon