Date   

Re: can zephyr sdk support macos?

Marti Bolivar <marti@...>
 

On Fri, Nov 16, 2018 at 12:03 AM Andrei
<andrei.emeltchenko.news@gmail.com> wrote:

Hi,

On Thu, Nov 15, 2018 at 10:52:55AM -0700, Marti Bolivar wrote:
The Zephyr SDK is Linux-only.
https://docs.zephyrproject.org/latest/getting_started/installation_mac.html
The Zephyr SDK covers the toolchain, which is not discussed on that
page at the moment. The main document has information on toolchain
installation:

https://docs.zephyrproject.org/latest/getting_started/getting_started.html




Best regards
Andrei Emeltchenko

On Thu, Nov 15, 2018 at 6:14 AM cstyle <cstyle.z.zhou@outlook.com> wrote:

can zephyr sdk support macos?



Re: can zephyr sdk support macos?

Andrei
 

Hi,

On Thu, Nov 15, 2018 at 10:52:55AM -0700, Marti Bolivar wrote:
The Zephyr SDK is Linux-only.
https://docs.zephyrproject.org/latest/getting_started/installation_mac.html

Best regards
Andrei Emeltchenko

On Thu, Nov 15, 2018 at 6:14 AM cstyle <cstyle.z.zhou@outlook.com> wrote:

can zephyr sdk support macos?


Re: NRF52 Scanning stops without indication

Chettimada, Vinayak Kariappa
 

Hi Jon,

Could you please share a simple application or an upstream Zephyr sample that can reproduce this memory leak?

From the look of it, the controller's rx buffers have been leaked. Is there any chance, any of the threads aborted? (incorrect application code in direct call path of stack's callbacks can crash or stall the stack).

Something that can help me debug is the SHA hash of the Zephyr source code, a simple application that will reproduce it and an approximate duration you want me to wait for the issue be reproduced.

Regards,
Vinayak

-----Original Message-----
From: <devel@lists.zephyrproject.org> on behalf of Jon Pry <jon@stel.life>
Date: Thursday, 15 November 2018 at 5:54 PM
To: "devel@lists.zephyrproject.org" <devel@lists.zephyrproject.org>
Subject: [Zephyr-devel] NRF52 Scanning stops without indication




Hi,

We are running continuous active scan on NRF52 with duplicate filtering disabled. Under some circumstances all scan data stops being generated. This has been difficult to reproduce but is a serious bug for our application. It takes thousands of hours of
device run time for us to create and identify this issue. I was able to capture a memory dump of such a device and am trying to examine it for any indication of the problem. I'm looking primarily at _radio state, but if anyone has any pointers I would appreciate
it. The zephyr version that create this dump is master branch as of 10/26.


