Date   

Re: Bluetooth Address Type - Fixed (public)

Johan Hedberg
 

Hi Jie,

On Thu, Oct 26, 2017, Jie Zhou wrote:
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 resolvable private addresses.
Is there a way for me to change the address type to public (i.e. fixed) for
my curie board? I see it in the API that there is cases for public
bluetooth address. However, I just can't seem to find how to change the
addr-type to public. I see the #define BT_ADDRLE_PUBLIC 0x00 in
include/bluetooth/hci.h, but don't know how to implement it. Does anyone
know how to do this?
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 to use it.

You might want to read up on the Bluetooth address types in the
Bluetooth Core specification, since it seems you have the details a bit
mixed up. You can find the relevant information in "Vol 6, Part B,
section 1.3 Device Address". You'll see that using a random address is
not necessarily for security reasons. E.g. if a device doesn't have a
public address, then a static random address can act as the Identity
Address (which is the case with the current Zephyr controller).

Also note that public addresses are managed by each company that the OUI
in the address belongs to, so you shouldn't just go creating arbitrary
public addresses and using them.

This all said, we do have an HCI vendor extension that lets the host
stack set a public address to the controller (remember, the Zephyr
controller starts with no public address at all). However, currently the
host-side has no code for using this vendor HCI command. It should be
fairly simple to add though, and I might have the time to look at it in
the coming weeks.

Johan


Re: BSD Sockets in mainline, and how that affects design decisions for the rest of IP stack (e.g. send MTU handling)

Paul Sokolovsky
 

Hello,

On Wed, 11 Oct 2017 13:06:25 +0300
Jukka Rissanen <jukka.rissanen@...> wrote:

[]

