Hi, I am trying to get the current time using the following: However, this is giving me an error on Qemu: Is there a reason for this? Also, is there another way to get the current time of the system

Hi Johan, I looked at the recent commits and didn't see any connection either.That's why I gave up and did the bisect. Is it possible that because the buffer wasn't released, subsequent commands

Pushpal please, at the very least, send your results to this mailing or, beyond the minimum, make a post online and make a note here for others to view your evaluation results.

Thanks for the suggestions / information. I'll begin evaluating these. This may be a great interim solution until the switch to CMake is made and fully tested out. -

Hi all, I have sent a proposal for a new HTTP API at https://github.com/zephyrp roject-rtos/zephyr/pull/4243 so in order to get more comments and feedback I am sending this mail. The PR#4243

Hi Steve, It's still a mystery how that's related to the patch you found with bisect. Did you try the v2 of my patch? The first version will not make any difference to you since it had the missing

This patch fixed it. Thanks, Steve

Hi Johan, More ... In looking at the log, it appears that the beacon_complete callback never gets called from bt_mesh_adv_send. So, net_buf_unref never gets called and we run out of buffers. Steve

Hi Steve, Here's version 2. The first attempt didn't take the account the jump to a label in the success case. So ignore the earlier and test this one, please. Johan

Hi John, Didn't fix it. Identical log. Steve

Hi Steve, I went through the patch in question, and found a leak of a net_buf object. I wonder if the available buffer count has been so well fine-tuned that loosing just one causes this issue.

Hi, I am using the eclipse CDT standalone debugger without any issues. Yannis

I've been using Eclipse <https://www.eclipse.org/> + "C/C++ Hardware Debugging" plug-in for a while. It works flawlessly and is reasonably easy to setup. If you are developing on ARM there is also

The samples/bluetooth/mesh fails on my nrf52840_pca10056 Below is the debug output of both the failing and non-failing cases. I bisected down to: first bad commit:

Hi Pushpal, We are in the process of switching from Make/Kbuild to CMake. Once this transition is complete it should be possible to generate IDE projects from CMake itself, although the focus

Thanks for the suggestion Justin. Haha, by old school, I meant they are very far removed from CLI debugging through gdb (which is what I'm used to) as they've been using tools like IAR for a while.

I would look into Segger https://www.segger.com/. They make a great debugger and they have a debugger IDE. I use it with Zephyr and I code with Sublime text. Some peripherals can't be debugged with

Hi All, I'm trying to convince my company to switch to Zephyr, but the lack of an actual IDE with a nice graphical debugger startles them (these are old-school type firmware people who have gotten

Hi all, I plan to rework GPIO API to fix the issue #2529 https://github.com/zephyrproject-rtos/zephyr/issues/2529. But first I would like to clean it up a bit. One thing which is confusing and feels

Hi Tamra, This PR is merged now, so simply rebuilding and flashing your nRF51 & Quark SE Zephyr images from the upstream master branch should yield a solution where the Bluetooth address remains the