(gdb) p 'ctrl.c'::_radio
$20 = {
hf_clock = 0x20007668 <__device_clock_nrf5_m16src>,
entropy = 0x20007680 <__device_entropy_nrf5>,
ticks_anchor = 3215498,
remainder_anchor = 0,
is_k32src_stable = 1 '\001',
ticker_id_prepare = 5 '\005',
ticker_id_event = 0 '\000',
ticker_id_stop = 0 '\000',
role = ROLE_NONE,
state = STATE_NONE,
advertiser = {
hdr = {
ticks_xtal_to_start = 39,
ticks_active_to_start = 0,
ticks_preempt_to_start = 0,
ticks_slot = 150
},
chan_map_current = 0 '\000',
rfu = 0 '\000',
is_hdcd = 0 '\000',
is_enabled = 1 '\001',
phy_p = 1 '\001',
chan_map = 7 '\a',
filter_policy = 0 '\000',
rl_idx = 255 '\377',
adv_data = {
data = {"`\033\070\r\230X't\002\001\004\021\a\236\312\334$\016\345\251\340\223\363\243\265\001\000@n\000\000\000\000\000\000\000\000\000", "`\033\070\r\230X't\002\001\004\021\a\236\312\334$\016\345\251\340\223\363\243\265\001\000@n\000\000\000\000\000\000\000\000\000"},
first = 0 '\000',
last = 0 '\000'
},
scan_data = {
data = {"D\022\070\r\230X't\v\tStarGateΛ", '\000' <repeats 18 times>, "D\022\070\r\230X't\v\tStarGateΛ", '\000' <repeats 18 times>},
first = 0 '\000',
last = 0 '\000'
},
conn = 0x20002220 <_radio>
},
scanner = {
hdr = {
ticks_xtal_to_start = 39,
ticks_active_to_start = 0,
ticks_preempt_to_start = 10,
ticks_slot = 5948
},
is_enabled = 1 '\001',
state = 0 '\000',
chan = 0 '\000',
rfu = 0 '\000',
phy = 0 '\000',
type = 1 '\001',
filter_policy = 0 '\000',
adv_addr_type = 0 '\000',
init_addr_type = 1 '\001',
rpa_gen = 1 '\001',
rl_idx = 255 '\377',
init_addr = "8\r\230X't",
adv_addr = "\344\350\016\036\341", <incomplete sequence \364>,
ticks_window = 5939,
conn_interval = 40,
conn_latency = 0,
conn_timeout = 400,
ticks_conn_slot = 37,
conn = 0x0 <z_clock_driver_init>,
win_offset_us = 2
},
conn_pool = 0x20002220 <_radio>,
conn_free = 0x0 <z_clock_driver_init>,
connection_count = 1 '\001',
conn_curr = 0x0 <z_clock_driver_init>,
packet_counter = 1 '\001',
crc_expire = 0 '\000',
data_chan_map = "\377\377\377\377\037",
data_chan_count = 37 '%',
sca = 5 '\005',
default_tx_octets = 27,
default_tx_time = 328,
default_phy_tx = 3,
default_phy_rx = 3,
pkt_rx_data_pool = 0x200023d8 <_radio+440>,
pkt_rx_data_free = 0x0 <z_clock_driver_init>,
packet_data_octets_max = 27,
packet_rx_data_pool_size = 208,
packet_rx_data_size = 52,
packet_rx_data_count = 4 '\004',
packet_rx = 0x20002374 <_radio+340>,
packet_rx_count = 5 '\005',
packet_rx_last = 0 '\000',
packet_rx_acquire = 2 '\002',
link_rx_pool = 0x200024a8 <_radio+648>,
link_rx_free = 0x200024d0 <_radio+688>,
link_rx_head = 0x200024a8 <_radio+648>,
link_rx_tail = 0x200024a8 <_radio+648>,
link_rx_data_quota = 2 '\002',
pkt_tx_ctrl_pool = 0x200024d8 <_radio+696>,
pkt_tx_ctrl_free = 0x200024d8 <_radio+696>,
pkt_tx_data_pool = 0x20002520 <_radio+768>,
pkt_tx_data_free = 0x20002520 <_radio+768>,
packet_tx_data_size = 36,
pkt_tx = 0x20002388 <_radio+360>,
pkt_release = 0x200023b0 <_radio+400>,
packet_tx_count = 5 '\005',
packet_tx_first = 1 '\001',
packet_tx_last = 1 '\001',
packet_release_first = 1 '\001',
packet_release_last = 1 '\001',
fc_handle = {0, 0, 0},
fc_req = 2 '\002',
fc_ack = 2 '\002',
fc_ena = 1 '\001',
ticks_active_to_start = 0,
conn_upd = 0x0 <z_clock_driver_init>
}

Thanks,

Jon Pry


Getting started with ARM GNU Compiler | errors | #gettingstartedguide

Balasubramanyam
 

Hi Team,

I am just getting started with Zephyr and trying to setup development environment. I followed all the steps described to setup ARM GNU GCC toolchain and compilation ENV.
After setting up everything required, I got the following error after trying to compile a sample project.

"
CMake Error at ../../cmake/extensions.cmake:1086 (message):
  Assertion failed: The toolchain is unable to build a dummy C file.  See
  CMakeError.log.
Call Stack (most recent call first):
  ../../CMakeLists.txt:28 (assert)
 
 
-- Configuring incomplete, errors occurred!
See also "../zephyr/samples/hello_world/build/CMakeFiles/CMakeOutput.log".
See also "../zephyr/samples/hello_world/build/CMakeFiles/CMakeError.log".
""

I went through the log files  and it seems build failed at following

""
The output was:
1
c:/gnu_arm_embedded/bin/../lib/gcc/arm-none-eabi/7.3.1/../../../../arm-none-eabi/lib\libc.a(lib_a-exit.o): In function `exit':
exit.c:(.text.exit+0x2c): undefined reference to `_exit'
collect2.exe: error: ld returned 1 exit status""

Seems ARM compiler issue, after bit of google found out that these options "--specs=nosys.specs" needs to be passed as command line params to run gcc.
I am not able to figure out where i can exactly instruct build environment to use these command line options for GCC.

I have attached both error and output log. 
Any help will be appreciated to be able to compile a project successfully.