You are unnecessarily creating this scenario about pro or against
solution. I have an example application in
https://github.com/zephyrproject-rtos/zephyr/pull/980 that needs to
send large (several kb) file to outside world using HTTP, and I am
trying so solve it efficiently. The application will not use BSD
sockets.
So, this thread got backlogged somehow (bumped up by Tomasz yesterday),
so I decided to approach it from the other side - to look into your
usecase (#980) and see how easy it would be to convert it to rely on
https://github.com/zephyrproject-rtos/zephyr/pull/119 instead.

Before going to that, I'd like to mention another thing which happened
in the meantime: https://github.com/zephyrproject-rtos/zephyr/pull/4402
got merged, which actually uses the technique proposed by me to send
largish files (more than 1 network packet), and can pass a more or less
non-trivial load tests (10000 iterations with Apache Bench). That's an
improvement from few months ago, when it was easy to deadlock it with
much less iterations. So, the solution can be called "tested and tried"
now, in a sense. (There're still deadlocks happening (e.g. #4216)
which we need to investigate.)


Anyway, back to your
https://github.com/zephyrproject-rtos/zephyr/pull/980. Specifically, I
reviewed its commit
https://github.com/zephyrproject-rtos/zephyr/pull/980/commits/2092924326dc59eea16eb3327a385666431c39e7#diff-1118253502f0844ef016460a07db48df
"samples: net: rpl: Simple RPL border router application".

Looking thru it, I got an idea why a socket sample is subject to
deadlocks (#4216), while other samples maybe not. That's because they
have comments like:

+#if defined(CONFIG_NET_L2_BLUETOOTH)
+#error "TCP connections over Bluetooth need CONFIG_NET_CONTEXT_NET_PKT_POOL "\
+ "defined."
+#endif /* CONFIG_NET_L2_BLUETOOTH */

Instead of investigating cause of deadlocks, they workaround it with:

+#if defined(CONFIG_NET_CONTEXT_NET_PKT_POOL)
+NET_PKT_TX_SLAB_DEFINE(http_srv_tx, 64);
+NET_PKT_DATA_POOL_DEFINE(http_srv_data, 64);

That's 8K with our default fragment size of 128 bytes.

But that's actually not what's done by your sample app, it doesn't
define CONFIG_NET_CONTEXT_NET_PKT_POOL. Instead it defines:

+CONFIG_NET_BUF_RX_COUNT=128
+CONFIG_NET_BUF_TX_COUNT=128

That's 16KB RX and TX buffers each.


So, let's summarize:

Your application, with 16KB send buffer, and patch
https://github.com/zephyrproject-rtos/zephyr/pull/1330, can send files
of several kb in size. Few simple questions:

1. What happens if your app needs to send file of 17KB?
2. What happens if there're no 16KB for send buffers, but only 1-2K?

The answer is obvious: it won't work.


At the same time, my proposal is all about making an API which will
allow any app to send 1MB (or more) files with 1KB (or less) buffers.


I agree with what you wrote - there're different ways to approach
problems and many ways of implementation. But we design an embedded IP
stack, and constrained by the hardware resources ("Zephyr runs in
8K"). It doesn't make sense two implement 2 solutions. We should
choose the one which allows to cover more usecases with less resources.


Now to remind, I started looking with the idea to see how the sample
app can be converted to use short-write-and-retry approach. I found
that it's not directly possible on the level of the app - due to
peculiarities of HTTP API used:
https://github.com/zephyrproject-rtos/zephyr/pull/980#pullrequestreview-71843524

I shared my concerns with the existing HTTP API (e.g.
https://github.com/zephyrproject-rtos/zephyr/issues/3796), and concerns
that its rewrite doesn't solve enough issues. But all this time, I
treated matter of HTTP API exactly as "there're different ways to do
it, and one way shouldn't be much worse than another". But I'm afraid,
we reached a point when design of the HTTP API affects the design of
IP stack, and not in the very right direction. I suggest we pause and
try to rework it (HTTP API), even if from the basics, and using the
ground requirements like "relying on more buffering than absolute
bare minimum is a bad thing".


I'm also pretty much sad to come out with such suggestion, because you
have a pretty cool and useful app on your hands, and I just
some useless demo which barely started to work. But I explained the
problem with it - your app works, because it requires more resources
than needed, and thus it won't work so well on other hardware. And as
experience shows, every app so far has various problems, so by taking
time to rebase it on a more generic, simpler API, we can solve many
yet-to-be-exposed problems.


Thanks for your consideration.

[]

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


Re: Setup In Eclipse

Piotr Mienkowski
 

Hi JC,

On 25.10.2017 16:05, JC wrote:
I'm running Ubuntu 16.04 LTS in a Virtualbox VM.  I'm using Eclipse
Oxygen CDT for development and openOCD for debugging.  My target is an
NRF52,  At this moment, I can build the code and successfully initiate
debugging through eclipse.  

Here's what I see that I find strange:
1. Only one thread in the debug window.
2. Unpredictable result when stepping through the code.
3. Callstack makes zero sense.
4. Breakpoints don't seem to work correctly outside of application code.

I have to think I've not configured something correctly about my debug
environment.  Does anyone have any ideas?
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'm only reminding it since you didn't mention it in your post.
Not setting this option would be a typical cause for 2. and 4. Though in
case of 4. the behavior shouldn't differ between application and system
code. Not enabling CONFIG_DEBUG may also influence 3. Though the changes
shouldn't be dramatic, callstack should still make sense.

To have thread aware debugging you need to use OpenOCD from the latest
Zephyr SDK version. The stock OpenOCD comes without Zephyr extensions. I
actually have not tried it out yet and am not sure how well it works. I
think you will also need to set
CONFIG_OPENOCD_SUPPORT=y
Maybe someone else knows more.

Let us know how it worked and especially if you were successful enabling
thread aware debugging.

Regards,
Piotr


Re: BSD Sockets in mainline, and how that affects design decisions for the rest of IP stack (e.g. send MTU handling)

Tomasz Bursztyka
 

On 26/10/2017 14:37, Paul Sokolovsky wrote:
Hello Tomasz,

Thanks for responding and bringing up this discussion - it got
backlogged (so I'm doing homework on it in the background).

On Wed, 25 Oct 2017 18:13:18 +0200
Tomasz Bursztyka <tomasz.bursztyka@...> wrote:

Hi guys,

It was
posted as https://github.com/zephyrproject-rtos/zephyr/pull/119 .
Again, at that time, there was no consensus about way to solve it,
so it was implemented only for BSD Sockets API.

Much later,
https://github.com/zephyrproject-rtos/zephyr/pull/1330 was posted.
It works in following way: it allows an application to create an
oversized packet
(...)

There're many more
details than presented above, and the devil is definitely in
details, there's no absolutely "right" solution, it's a compromise.
I hope that Jukka and Tomasz, who are proponents of the second
(GH-1330) approach can correct me on the benefits of it.
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.
That sounds fresh, thanks ;-)

Let me
explain why:

First, let's not rush on this MTU handling just yet, though it is
much needed. We first need this:

-> https://github.com/zephyrproject-rtos/zephyr/issues/3283
Ack, that's good thing to do...

it will simplify a lot how packet are allocated. I haven't touched
MTU stuff since I did the net_pkt move because of this feature we'll
use.

I foresee a lot of possible improvements with this issue resolved:
certainly MTU handling, better memory management than current frag
model, but also better response against low memory
... but I don't see how it directly relates to the topic of this RFC,
which is selecting paradigm to deal with the case that we have finite
units of buffering, and how that should affect user-facing API design.
I was indeed only responding on MTU handling (as both PR do in a way).

There're definitely a lot to improve and optimize in our IP stack, and
the issue you mention is one of them. But it's going to be just that -
the optimization. But what we discuss is how to structure API:

1. Accept that the amount of buffering we can do is very finite, and
make applications be aware of that and ready to handle - the POSIX
inspired way. If done that way, we can just use a network packet as
a buffering unit and further optimize that handling.

2. Keep pretending that we can buffer mini-infinite amount of data.
It's mini-infinite because we still won't be able to buffer more than
RAM allows (actually, more than TX slab allows), and that's still too
little, so won't work for "real" amounts of data, which still will need
to fall back to p.1 handling above. Packet buffers are still used for
buffering, but looking at Jukka's implementation, they are used as
generic data buffers, and require pretty heavy post-processing - first
splitting oversized buffers into packet-friendly sizes (#1330),
stuffing protocol headers in front (we already do that, and that's
pretty awful and not zero-copy at all), etc. Again, all that happens
with no free memory available - it was already spent to buffer that
"mini-infinite" amount of data.


You also say that you don't like any of these choices. Well, there're
only so many ways to do. What do you have in mind?
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 seems.

On socket you have one opaque type to access the network and read/write on it.
The data buffer is then split in two: user has to manage his raw data in his own buffers,
(and take to/from it when receiving/sending) where the actual network data
(encapsulated raw data) is handled behind by socket on send/recv.
Both sending/receiving logic is easy, as long as you have enough memory for user's buffer.

In zephyr, both are directly found at once in net_pkt. The user does not have
to create its own buffers: he just has to pick from net slabs, populate it, finalize and done.

From a memory usage point of view, the later is easier and more efficient
as long as the net stack is doing it well, obviously, like properly handling MTU, etc...
but mostly on _tx_ only. On rx, as the data is scattered around buffer fragments, it requires
the user do add logic on his side to parse the received data (the encapsulated one).
Thus the net_frag_read() and derived functions. Which can be a bit complicated to grasp I guess.

About the "mini-inifinite", that's up to the user to handle net_pkt_append() returned amount.
A bit like send() in socket. Though the difference here if of course data still needs to be send.


As I did change net_nbuf to net_pkt, my point doing it was exactly that net_pkt should represent
one unique IP packet. So from that, I would say net_pkt_append() must not go over MTU.

Note however that this MTU can be either HW MTU or IP based one.
For instance on 15.4/6lo you don't want to limit IPv6 packets on HW MTU, but you use this
IPv6 (minimum) size of 1280 bytes which in turn is fragmented through 6lo to fit in as many
as necessary 15.4 frames. But if not using 6lo, it would need to use HW MTU only.
(There is a possibility to handle bigger IPv6 packets through IPv6 fragmentation, I can't remember
is that generates as many net_pkt as necessary, or if it does all on one which would go against
net_pkt usage)

As I am not working against user API, I don't have good overview on how it's supposed to work.

Well, maybe my blabbering can help you guys to decide which way should be the best.

Tomasz


New Defects reported by Coverity Scan for Zephyr

Nashif, Anas
 



Regards,
Anas Nashif 

Begin forwarded message:

From: <scan-admin@...>
Date: October 26, 2017 at 14:29:08 GMT+2
To: <anas.nashif@...>
Subject: New Defects reported by Coverity Scan for Zephyr


Hi,

Please find the latest report on new defect(s) introduced to Zephyr found with Coverity Scan.

17 new defect(s) introduced to Zephyr found with Coverity Scan.
6 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan.

New defect(s) Reported-by: Coverity Scan
Showing 17 of 17 defect(s)


** CID 178249:  Parse warnings  (PARSE_ERROR)
/samples/mpu/mem_domain_apis_test/src/main.c: 44 in ()


________________________________________________________________________________________________________
*** CID 178249:  Parse warnings  (PARSE_ERROR)
/samples/mpu/mem_domain_apis_test/src/main.c: 44 in ()
38         &app0_parts0,
39         &app0_parts1
40     };
41     
42     K_MEM_PARTITION_DEFINE(app1_parts0, app1_buf, sizeof(app1_buf),
43                    K_MEM_PARTITION_P_RW_U_RW);
   CID 178249:  Parse warnings  (PARSE_ERROR)
   expression must be an integral constant expression
44     K_MEM_PARTITION_DEFINE(app1_parts1, app0_buf, sizeof(app0_buf),
45                    K_MEM_PARTITION_P_RW_U_RO);
46     
47     struct k_mem_partition *app1_parts[] = {
48         &app1_parts0,
49         &app1_parts1

** CID 178248:  Null pointer dereferences  (REVERSE_INULL)
/subsys/net/lib/coap/coap.c: 1233 in coap_packet_get_payload()


________________________________________________________________________________________________________
*** CID 178248:  Null pointer dereferences  (REVERSE_INULL)
/subsys/net/lib/coap/coap.c: 1233 in coap_packet_get_payload()
1227         u16_t coap_pkt_len;
1228     
1229         frag = NULL;
1230         *offset = 0xffff;
1231         *len = 0;
1232     
   CID 178248:  Null pointer dereferences  (REVERSE_INULL)
   Null-checking "offset" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
1233         if (!cpkt || !cpkt->pkt || !offset || !len) {
1234             return NULL;
1235         }
1236     
1237         coap_pkt_len = get_coap_packet_len(cpkt->pkt);
1238     

** CID 178247:  Error handling issues  (CHECKED_RETURN)
/subsys/net/lib/sockets/sockets.c: 111 in zsock_accepted_cb()


________________________________________________________________________________________________________
*** CID 178247:  Error handling issues  (CHECKED_RETURN)
/subsys/net/lib/sockets/sockets.c: 111 in zsock_accepted_cb()
105     
106     static void zsock_accepted_cb(struct net_context *new_ctx,
107                       struct sockaddr *addr, socklen_t addrlen,
108                       int status, void *user_data) {
109         struct net_context *parent = user_data;
110     
   CID 178247:  Error handling issues  (CHECKED_RETURN)
   Calling "net_context_recv" without checking return value (as is done elsewhere 21 out of 26 times).
111         net_context_recv(new_ctx, zsock_received_cb, K_NO_WAIT, NULL);
112         k_fifo_init(&new_ctx->recv_q);
113     
114         NET_DBG("parent=%p, ctx=%p, st=%d", parent, new_ctx, status);
115     
116         k_fifo_put(&parent->accept_q, new_ctx);

** CID 178246:  Error handling issues  (CHECKED_RETURN)
/subsys/net/lib/app/client.c: 479 in _app_connected()


________________________________________________________________________________________________________
*** CID 178246:  Error handling issues  (CHECKED_RETURN)
/subsys/net/lib/app/client.c: 479 in _app_connected()
473     #if defined(CONFIG_NET_APP_TLS) || defined(CONFIG_NET_APP_DTLS)
474         if (ctx->is_tls) {
475             k_sem_give(&ctx->client.connect_wait);
476         }
477     #endif
478     
   CID 178246:  Error handling issues  (CHECKED_RETURN)
   Calling "net_context_recv" without checking return value (as is done elsewhere 21 out of 26 times).
479         net_context_recv(net_ctx, ctx->recv_cb, K_NO_WAIT, ctx);
480     
481     #if defined(CONFIG_NET_APP_TLS) || defined(CONFIG_NET_APP_DTLS)
482         if (ctx->is_tls) {
483             /* If we have TLS connection, the connect cb is called
484              * after TLS handshakes are done.

** CID 178245:  Parse warnings  (PARSE_ERROR)
/samples/mpu/mem_domain_apis_test/src/main.c: 42 in ()


________________________________________________________________________________________________________
*** CID 178245:  Parse warnings  (PARSE_ERROR)
/samples/mpu/mem_domain_apis_test/src/main.c: 42 in ()
36     
37     struct k_mem_partition *app0_parts[] = {
38         &app0_parts0,
39         &app0_parts1
40     };
41     
   CID 178245:  Parse warnings  (PARSE_ERROR)
   expression must be an integral constant expression
42     K_MEM_PARTITION_DEFINE(app1_parts0, app1_buf, sizeof(app1_buf),
43                    K_MEM_PARTITION_P_RW_U_RW);
44     K_MEM_PARTITION_DEFINE(app1_parts1, app0_buf, sizeof(app0_buf),
45                    K_MEM_PARTITION_P_RW_U_RO);
46     
47     struct k_mem_partition *app1_parts[] = {

** CID 178244:  Error handling issues  (CHECKED_RETURN)
/subsys/net/lib/http/http_server.c: 800 in accept_cb()


________________________________________________________________________________________________________
*** CID 178244:  Error handling issues  (CHECKED_RETURN)
/subsys/net/lib/http/http_server.c: 800 in accept_cb()
794         }
795     
796         http_ctx->req.net_ctx = net_ctx;
797     
798         new_client(http_ctx, net_ctx, addr);
799     
   CID 178244:  Error handling issues  (CHECKED_RETURN)
   Calling "net_context_recv" without checking return value (as is done elsewhere 21 out of 26 times).
800         net_context_recv(net_ctx, http_ctx->recv_cb, K_NO_WAIT, http_ctx);
801     }
802     
803     static int set_net_ctx(struct http_server_ctx *http_ctx,
804                    struct net_context *ctx,
805                    struct sockaddr *addr,

** CID 178243:  Error handling issues  (CHECKED_RETURN)
/drivers/ethernet/eth_enc28j60.c: 88 in eth_enc28j60_read_reg()


________________________________________________________________________________________________________
*** CID 178243:  Error handling issues  (CHECKED_RETURN)
/drivers/ethernet/eth_enc28j60.c: 88 in eth_enc28j60_read_reg()
82             tx_size = 3;
83         }
84     
85         tx_buf[0] = ENC28J60_SPI_RCR | (reg_addr & 0xFF);
86         tx_buf[1] = 0x0;
87     
   CID 178243:  Error handling issues  (CHECKED_RETURN)
   Calling "spi_transceive" without checking return value (as is done elsewhere 20 out of 25 times).
88         spi_transceive(context->spi, tx_buf, tx_size, tx_buf, tx_size);
89     
90         *value = tx_buf[tx_size - 1];
91     
92         k_sem_give(&context->spi_sem);
93     }

** CID 178242:  Parse warnings  (PARSE_ERROR)
/samples/mpu/mem_domain_apis_test/src/main.c: 34 in ()


________________________________________________________________________________________________________
*** CID 178242:  Parse warnings  (PARSE_ERROR)
/samples/mpu/mem_domain_apis_test/src/main.c: 34 in ()
28     /* the start address of the MPU region needs to align with its size */
29     u8_t __aligned(32) app0_buf[32];
30     u8_t __aligned(32) app1_buf[32];
31     
32     K_MEM_PARTITION_DEFINE(app0_parts0, app0_buf, sizeof(app0_buf),
33                    K_MEM_PARTITION_P_RW_U_RW);
   CID 178242:  Parse warnings  (PARSE_ERROR)
   expression must be an integral constant expression
34     K_MEM_PARTITION_DEFINE(app0_parts1, app1_buf, sizeof(app1_buf),
35                    K_MEM_PARTITION_P_RW_U_RO);
36     
37     struct k_mem_partition *app0_parts[] = {
38         &app0_parts0,
39         &app0_parts1

** CID 178241:    (CHECKED_RETURN)
/drivers/ethernet/eth_enc28j60.c: 174 in eth_enc28j60_read_mem()
/drivers/ethernet/eth_enc28j60.c: 185 in eth_enc28j60_read_mem()


________________________________________________________________________________________________________
*** CID 178241:    (CHECKED_RETURN)
/drivers/ethernet/eth_enc28j60.c: 174 in eth_enc28j60_read_mem()
168     
169         k_sem_take(&context->spi_sem, K_FOREVER);
170     
171         for (int i = 0; i < num_segments;
172              ++i, data_buffer += MAX_BUFFER_LENGTH) {
173             context->mem_buf[0] = ENC28J60_SPI_RBM;
   CID 178241:    (CHECKED_RETURN)
   Calling "spi_transceive" without checking return value (as is done elsewhere 20 out of 25 times).
174             spi_transceive(context->spi,
175                        context->mem_buf, MAX_BUFFER_LENGTH + 1,
176                        context->mem_buf, MAX_BUFFER_LENGTH + 1);
177             if (data_buffer) {
178                 memcpy(data_buffer, context->mem_buf + 1,
179                        MAX_BUFFER_LENGTH);
/drivers/ethernet/eth_enc28j60.c: 185 in eth_enc28j60_read_mem()
179                        MAX_BUFFER_LENGTH);
180             }
181         }
182     
183         if (num_remaining > 0) {
184             context->mem_buf[0] = ENC28J60_SPI_RBM;
   CID 178241:    (CHECKED_RETURN)
   Calling "spi_transceive" without checking return value (as is done elsewhere 20 out of 25 times).
185             spi_transceive(context->spi,
186                        context->mem_buf, num_remaining + 1,
187                        context->mem_buf, num_remaining + 1);
188             if (data_buffer) {
189                 memcpy(data_buffer, context->mem_buf + 1,
190                        num_remaining);

** CID 178240:  Error handling issues  (CHECKED_RETURN)
/drivers/ethernet/eth_enc28j60.c: 46 in eth_enc28j60_set_bank()


________________________________________________________________________________________________________
*** CID 178240:  Error handling issues  (CHECKED_RETURN)
/drivers/ethernet/eth_enc28j60.c: 46 in eth_enc28j60_set_bank()
40     
41         k_sem_take(&context->spi_sem, K_FOREVER);
42     
43         tx_buf[0] = ENC28J60_SPI_RCR | ENC28J60_REG_ECON1;
44         tx_buf[1] = 0x0;
45     
   CID 178240:  Error handling issues  (CHECKED_RETURN)
   Calling "spi_transceive" without checking return value (as is done elsewhere 20 out of 25 times).
46         spi_transceive(context->spi, tx_buf, 2, tx_buf, 2);
47     
48         tx_buf[0] = ENC28J60_SPI_WCR | ENC28J60_REG_ECON1;
49         tx_buf[1] = (tx_buf[1] & 0xFC) | ((reg_addr >> 8) & 0x0F);
50     
51         spi_write(context->spi, tx_buf, 2);

** CID 178239:    (FORWARD_NULL)
/tests/net/app/src/main.c: 192 in iface_setup()
/tests/net/app/src/main.c: 202 in iface_setup()


________________________________________________________________________________________________________
*** CID 178239:    (FORWARD_NULL)
/tests/net/app/src/main.c: 192 in iface_setup()
186             DBG("Cannot add IPv6 address %s\n",
187                    net_sprint_ipv6_addr(&my_addr1));
188             zassert_not_null(ifaddr, "addr1");
189         }
190     
191         /* For testing purposes we need to set the adddresses preferred */
   CID 178239:    (FORWARD_NULL)
   Dereferencing null pointer "ifaddr".
192         ifaddr->addr_state = NET_ADDR_PREFERRED;
193     
194         ifaddr = net_if_ipv6_addr_add(iface1, &ll_addr,
195                           NET_ADDR_MANUAL, 0);
196         if (!ifaddr) {
197             DBG("Cannot add IPv6 address %s\n",
/tests/net/app/src/main.c: 202 in iface_setup()
196         if (!ifaddr) {
197             DBG("Cannot add IPv6 address %s\n",
198                    net_sprint_ipv6_addr(&ll_addr));
199             zassert_not_null(ifaddr, "ll_addr");
200         }
201     
   CID 178239:    (FORWARD_NULL)
   Dereferencing null pointer "ifaddr".
202         ifaddr->addr_state = NET_ADDR_PREFERRED;
203     
204         net_ipv6_addr_create(&in6addr_mcast, 0xff02, 0, 0, 0, 0, 0, 0, 0x0001);
205     
206         maddr = net_if_ipv6_maddr_add(iface1, &in6addr_mcast);
207         if (!maddr) {

** CID 178238:  Parse warnings  (PARSE_ERROR)
/samples/mpu/mem_domain_apis_test/src/main.c: 32 in ()


________________________________________________________________________________________________________
*** CID 178238:  Parse warnings  (PARSE_ERROR)
/samples/mpu/mem_domain_apis_test/src/main.c: 32 in ()
26     struct k_mem_domain app_domain[2];
27     
28     /* the start address of the MPU region needs to align with its size */
29     u8_t __aligned(32) app0_buf[32];
30     u8_t __aligned(32) app1_buf[32];
31     
   CID 178238:  Parse warnings  (PARSE_ERROR)
   expression must be an integral constant expression
32     K_MEM_PARTITION_DEFINE(app0_parts0, app0_buf, sizeof(app0_buf),
33                    K_MEM_PARTITION_P_RW_U_RW);
34     K_MEM_PARTITION_DEFINE(app0_parts1, app1_buf, sizeof(app1_buf),
35                    K_MEM_PARTITION_P_RW_U_RO);
36     
37     struct k_mem_partition *app0_parts[] = {

** CID 178237:  Memory - corruptions  (OVERRUN)
/drivers/ieee802154/ieee802154_mcr20a.c: 218 in _mcr20a_write_burst()


________________________________________________________________________________________________________
*** CID 178237:  Memory - corruptions  (OVERRUN)
/drivers/ieee802154/ieee802154_mcr20a.c: 218 in _mcr20a_write_burst()
212             spi->cmd_buf[0] = MCR20A_REG_WRITE | addr;
213             memcpy(&spi->cmd_buf[1], data_buf, len);
214             len += 1;
215         } else {
216             spi->cmd_buf[0] = MCR20A_IAR_INDEX | MCR20A_REG_WRITE;
217             spi->cmd_buf[1] = addr | MCR20A_REG_WRITE;
   CID 178237:  Memory - corruptions  (OVERRUN)
   Overrunning buffer pointed to by "&spi->cmd_buf[2]" of 12 bytes by passing it to a function which accesses it at byte offset 12 using argument "len" (which evaluates to 11). [Note: The source code implementation of the function has been overridden by a builtin model.]
218             memcpy(&spi->cmd_buf[2], data_buf, len);
219             len += 2;
220         }
221     
222         spi_slave_select(spi->dev, spi->slave);
223         retval = (spi_write(spi->dev, spi->cmd_buf, len) == 0);

** CID 178236:  Memory - corruptions  (OVERRUN)
/drivers/ieee802154/ieee802154_mcr20a.c: 260 in _mcr20a_read_burst()


________________________________________________________________________________________________________
*** CID 178236:  Memory - corruptions  (OVERRUN)
/drivers/ieee802154/ieee802154_mcr20a.c: 260 in _mcr20a_read_burst()
254             return 0;
255         }
256     
257         if (dreg) {
258             memcpy(data_buf, &spi->cmd_buf[1], len - 1);
259         } else {
   CID 178236:  Memory - corruptions  (OVERRUN)
   Overrunning buffer pointed to by "&spi->cmd_buf[2]" of 12 bytes by passing it to a function which accesses it at byte offset 12 using argument "len - 2" (which evaluates to 11). [Note: The source code implementation of the function has been overridden by a builtin model.]
260             memcpy(data_buf, &spi->cmd_buf[2], len - 2);
261         }
262     
263         k_sem_give(&spi->spi_sem);
264     
265         return 1;

** CID 178235:  Null pointer dereferences  (REVERSE_INULL)
/subsys/net/lib/dns/mdns_responder.c: 241 in send_response()


________________________________________________________________________________________________________
*** CID 178235:  Null pointer dereferences  (REVERSE_INULL)
/subsys/net/lib/dns/mdns_responder.c: 241 in send_response()
235     
236         } else {
237             /* TODO: support also service PTRs */
238             return -EINVAL;
239         }
240     
   CID 178235:  Null pointer dereferences  (REVERSE_INULL)
   Null-checking "reply" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
241         if (!reply) {
242             return -ENOMEM;
243         }
244     
245         ret = net_context_sendto(reply, &dst, dst_len, NULL, K_NO_WAIT,
246                      NULL, NULL);

** CID 178234:  Null pointer dereferences  (REVERSE_INULL)
/subsys/net/lib/coap/coap.c: 1233 in coap_packet_get_payload()


________________________________________________________________________________________________________
*** CID 178234:  Null pointer dereferences  (REVERSE_INULL)
/subsys/net/lib/coap/coap.c: 1233 in coap_packet_get_payload()
1227         u16_t coap_pkt_len;
1228     
1229         frag = NULL;
1230         *offset = 0xffff;
1231         *len = 0;
1232     
   CID 178234:  Null pointer dereferences  (REVERSE_INULL)
   Null-checking "len" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
1233         if (!cpkt || !cpkt->pkt || !offset || !len) {
1234             return NULL;
1235         }
1236     
1237         coap_pkt_len = get_coap_packet_len(cpkt->pkt);
1238     

** CID 178233:  Null pointer dereferences  (REVERSE_INULL)
/samples/net/echo_client/src/tcp.c: 194 in compare_tcp_data()


________________________________________________________________________________________________________
*** CID 178233:  Null pointer dereferences  (REVERSE_INULL)
/samples/net/echo_client/src/tcp.c: 194 in compare_tcp_data()
188          * length is directly the fragment len.
189          */
190         len = frag->len - (ptr - frag->data);
191     
192         start = lorem_ipsum + received_len;
193     
   CID 178233:  Null pointer dereferences  (REVERSE_INULL)
   Null-checking "frag" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
194         while (frag) {
195             if (memcmp(ptr, start + pos, len)) {
196                 NET_DBG("Invalid data received");
197                 return false;
198             }
199     


________________________________________________________________________________________________________
To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V05UPxvVjWch-2Bd2MGckcRbO5jMuM3qcdgkQ-2B8GeSLDbY-2BGxhHXRVXXhN9J-2FGl-2FrBg-3D-3D_qb0Uj4AheYo18oR3ufs7U2EqDpE-2BCuzW5lXxy9dw9-2BCYGJAjGVBvdMSEIXid9MGVLnYaCxQWNCEO6x0llsKktGNllYqBFTSj2s3BUW8QUrdvl233u8LuFGWpOgSu2rc-2BvqdYiOVm0hPLHncFd4V-2F9JHMSM1BZTFpzNZeXoef3wWEMVzKSvGT6UGq3Ro61uQfOZk28XrY3pDBluqFe6LAeaHu5vYnVkhOARe-2BxPHSkKM-3D

To manage Coverity Scan email notifications for "anas.nashif@...", click https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V05UPxvVjWch-2Bd2MGckcRbVDbis712qZDP-2FA8y06Nq4QuJ4n4mXbeIpNhS8BGwxNLHj-2BTxeFwdI3SDDdsncH-2Bz9xw1m0wMt3vy-2F0hadYzJBea4I9eUVx23T6CU82-2BIxqn54S4Kugeb6uiTfRhIn290-3D_qb0Uj4AheYo18oR3ufs7U2EqDpE-2BCuzW5lXxy9dw9-2BCYGJAjGVBvdMSEIXid9MGVJ6piO1tzXPVgJVeRiqIumtvn4xp-2FsSSqAXdL4A3zXUPunFRRDa8MYZonXqSTke1mxlt6PHAxaGm6uFhYWiI7GnJ2TrKZIQU-2Bd3wMUQD-2FpCWVJwmYlOLvhtcJ2f-2BhdG03bLQdH57Of3UzdhGrU-2B4hZzPeOMladuanpRCD-2FHbkM-2Bs-3D


Re: BSD Sockets in mainline, and how that affects design decisions for the rest of IP stack (e.g. send MTU handling)

Paul Sokolovsky
 

Hello Tomasz,

Thanks for responding and bringing up this discussion - it got
backlogged (so I'm doing homework on it in the background).

On Wed, 25 Oct 2017 18:13:18 +0200
Tomasz Bursztyka <tomasz.bursztyka@...> wrote:

Hi guys,

It was
posted as https://github.com/zephyrproject-rtos/zephyr/pull/119 .
Again, at that time, there was no consensus about way to solve it,
so it was implemented only for BSD Sockets API.

Much later,
https://github.com/zephyrproject-rtos/zephyr/pull/1330 was posted.
It works in following way: it allows an application to create an
oversized packet
(...)

There're many more
details than presented above, and the devil is definitely in
details, there's no absolutely "right" solution, it's a compromise.
I hope that Jukka and Tomasz, who are proponents of the second
(GH-1330) approach can correct me on the benefits of it.
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.
That sounds fresh, thanks ;-)

Let me
explain why:

First, let's not rush on this MTU handling just yet, though it is
much needed. We first need this:

-> https://github.com/zephyrproject-rtos/zephyr/issues/3283
Ack, that's good thing to do...


it will simplify a lot how packet are allocated. I haven't touched
MTU stuff since I did the net_pkt move because of this feature we'll
use.

I foresee a lot of possible improvements with this issue resolved:
certainly MTU handling, better memory management than current frag
model, but also better response against low memory
... but I don't see how it directly relates to the topic of this RFC,
which is selecting paradigm to deal with the case that we have finite
units of buffering, and how that should affect user-facing API design.

There're definitely a lot to improve and optimize in our IP stack, and
the issue you mention is one of them. But it's going to be just that -
the optimization. But what we discuss is how to structure API:

1. Accept that the amount of buffering we can do is very finite, and
make applications be aware of that and ready to handle - the POSIX
inspired way. If done that way, we can just use a network packet as
a buffering unit and further optimize that handling.

2. Keep pretending that we can buffer mini-infinite amount of data.
It's mini-infinite because we still won't be able to buffer more than
RAM allows (actually, more than TX slab allows), and that's still too
little, so won't work for "real" amounts of data, which still will need
to fall back to p.1 handling above. Packet buffers are still used for
buffering, but looking at Jukka's implementation, they are used as
generic data buffers, and require pretty heavy post-processing - first
splitting oversized buffers into packet-friendly sizes (#1330),
stuffing protocol headers in front (we already do that, and that's
pretty awful and not zero-copy at all), etc. Again, all that happens
with no free memory available - it was already spent to buffer that
"mini-infinite" amount of data.


You also say that you don't like any of these choices. Well, there're
only so many ways to do. What do you have in mind?


(we could after
all send asap a tinier than MTU TCP segment if there was only a small
amount of memory available, and continue with the rest etc...).
That's how sockets work already - they ask user's data to be added to a
packets, and if less is added, it passes that info back to app (for it
to retry). The whole talk is about making that available to the native
API too (governed also by other constraints like MTU size).


Tomasz


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


Bluetooth Address Type - Fixed (public)

Jie Zhou <zhoujie@...>
 

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 resolvable private addresses. Is there a way for me to change the address type to public (i.e. fixed) for my curie board? I see it in the API that there is cases for public bluetooth address. However, I just can't seem to find how to change the addr-type to public. I see the #define BT_ADDRLE_PUBLIC 0x00 in  include/bluetooth/hci.h, but don't know how to implement it. Does anyone know how to do this?

Thanks,
Jie



Re: Problems with static variables and GNU map files

Paul Sokolovsky
 

Hello Marti,

On Wed, 25 Oct 2017 23:56:47 -0400
Marti Bolivar <marti.bolivar@...> wrote:

Why not just #define static SOMETHING_ELSE as needed?
Because "static" has different semantics in different contexts. For
example, we don't want to touch "static inline" functions. Though, based
on the number of changes, I guess it would be easier to add a #define
for static inline functions than for everything else...


On 19 October 2017 at 15:08, Paul Sokolovsky
<paul.sokolovsky@...> wrote:

Hello,

A usecase (one of many): I want to see what network interface
structures go into my Zephyr binary. Of course, I look at the
linker map file, and ... see nothing:

net_if 0x000000000041fa80 0x2a0 load address
0x00000000000150bc
0x000000000041fa80 __net_if_start = .
*(.net_if.*)
.net_if.data 0x000000000041fa80 0x2a0 drivers/built-in.o
*(SORT(.net_if.*))
0x000000000041fd20 __net_if_end = .

That's because netif structures are defined as static, and GNU
linker takes that as an incentive to conceal them from the map
file. This issue was reported few years ago as
https://sourceware.org/bugzilla/show_bug.cgi?id=16566 with no
feedback, so apparently nothing is going to happen.


Proposal:

Let's have

#define STATIC static

And use STATIC everywhere a static var is defined. This way, it can
be redefined in one place to produce a relevant map file (let's
also have unique names for all variables, yeah).


--
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
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


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


Re: Problems with static variables and GNU map files

Marti Bolivar <marti.bolivar@...>
 

Why not just #define static SOMETHING_ELSE as needed?

On 19 October 2017 at 15:08, Paul Sokolovsky <paul.sokolovsky@...> wrote:
Hello,

A usecase (one of many): I want to see what network interface structures
go into my Zephyr binary. Of course, I look at the linker map file,
and ... see nothing:

net_if          0x000000000041fa80      0x2a0 load address 0x00000000000150bc
                0x000000000041fa80                __net_if_start = .
 *(.net_if.*)
 .net_if.data   0x000000000041fa80      0x2a0 drivers/built-in.o
 *(SORT(.net_if.*))
                0x000000000041fd20                __net_if_end = .

That's because netif structures are defined as static, and GNU linker
takes that as an incentive to conceal them from the map file. This
issue was reported few years ago as
https://sourceware.org/bugzilla/show_bug.cgi?id=16566 with no
feedback, so apparently nothing is going to happen.


Proposal:

Let's have

#define STATIC static

And use STATIC everywhere a static var is defined. This way, it can be
redefined in one place to produce a relevant map file (let's also have
unique names for all variables, yeah).


--
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
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: BSD Sockets in mainline, and how that affects design decisions for the rest of IP stack (e.g. send MTU handling)

Tomasz Bursztyka
 

Hi guys,

It was
posted as https://github.com/zephyrproject-rtos/zephyr/pull/119 . Again,
at that time, there was no consensus about way to solve it, so it was
implemented only for BSD Sockets API.

Much later,
https://github.com/zephyrproject-rtos/zephyr/pull/1330 was posted. It
works in following way: it allows an application to create an
oversized packet
(...)

There're many more
details than presented above, and the devil is definitely in details,
there's no absolutely "right" solution, it's a compromise. I hope that
Jukka and Tomasz, who are proponents of the second (GH-1330) approach
can correct me on the benefits of it.
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 not rush on this MTU handling just yet, though it is much needed.
We first need this:

-> https://github.com/zephyrproject-rtos/zephyr/issues/3283

it will simplify a lot how packet are allocated. I haven't touched MTU stuff since
I did the net_pkt move because of this feature we'll use.

I foresee a lot of possible improvements with this issue resolved: certainly MTU handling, better memory
management than current frag model, but also better response against low memory (we could after all
send asap a tinier than MTU TCP segment if there was only a small amount of memory available,
and continue with the rest etc...).

Tomasz


Setup In Eclipse

JC <jordansspamfilter@...>
 

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.  My target is an NRF52,  At this moment, I can build the code and successfully initiate debugging through eclipse.  

Here's what I see that I find strange:
1. Only one thread in the debug window.
2. Unpredictable result when stepping through the code.
3. Callstack makes zero sense.
4. Breakpoints don't seem to work correctly outside of application code.

I have to think I've not configured something correctly about my debug environment.  Does anyone have any ideas?

-JC


Re: Reaction to hard fault - how to reset instead of hang

Boie, Andrew P
 

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

-----Original Message-----
From: zephyr-devel-bounces@... [mailto:zephyr-devel-
bounces@...] On Behalf Of Laczen JMS
Sent: Monday, October 23, 2017 1:37 AM
To: zephyr-devel@...
Subject: [Zephyr-devel] Reaction to hard fault - how to reset instead of hang

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 this by increasing the stack size but I am
uncertain that the new stack size will be big enough to handle whatever data is
send to the node.

Is it possible to make the device reset instead of hang ? Is there a configuration
option to set what the device needs to do in case of a hard fault ?

Kind regards,

Jehudi
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: bluetooth mesh on nrf51822-16kb tinycrypt-ecc

laczenJMS
 

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 concept of memory slabs/memory pools
to allocate and free the respective states ? This might be easier then
to overlay.

Kind regards,

Jehudi

2017-10-20 16:51 GMT+02:00 Johan Hedberg <johan.hedberg@...>:

Hi Jehudi,

On Fri, Oct 20, 2017, Laczen JMS wrote:
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 precalculate the
keys and to include them instead of generating on the device ?
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 when you receive the remote
public key. That's not something that you can do in advance and it also
consumes roughly the same amount of stack with TinyCrypt.

There could however be other places where there's potential to slim
things down a bit further. One such place is the provisioning state in
prov.c. A node is either provisioned or unprovisioned, so the network
state and the provisioning state never need to coexist in memory. This
means we could save some memory if we find a way to overlay them (using
a union or some linker magic). This task is actually listed in the
subsys/bluetooth/host/mesh/TODO file.

Johan


Reaction to hard fault - how to reset instead of hang

laczenJMS
 

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 this by
increasing the stack size but I am uncertain that the new stack size
will be big enough to handle whatever data is send to the node.

Is it possible to make the device reset instead of hang ? Is there a
configuration option to set what the device needs to do in case of a
hard fault ?

Kind regards,

Jehudi


Re: CI fails for pull request on arm branch

Kumar Gala
 

On Oct 23, 2017, at 9:45 AM, Wagenknecht, Daniel <Daniel.Wagenknecht@...> wrote:

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
Sanitycheck / frdm_k64f:samples/mpu/mem_domain_apis_test/test

While I was only working on stm32 i2c drivers.

Please have a look into this problem.
Thanks!
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 if you can rebase your branch again, that should hopefully address the issue.

- k


CI fails for pull request on arm branch

Daniel Wagenknecht
 

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

 Sanitycheck / frdm_k64f:samples/mpu/mem_domain_apis_test/test 

While I was only working on stm32 i2c drivers.

 

Please have a look into this problem.

Thanks!

 

Daniel Wagenknecht

Softwaredeveloper, R&D

 

 

CLAGE GmbH

Pirolweg 1-5

21337 Lüneburg | Germany

 

Fon: +49 4131 8901-7906

Fax: +49 4131 83200

E-Mail: daniel.wagenknecht@...

www.clage.de

 

 


System clock k_uptime_get() not working

Yie
 

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 k_uptime_get() doesn't seem to be working for me as it always returns 0 whereas k_cycle_get_32() always return a value.

I am running this on the qemu_cortex_m3 board.

Any help would be much appreciated. Thanks.


Re: bluetooth mesh on nrf51822-16kb tinycrypt-ecc

Johan Hedberg
 

Hi Jehudi,

On Fri, Oct 20, 2017, Laczen JMS wrote:
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 precalculate the
keys and to include them instead of generating on the device ?
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 when you receive the remote
public key. That's not something that you can do in advance and it also
consumes roughly the same amount of stack with TinyCrypt.

There could however be other places where there's potential to slim
things down a bit further. One such place is the provisioning state in
prov.c. A node is either provisioned or unprovisioned, so the network
state and the provisioning state never need to coexist in memory. This
means we could save some memory if we find a way to overlay them (using
a union or some linker magic). This task is actually listed in the
subsys/bluetooth/host/mesh/TODO file.

Johan


bluetooth mesh on nrf51822-16kb tinycrypt-ecc

laczenJMS
 

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 precalculate the
keys and to include them instead of generating on the device ?

Kind regards,

Jehudi


Re: Current time in Zephyr using ARM Qemu board

aska.wu
 

Hi,

You probably can try this PR https://github.com/zephyrproject-rtos/zephyr/pull/1502 if you want to manage system time by gettimeofday()/settimeofday(). Note that It's still under review and only works for cortex-m boards for the time being.

Aska Wu


On Wed, 18 Oct 2017 at 22:26 Hui Yie Teh <hteh703@...> wrote:
Hi,

I am trying to get the current time using the following:

time_t rawtime; 
struct tm *info;
time( &rawtime );
info = localtime( &rawtime );
printf("Current local time and date: %s", asctime(info));

However, this is giving me an error on Qemu:

qemu: fatal: Trying to execute code outside RAM or ROM at 0x05252ff4

Is there a reason for this? Also, is there another way to get the current time of the system in Zephyr?

Any help would be much appreciated.

Cheers,
Yie
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel

5221 - 5240 of 8778