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@...

--

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.

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

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)

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

Best regards,
Frank

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

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

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.

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

Hi,

No problem. Good to hear your issue is solved.

Using the zero address as public address is not really an issue however nobody so far can explain if it is normal that the BlueZ stack uses the "random address" when the public address is set to zero.

Anyhow QT is looking at it as it creates an issue when using the QT BLE stack for fetching the HCI controller/adaptor when the public address is set to zero (FYI https://bugreports.qt.io/browse/QTBUG-71727)

Best regards,
Frank

Hi Paul,

As I saw netif based API's in Zephyr stack, I assumed it as lwip stack.
Thanks for clarifying that Zephyr has its own IP stack which is not lwip.

Thanks & Regards,
Deepa

Thanks a lot Frank, I executed commands advertise on and discoverable on as you mentioned, now I can scan out the device with MAC address I set ! 

Now our problems are the same, I will read the source codes to find out the problem, also hope others can pay attention and solve this problem too. Look forward to your progress and good news!

Hi,

For advertising I don't use the hcitool cmd, however I think a fast and easy check can also be done by using either the bluetootctl or the btmgmt tool.

So after executing the bluetoothctl you can activate advertising by just typing : advertise on. I would also execute : discoverable on,  otherwise the nRFConnect will not see the BT device that is advertising.

For a more user friendly approach I would recommend to use a C++ implementation (See e.g. QT heart-rate server applic) to approach the Bluez stack.

Best regards,
Frank

Hello Deepa,

On Sun, 11 Nov 2018 23:43:19 -0800
deepa.gopinath@... wrote:

Hi Paul,

I have found it in this link
- https://github.com/zephyrproject-rtos/zephyr/issues/10561 By
referring the config file also we can able to find Echo client and
server example can be built for either OpenThread or third party IP
stack.
https://github.com/zephyrproject-rtos/zephyr/blob/master/samples/net/echo_client/overlay-ot.conf
Remaining config files will be used to build for other configurations
- https://github.com/zephyrproject-rtos/zephyr/blob/master/samples/net/echo_client/

None of the links you mention has occurrence of "lwip" (case
insensitive) in any material it points to.

Zephyr doesn't work with lwIP, it has own IP stack. However, I'd be
interesting to hear if someone integrated lwIP with Zephyr
(apparently, bypassing its native IP stack), so if you have any links
substantiating that, please feel free to share them.

Thanks & Regards,
Deepa

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

Hello Andrew,


I appreciate the response.

On Fri, 9 Nov 2018 17:57:03 +0000
"Boie, Andrew P" <andrew.p.boie@...> wrote:

I'm patiently waiting for a paradise times when on CPU exception,
assert, etc., we'll be ending up in debugger, point to the
instruction where the problem happened (or it can be seen in
backtrace).

We do dump this info to the console on a fatal CPU exception. On x86
there's even a crude stack trace.

Yes, and actually, over the couple of years, I found that information
to become more usable. Like, I remember when I just started with
Zephyr, I regularly hit cases when I couldn't get anything useful from
such a crash dump, while recently I noticed to myself that it was
helpful each time. I don't know whether format of it changed to be more
detailed/clear, or I got more experience with it, I assume both it.

But sure, it's still pretty far in usability from "desktop" debugging.

But it would be nice, if running
some application under GDB, for the exception to simply break the
debugger at the offending instruction rather than go through Zephyr's
exception handling path.

I'm not sure how this could work, perhaps have the Zephyr exception
handler set up the stack/registers to the original context and issue
a debug exception? Or would this involve some kind of Zephyr-aware
extension to GDB? The problem is always that the stack layout for a
CPU exception is different than a function call, and might not even
be on the same stack, so you can't easily unwind through when the
exception happened to the original faulting context.

Well, if I knew how to do it, I'd go trying to do it myself ;-). So
far, I don't even understand how generic GDB stub (as run on real hw
for GDB debugging), qemu's "meta level stub", Zephyr's builtin stub
(which was remove some time ago) should/would interact to make it
possible to achieve that effect. I remember a year or so ago I set up
to read thru google results on "qemu gdb debugging support", but
figured it's too far-fetched from the normal "Zephyr development" of
which we have a lot to do in queue yet.

That said, you nailed it right - the "user feature request" is exactly
to be able to use GDB as used in normal workstation environment, where
if a binary segfaults, I can run it under qemu, and it's stop and allow
me to review the state right at the instruction which crashes.

So again, I appreciate the response here, let's keep at the back of out
minds, maybe we'll get to implement it later.

Andrew

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

Hi,

On 13 Nov 2018, at 0.38, @abaska wrote:
I am trying to configure Zephyr as a HCI UART host.

My setup:
• nrf52840_pca10056 nordic dev kit running zephyr/samples/bluetooth/hci_uart. This seems pretty straight forward.
• stm32f746g_disco dev kit running zephyr/samples/bluetooth/mesh. When selecting the mesh sample the build environment knows to automatically select BT_HCI_HOST.
• 4 UART lines between the two boards. Rx, Tx, RTS, and CTS.

Is this a valid setup? I really only need zephyr running as the host and then the HCI controller could be any controller that speaks HCI UART, but right now I have both boards running zephyr. I found documentation on zephyr HCI controller, but not much on zephyr being the HCI host.

This is a valid and quite common set up. The most important thing you'll need to enable is the host-side UART HCI driver using CONFIG_BT_H4=y.

Johan

Hi Frank，
    Thanks for your suggestions, The mac address was changed successfully under your instructions, but I still cannot discover the device with nRFConnect smartphone app.
That seems all the difference between us.
After I changed mac address of the controller, I just set advertise data and enabled advertise function:
The advertise data I set was :
hcitool -i hci0 cmd 0x08 0x0008 1e 02 01 06 03 03 aa fe 17 16 aa fe 00 -10 00 01 02 03 04 05 06 07 08 09 0a 0b 0e 0f 00 00 00 00
Then I set advertise function enable:
sudo hcitool -i hci0 cmd 0x08 0x000a 01

would you please tell what commands you executed to make the controller advertise normally ? Thanks

Hello,

I am trying to configure Zephyr as a HCI UART host.

My setup:

• nrf52840_pca10056 nordic dev kit running zephyr/samples/bluetooth/hci_uart. This seems pretty straight forward.
• stm32f746g_disco dev kit running zephyr/samples/bluetooth/mesh. When selecting the mesh sample the build environment knows to automatically select BT_HCI_HOST.
• 4 UART lines between the two boards. Rx, Tx, RTS, and CTS.

Is this a valid setup? I really only need zephyr running as the host and then the HCI controller could be any controller that speaks HCI UART, but right now I have both boards running zephyr. I found documentation on zephyr HCI controller, but not much on zephyr being the HCI host.

In running this I would expect to see the mesh sample run. IE to be able to see a configurable mesh device and to be able to provision it. What I am seeing is one UART message in either direction (seen via scope) then nothing. I started divining into the hci code but wanted to reach out to see if anyone has ever ran zephyr as a bluetooth HCI host before.

I'm developing a shell module for the sensor drivers and I want to
validate if the device name passed from the user is a sensor device.

The userspace infrastructure has facilities for this, but as I commented in your patch, what you are doing is only intended for system call handlers. The Zephyr kernel running in supervisor mode is intended to be very lightweight and doesn't have features like this, it's a garbage-in-garbage-out type of situation.

The proper way to do this is have the shell main loop run in user mode, it's the only way to make robust assertions that malformed user input can't hose the system. I suggest just dropping the checks.

Andrew