Thanks,
Balasubramanyam Rangineni


Re: can zephyr sdk support macos?

Marti Bolivar <marti@...>
 

The Zephyr SDK is Linux-only.

On Thu, Nov 15, 2018 at 6:14 AM cstyle <cstyle.z.zhou@outlook.com> wrote:

can zephyr sdk support macos?


NRF52 Scanning stops without indication

Jon Pry
 

Hi, 

    We are running continuous active scan on NRF52 with duplicate filtering disabled.  Under some circumstances all scan data stops being generated. This has been difficult to reproduce but is a serious bug for our application. It takes thousands of hours of device run time for us to create and identify this issue. I was able to capture a memory dump of such a device and am trying to examine it for any indication of the problem. I'm looking primarily at _radio state, but if anyone has any pointers I would appreciate it. The zephyr version that create this dump is master branch as of 10/26. 


(gdb) p 'ctrl.c'::_radio
$20 = {
  hf_clock = 0x20007668 <__device_clock_nrf5_m16src>, 
  entropy = 0x20007680 <__device_entropy_nrf5>, 
  ticks_anchor = 3215498, 
  remainder_anchor = 0, 
  is_k32src_stable = 1 '\001', 
  ticker_id_prepare = 5 '\005', 
  ticker_id_event = 0 '\000', 
  ticker_id_stop = 0 '\000', 
  role = ROLE_NONE, 
  state = STATE_NONE, 
  advertiser = {
    hdr = {
      ticks_xtal_to_start = 39, 
      ticks_active_to_start = 0, 
      ticks_preempt_to_start = 0, 
      ticks_slot = 150
    }, 
    chan_map_current = 0 '\000', 
    rfu = 0 '\000', 
    is_hdcd = 0 '\000', 
    is_enabled = 1 '\001', 
    phy_p = 1 '\001', 
    chan_map = 7 '\a', 
    filter_policy = 0 '\000', 
    rl_idx = 255 '\377', 
    adv_data = {
      data = {"`\033\070\r\230X't\002\001\004\021\a\236\312\334$\016\345\251\340\223\363\243\265\001\000@n\000\000\000\000\000\000\000\000\000", "`\033\070\r\230X't\002\001\004\021\a\236\312\334$\016\345\251\340\223\363\243\265\001\000@n\000\000\000\000\000\000\000\000\000"}, 
      first = 0 '\000', 
      last = 0 '\000'
    }, 
    scan_data = {
      data = {"D\022\070\r\230X't\v\tStarGateΛ", '\000' <repeats 18 times>, "D\022\070\r\230X't\v\tStarGateΛ", '\000' <repeats 18 times>}, 
      first = 0 '\000', 
      last = 0 '\000'
    }, 
    conn = 0x20002220 <_radio>
  }, 
  scanner = {
    hdr = {
      ticks_xtal_to_start = 39, 
      ticks_active_to_start = 0, 
      ticks_preempt_to_start = 10, 
      ticks_slot = 5948
    }, 
    is_enabled = 1 '\001', 
    state = 0 '\000', 
    chan = 0 '\000', 
    rfu = 0 '\000', 
    phy = 0 '\000', 
    type = 1 '\001', 
    filter_policy = 0 '\000', 
    adv_addr_type = 0 '\000', 
    init_addr_type = 1 '\001', 
    rpa_gen = 1 '\001', 
    rl_idx = 255 '\377', 
    init_addr = "8\r\230X't", 
    adv_addr = "\344\350\016\036\341", <incomplete sequence \364>, 
    ticks_window = 5939, 
    conn_interval = 40, 
    conn_latency = 0, 
    conn_timeout = 400, 
    ticks_conn_slot = 37, 
    conn = 0x0 <z_clock_driver_init>, 
    win_offset_us = 2
  }, 
  conn_pool = 0x20002220 <_radio>, 
  conn_free = 0x0 <z_clock_driver_init>, 
  connection_count = 1 '\001', 
  conn_curr = 0x0 <z_clock_driver_init>, 
  packet_counter = 1 '\001', 
  crc_expire = 0 '\000', 
  data_chan_map = "\377\377\377\377\037", 
  data_chan_count = 37 '%', 
  sca = 5 '\005', 
  default_tx_octets = 27, 
  default_tx_time = 328, 
  default_phy_tx = 3, 
  default_phy_rx = 3, 
  pkt_rx_data_pool = 0x200023d8 <_radio+440>, 
  pkt_rx_data_free = 0x0 <z_clock_driver_init>, 
  packet_data_octets_max = 27, 
  packet_rx_data_pool_size = 208, 
  packet_rx_data_size = 52, 
  packet_rx_data_count = 4 '\004', 
  packet_rx = 0x20002374 <_radio+340>, 
  packet_rx_count = 5 '\005', 
  packet_rx_last = 0 '\000', 
  packet_rx_acquire = 2 '\002', 
  link_rx_pool = 0x200024a8 <_radio+648>, 
  link_rx_free = 0x200024d0 <_radio+688>, 
  link_rx_head = 0x200024a8 <_radio+648>, 
  link_rx_tail = 0x200024a8 <_radio+648>, 
  link_rx_data_quota = 2 '\002', 
  pkt_tx_ctrl_pool = 0x200024d8 <_radio+696>, 
  pkt_tx_ctrl_free = 0x200024d8 <_radio+696>, 
  pkt_tx_data_pool = 0x20002520 <_radio+768>, 
  pkt_tx_data_free = 0x20002520 <_radio+768>, 
  packet_tx_data_size = 36, 
  pkt_tx = 0x20002388 <_radio+360>, 
  pkt_release = 0x200023b0 <_radio+400>, 
  packet_tx_count = 5 '\005', 
  packet_tx_first = 1 '\001', 
  packet_tx_last = 1 '\001', 
  packet_release_first = 1 '\001', 
  packet_release_last = 1 '\001', 
  fc_handle = {0, 0, 0}, 
  fc_req = 2 '\002', 
  fc_ack = 2 '\002', 
  fc_ena = 1 '\001', 
  ticks_active_to_start = 0, 
  conn_upd = 0x0 <z_clock_driver_init>
}

