Anas, If we go into Coverity and items as a “bug” will there be some sort of automation that will generate a bug ticket in the github issues? David

Hi Jie, Usually a host stack doesn't have to do anything special with public addresses since controllers that support them come with the address pre-programmed. All you need to say is that you want

Hello,

Hi JC, One obvious thing you need to do, which nevertheless is easy to overlook, is setting Kconfig option CONFIG_DEBUG=y It disables compiler optimizations and adds debug symbols to the bin file.

I was indeed only responding on MTU handling (as both PR do in a way). As I am not using at all user APIs, I can't tell what would be the best. But the issue is mostly found in the API usage it

Regards, Anas Nashif Begin forwarded message:

Hello Tomasz, Thanks for responding and bringing up this discussion - it got backlogged (so I'm doing homework on it in the background). Tomasz Bursztyka <tomasz.bursztyka@...>

Hi all, Looking at the bluetooth API and the sample bluetooth code, tt seems that the default advertised address addr->type is random. I think this is because of security reasons, so it is using

Hello Marti, Marti Bolivar <marti.bolivar@...> wrote: Because "static" has different semantics in different contexts. For example, we don't want to touch "static inline" functions. Though,

Why not just #define static SOMETHING_ELSE as needed?

Hi guys, (...) Actually I missed the fact PR 1330 was about MTU handling. Does not sound generic enough. In the end I don't approve both of the proposed solution. Let me explain why: First, let's

Hello All: I've got a couple of questions on setting up a debug environment. I'm running Ubuntu 16.04 LTS in a Virtualbox VM. I'm using Eclipse Oxygen CDT for development and openOCD for debugging.

The _SysFatalErrorHandler function (implemented under arch/) has the hard fault policy and is declared __weak. Applications may implement their own version of it. HTH, Andrew

Hi Johan, Thanks for the reply. It is clearly not possible to reduce the stack usage of tinycrypt. Regarding the coexisting of network state and provisioning state, would it be possible to use the

Hi, Sometimes I run into the situation where a hard fault is triggered (e.g. a bluetooth mesh node with a BT_RX_STACK_SIZE that is set to small). The result of this is a system hang. I can correct

Weird, I’ll try and look into this. I kicked off a re-build of your PR to see if that deals with it. It looks like there is a fix in master. I’ve updated the ‘arm’ branch against master, so

Hi there, I rebased pull request #4458 on the latest upstream arm-branch. Shippable tests fail (results) , but it seems unrelated to my changes. For example in test-run #1 it fails at

Hi, I am trying the two functions: k_cycle_get_32() and k_uptime_get(). From what I understand, k_cycle_get_32() uses the hardware clock and k_uptime_get() uses the system clock. However, the

Hi Jehudi, The large stack footprint of TinyCrypt is one of my pet peeves with it as well. You could pre-generate the public-private keypair, but then you're still left with calculating the DHKey

Hi, On a zephyr device with bluetooth mesh tinycrypt-ecc is used to generate the ecdh key. Tinycrypt uses a stack of 1kb which is quite large on small ram (16kb) devices. Is it possible to