Thanks,

Jon Pry


Re: Proper way to handle GPIO IRQ enablement

Lincoln Simmons
 

Nice, thanks Tomasz!

It might be a few days before ill be able to test it, but I'll get back to you.

-Lincoln


On Thu, Nov 15, 2018, 6:11 AM Tomasz Bursztyka <tomasz.bursztyka@...> wrote:
Hi Lincoln,

Can you try https://github.com/zephyrproject-rtos/zephyr/pull/11396
(1st commit)

That should solve your issue.

Instead of returning -EALREADY if already installed, I just return 0.

Tomasz


can zephyr sdk support macos?

cstyle
 

can zephyr sdk support macos?


Re: Proper way to handle GPIO IRQ enablement

Tomasz Bursztyka
 

Hi Lincoln,

Can you try https://github.com/zephyrproject-rtos/zephyr/pull/11396
(1st commit)

That should solve your issue.

Instead of returning -EALREADY if already installed, I just return 0.

Tomasz


Re: Proper way to handle GPIO IRQ enablement

Tomasz Bursztyka
 

Hi,

Knowing this, I have a couple of questions:

First, is this already a known and accepted issue that a user is
expected to know to avoid? (Obviously, this would be at the price of
having the most efficient list insertion which seems like an
acceptable tradeoff)
Actually you found a bug. It's not up to the user to know that the cb
is already installed (even though, logically it does not make sense to
add the same cb many times), in other words: gpio should not blindly
install an already installed cb.

I'll open an issue. I think it should check the status of the node, if
already set up, it will try to find it and return an error: -EALREADY
if found, or -EINVAL as it might have been inserted into another
controller's list and we should not touch it.

Once my IRQ pin is configured and my callback added, it looks like I
should ONLY ever use gpio_pin_[enable|disable]_callback() to enable
or disable the IRQ? This is okay, but requires me to maintain more
state in my peripheral device driver. It would be nice if something
catastrophic happens, I could blindly reinitialize my driver and
either (a) have a GPIO api to check if a callback is already
registered before calling gpio_add_callback() or (b) the
gpio_add_callback() function will do nothing if the callback is
already in the list.
I think my fix proposal above should clarify that.
If it returns 0 or -EALREADY, all will be fine.

Any recommendation or comments are appreciated! Or perhaps I'm off
base on something, let me know!
No that was a good catch!

Thanks,

Tomasz


Proper way to handle GPIO IRQ enablement

Lincoln Simmons
 

Hi, I'm attempting to use the Zephyr GPIO API for the first time.  It seems full featured, but I think this has caused me some confusion.  I was debugging my application and found that I got stuck in an infinite loop in _gpio_fire_callbacks().  (For what it's worth, I'm using an nRF52832 chip, so this was called from gpio_nrfx.c)

I am trying to interface with an IRQ pin on a peripheral, so I wrote a couple of enable/disable functions for my driver that look similar to this:

https://gist.github.com/Lncn/49174feb32c2d96dc4e82924b6163c8f

This code was ported from another platform & RTOS where I simply reconfigured the pin entirely when enabling/disabling the device IRQ.  In hindsight this may have been heavy handed.  I was unknowingly calling my "x_enable_irq" function twice in the process of initializing my application and I think this caused my infinite loop.  It appears you cannot call gpio_add_callback twice with the same callback struct, as sys_slist_prepend() will create a circular linked list if the struct gpio_callback reference is already in the list.

Knowing this, I have a couple of questions:

  1. First, is this already a known and accepted issue that a user is expected to know to avoid? (Obviously, this would be at the price of having the most efficient list insertion which seems like an acceptable tradeoff)
  2. Once my IRQ pin is configured and my callback added, it looks like I should ONLY ever use gpio_pin_[enable|disable]_callback() to enable or disable the IRQ?  This is okay, but requires me to maintain more state in my peripheral device driver.  It would be nice if something catastrophic happens, I could blindly reinitialize my driver and either (a) have a GPIO api to check if a callback is already registered before calling gpio_add_callback() or (b) the gpio_add_callback() function will do nothing if the callback is already in the list.
Any recommendation or comments are appreciated!  Or perhaps I'm off base on something, let me know!

Thanks,
Lincoln Simmons
lincolnsimmons@...


Re: #nrf52480 Calling a function not compiled as part of Zephyr from within Zephyr #nrf52480

lairdjm
 

Hi,
I sent a reply using the reply function on the message board site but it seems to have been a private message not a general reply. I fixed this off-by-one issue as I was calling at the function minus one by mistake, I've changed it and can confirm it works fine.
Thanks,
Jamie


From: Marti Bolivar <marti@...>
Sent: Wednesday, November 14, 2018 4:56:57 PM
To: Jamie Mccrae
Cc: devel@...
Subject: Re: [Zephyr-devel] #nrf52480 Calling a function not compiled as part of Zephyr from within Zephyr
 
Hi Jamie,

You might want to take a look at how MCUboot invokes the reset vector
in an NVIC table after having found the image:

https://github.com/runtimeco/mcuboot/blob/master/boot/zephyr/main.c#L53

As you can see, you can cast the address to a function of the
appropriate type and it does work on nRF52840.

If it's an MPU issue in your environment, the kernel developers who
work on userspace would probably benefit from seeing any relevant
Kconfig options in your build/zephyr/.config file.

HTH,
Marti
On Mon, Nov 12, 2018 at 6:24 AM <jamie.mccrae@...> wrote:
>
> Hi,
>
> I am attempting to run an external function on an nRF52840 which is present on the module's flash at a known address but is not part of the Zephyr environment (consider it external). The function doesn't do much except update some pointers which are provided to it, however when attempting to run the function from Zephyr, it generates a usage fault error, "Illegal use of the EPSR". I assume this is caused by a kernel security feature, so how would one go about calling an external function generated in a different build environment from Zephyr without it causing a fault?
>


Re: Confirm your gabriel.wang@arm.com email address

Brett Preston
 

Hi Gabriel,

Confirming that you are subscribed to the devel mail list, so you should have no issues sending, or receiving, messages -

Thanks!


Brett

On Wed, Nov 14, 2018 at 9:06 AM, Gabriel Wang <gabriel.wang@...> wrote:

Hi Zephyr Group

 

I would like to send and receive message.

 

 

 

Best Regards

Gabriel Wang

 

Embedded & Automotive Line of Business

Phone: +44 7387262578

 

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.




--
Brett Preston
Sr. Program Manager
The Linux Foundation
+1 (971) 303-9030


Confirm your gabriel.wang@arm.com email address

Gabriel Wang
 

Hi Zephyr Group

 

I would like to send and receive message.

 

 

 

Best Regards

Gabriel Wang

 

Embedded & Automotive Line of Business

Phone: +44 7387262578

 

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


Re: #nrf52480 Calling a function not compiled as part of Zephyr from within Zephyr #nrf52480

Marti Bolivar <marti@...>
 

Hi Jamie,

You might want to take a look at how MCUboot invokes the reset vector
in an NVIC table after having found the image:

https://github.com/runtimeco/mcuboot/blob/master/boot/zephyr/main.c#L53

As you can see, you can cast the address to a function of the
appropriate type and it does work on nRF52840.

If it's an MPU issue in your environment, the kernel developers who
work on userspace would probably benefit from seeing any relevant
Kconfig options in your build/zephyr/.config file.

HTH,
Marti

On Mon, Nov 12, 2018 at 6:24 AM <jamie.mccrae@lairdtech.com> wrote:

Hi,

I am attempting to run an external function on an nRF52840 which is present on the module's flash at a known address but is not part of the Zephyr environment (consider it external). The function doesn't do much except update some pointers which are provided to it, however when attempting to run the function from Zephyr, it generates a usage fault error, "Illegal use of the EPSR". I assume this is caused by a kernel security feature, so how would one go about calling an external function generated in a different build environment from Zephyr without it causing a fault?


Re: Zephyr (v1.13.0) HCI_UART running on nRF52 DK why BD address is always 00:00:00:00:00:00 after power cycle #nrf52832

frv
 
Edited

Hi Jamie,

Thanks for your explanation.

However for me it remains a riddle (and probably a bug), why the BlueZ implementation selects the random address as HCI adapter address when the public address is set to zero?
When setting the public address different from zero, the DBus topogoly still keeps the address type as random for Adapter1 despite the hcitool cmd 0x3f 0x006  BD_ADDRESS sets the public address.

Nevertheless this solves the QT issue when the hciForAddress function is called in the HciManager object. 

The low level function ioctl(hciSocket, HCIGETDEVINFO, &devInfo) will have a match for the address value in the devInfo when compared to this
new random but still public address (IMHO)


...
for (int i = 0; i < devRequestList->dev_num; i++) {
        devInfo.dev_id = (devRequest+i)->dev_id;
        if (ioctl(hciSocket, HCIGETDEVINFO, &devInfo) < 0) {
            continue;
        }
 
        int result = memcmp(&adapter, &devInfo.bdaddr, sizeof(bdaddr_t));
        if (result == 0 || deviceAdapter.isNull()) // addresses match
            return devInfo.dev_id;

.... 

More details can be read here : https://bugreports.qt.io/browse/QTBUG-71727

Best regards,
Frank


Re: Zephyr (v1.13.0) HCI_UART running on nRF52 DK why BD address is always 00:00:00:00:00:00 after power cycle #nrf52832

lairdjm
 

Hi,
It is correct that a public address starting with 00:00:00 will not work, it is a reserved IEEE address and the addressing scheme follows that standard, see https://www.iana.org/assignments/ethernet-numbers/ethernet-numbers.xhtml
And in regards to any similar problems with random addresses, this is because as stated in the core version 5 Bluetooth guide:
"At least one bit of the random part of the address shall be 0
At least one bit of the random part of the address shall be 1"

Hcitools was deprecated in 2017 and is no longer maintained and should not be used, this is why by default when building BlueZ with the default build options you don't get these utilities. And depending upon the version of Qt you use, you get a different interface for using Bluetooth, very old versions of Qt have their own GATT implementation, newer versions use BlueZ and with 5.11 it was re-written.
Thanks,
Jamie


Re: Zephyr (v1.13.0) HCI_UART running on nRF52 DK why BD address is always 00:00:00:00:00:00 after power cycle #nrf52832

frv
 

Hi icephyr,

I think 2 things are mixed up here in this topic, my problem with the ZERO address as public address was not related to advertising but rather why the Bluez takes the random address as address when the public address is set to zero as it is in my case with the Nordic nRF52832. 
This behaviour is causing a problem in the QT BT stack when creating the QLowPowerController object as the HCI adapter can not be fetched properly based on this random address.

The bluetoothctl is based on the Bluez stack via DBus, this is the same for the QT BT stack... 

IMHO I think your problem was more related to the fact the discover flag was not set. 

Anyhow I hope QT can come up with a better solution or at least explain what the real issue is if it is not in their SW stack. Let's see and hear... 

Best regards,
Frank


Re: Zephyr (v1.13.0) HCI_UART running on nRF52 DK why BD address is always 00:00:00:00:00:00 after power cycle #nrf52832

icephyr
 

Well,I just wonder why we have to set mac address first to make the advertise function normal,since the bluez stack assigned a random address already.
And also, why command advertise on take efforts but hcitool commands can not.
So many differences between hcitools and bluetoothctl, Hope anyone can give an accurate explanation.


Re: Zephyr as HCI Host #uart #bluetoothmesh #hci

@abaska
 

Looks like UART flow control is not implemented on stm32f746g_disco. I am going to get that working. Hopefully that makes this setup work.

2621 - 2640 of 8041