1. users@lists.zephyrproject.org
  2. Messages
   Date   
Re: 96boards Nitrogen

Steve Brown
 

Ricardo,

On Thu, 2017-09-14 at 14:49 -0300, Ricardo Salveti de Araujo wrote:
On Thu, Sep 14, 2017 at 5:53 AM, Steve Brown <sbrown@cortland.com>
wrote:
Richardo,

On Thu, 2017-09-14 at 01:47 -0300, Ricardo Salveti de Araujo wrote:
On Wed, Sep 13, 2017 at 6:37 PM, Steve Brown <sbrown@cortland.com
wrote:
Has anyone had success with samples/bluetooth/beacon on this
device?

Even the nitrogen_beacon.hex file from 96boards.org won't
transmit.
The
console messages are as expected, but nothing on the air. Same
results
on two recent boards from Seeed.

The same .hex file flashed to a redbear ble nano2 does
transmit.
There
is no console output because a different uart is used, but the
beacons
are on the air.

The designation on the nRF52 is N52832/QFAAB0/1616BD. I looked
at
the
errata and didn't see anything obvious.
It is supposed to just work, without any additional changes, so
wonder
if this could be hw issues.

Can you check the hw revision for your Nitrogens (should be
either
v0.9, v1.0 or v1.1)?

I got several from v0.9 and v1.1 and they are all functional.
Just
tested the beacon sample from Zephyr 1.9 and it is working just
fine.

Cheers,
The boards are:
 v1.0 build date 09/19/2016
 v1.1 build date 02/16/2017

The nitrogen build uses pyOCD to flash the device. This works as
expected.
By works as expected you mean including the BT radio?

However, copying a .bin file to /media/$USER/MBED gives the
following error:
"The interface firmware FAILED to parse the hex file" in FAIL.TXT

If I copy a .hex file to the MBED disk, it isn't processed and the
file
remains in the folder.

Both boards exhibit identical behavior.
Yeah, this looks like an issue in the firmware flashed in LPC11U35.
Talking with Seeeds, it seems they originally flashed
https://github.com/xiongyihui/CMSIS-DAP/tree/arch_ble, but I didn't
yet investigate to see why this is currently broken. Maybe it assumes
the user will flash softdevice compatible fw by default, not sure.

Cheers,
Thanks for the info on the CMSIS firmware. I'm not using it, but
thought that it might be connected to my radio problem. From your
comments, it's not.

pyocd-flashtool flashes the device with the expected console output.
The radio doesn't work.

I've ordered another 2 from Digikey and will see how they behave. When
I ordered them from Seeed, I never thought to check if they were
available locally.

I wonder if they got zapped during customs inspection. They probably x-
ray the small boxes. I hope the customs inspector wears a film badge.
If anybody from Nordic is listening, maybe they have an opinion.

Steve
Re: 96boards Nitrogen

Ricardo Salveti de Araujo <ricardo.salveti@...>
 

On Thu, Sep 14, 2017 at 5:53 AM, Steve Brown <sbrown@cortland.com> wrote:
Richardo,

On Thu, 2017-09-14 at 01:47 -0300, Ricardo Salveti de Araujo wrote:
On Wed, Sep 13, 2017 at 6:37 PM, Steve Brown <sbrown@cortland.com>
wrote:
Has anyone had success with samples/bluetooth/beacon on this
device?

Even the nitrogen_beacon.hex file from 96boards.org won't transmit.
The
console messages are as expected, but nothing on the air. Same
results
on two recent boards from Seeed.

The same .hex file flashed to a redbear ble nano2 does transmit.
There
is no console output because a different uart is used, but the
beacons
are on the air.

The designation on the nRF52 is N52832/QFAAB0/1616BD. I looked at
the
errata and didn't see anything obvious.
It is supposed to just work, without any additional changes, so
wonder
if this could be hw issues.

Can you check the hw revision for your Nitrogens (should be either
v0.9, v1.0 or v1.1)?

I got several from v0.9 and v1.1 and they are all functional. Just
tested the beacon sample from Zephyr 1.9 and it is working just fine.

Cheers,
The boards are:
v1.0 build date 09/19/2016
v1.1 build date 02/16/2017

The nitrogen build uses pyOCD to flash the device. This works as
expected.
By works as expected you mean including the BT radio?

However, copying a .bin file to /media/$USER/MBED gives the
following error:
"The interface firmware FAILED to parse the hex file" in FAIL.TXT

If I copy a .hex file to the MBED disk, it isn't processed and the file
remains in the folder.

Both boards exhibit identical behavior.
Yeah, this looks like an issue in the firmware flashed in LPC11U35.
Talking with Seeeds, it seems they originally flashed
https://github.com/xiongyihui/CMSIS-DAP/tree/arch_ble, but I didn't
yet investigate to see why this is currently broken. Maybe it assumes
the user will flash softdevice compatible fw by default, not sure.

Cheers,
--
Ricardo Salveti
Re: 96boards Nitrogen

Steve Brown
 

Richardo,

On Thu, 2017-09-14 at 01:47 -0300, Ricardo Salveti de Araujo wrote:
On Wed, Sep 13, 2017 at 6:37 PM, Steve Brown <sbrown@cortland.com>
wrote:
Has anyone had success with samples/bluetooth/beacon on this
device?

Even the nitrogen_beacon.hex file from 96boards.org won't transmit.
The
console messages are as expected, but nothing on the air. Same
results
on two recent boards from Seeed.

The same .hex file flashed to a redbear ble nano2 does transmit.
There
is no console output because a different uart is used, but the
beacons
are on the air.

The designation on the nRF52 is N52832/QFAAB0/1616BD. I looked at
the
errata and didn't see anything obvious.
It is supposed to just work, without any additional changes, so
wonder
if this could be hw issues.

Can you check the hw revision for your Nitrogens (should be either
v0.9, v1.0 or v1.1)?

I got several from v0.9 and v1.1 and they are all functional. Just
tested the beacon sample from Zephyr 1.9 and it is working just fine.

Cheers,
The boards are:
v1.0 build date 09/19/2016
v1.1 build date 02/16/2017

The nitrogen build uses pyOCD to flash the device. This works as
expected. However, copying a .bin file to /media/$USER/MBED gives the
following error:
"The interface firmware FAILED to parse the hex file" in FAIL.TXT

If I copy a .hex file to the MBED disk, it isn't processed and the file
remains in the folder.

Both boards exhibit identical behavior.

By comparison, copying either a .bin or .hex to the CMSIS disk on my
blenano2 works as expected.

I agree it looks like a hardware problem, but on two different rev
boards?

Is the drag/drop CMSIS interface known to work?

Thanks,

Steve
Re: TCP assert error logs

Vakul Garg <vakul.garg@...>
 

Hi Paul

-----Original Message-----
From: Paul Sokolovsky [mailto:paul.sokolovsky@linaro.org]
Sent: Wednesday, September 13, 2017 4:51 PM
To: Vakul Garg <vakul.garg@nxp.com>
Cc: zephyr-users@lists.zephyrproject.org
Subject: Re: [Zephyr-users] TCP assert error logs

On Wed, 13 Sep 2017 08:50:02 +0000
Vakul Garg <vakul.garg@nxp.com> wrote:

UDP loopback works and I can make progress with it for now.

(Ultimately, I need to move to some non-networking IPC such as mailbox
or pipe. The problem I face with that now is that I cannot multiplex
these zephyr IPC in POSIX poll() along with socket
descriptors.)
Yes, POSIX bits is Zephyr are very initial and very bare so far - a bit of threads
and a bit of sockets support. There're neither full-featured poll()
implementation, nor fd's (file descriptors), nor other POSIX IPC.
I used TCP/UDP POSIX sockets between two local apps just because I thought I can't multiplex a
local IPC method such as mailbox/pipe with network sockets connected to a remote endpoint.

If I change my code to use net_context apis for remote networking and use mailbox/pipe between local apps,
will I be able to multiplex net_contexts with mailbox/pipes using k_poll mechanism?


But there's definitely desire to extend POSIX support in Zephyr, so any
feedback is appreciated. (You may also want to route this feedback via
Maureen Helm, who's both on Zephyr and Linaro LITE TSCs, so with her input,
specific things may get planned and prioritized.)


Thanks & Regards

Vakul
[]

--
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: 96boards Nitrogen

Ricardo Salveti de Araujo <ricardo.salveti@...>
 

On Wed, Sep 13, 2017 at 6:37 PM, Steve Brown <sbrown@cortland.com> wrote:
Has anyone had success with samples/bluetooth/beacon on this device?

Even the nitrogen_beacon.hex file from 96boards.org won't transmit. The
console messages are as expected, but nothing on the air. Same results
on two recent boards from Seeed.

The same .hex file flashed to a redbear ble nano2 does transmit. There
is no console output because a different uart is used, but the beacons
are on the air.

The designation on the nRF52 is N52832/QFAAB0/1616BD. I looked at the
errata and didn't see anything obvious.
It is supposed to just work, without any additional changes, so wonder
if this could be hw issues.

Can you check the hw revision for your Nitrogens (should be either
v0.9, v1.0 or v1.1)?

I got several from v0.9 and v1.1 and they are all functional. Just
tested the beacon sample from Zephyr 1.9 and it is working just fine.

Cheers,
--
Ricardo Salveti
Re: 96boards Nitrogen

eden candelas <e.candelas@...>
 

Hello, I did modified the example to work as iBeacon ( the version on the example is for an eddystone). Basically you have to update the ad[] struct with the byte array required for the iBeacon spec.

Attached to this mail you will find the main.c that I have been using to test that functionality.

Regards.



Edén Candelas
cel. +52-(81)-1729-2117


On Wed, Sep 13, 2017 at 4:37 PM, Steve Brown <sbrown@...> wrote:
Has anyone had success with samples/bluetooth/beacon on this device?

Even the nitrogen_beacon.hex file from 96boards.org won't transmit. The
console messages are as expected, but nothing on the air. Same results
on two recent boards from Seeed.

The same .hex file flashed to a redbear ble nano2 does transmit. There
is no console output because a different uart is used, but the beacons
are on the air.

The designation on the nRF52 is N52832/QFAAB0/1616BD. I looked at the
errata and didn't see anything obvious.

I'm waiting for a reply from Seeed as to what they use to test the ble
functionality of the devices before they ship.

As a last resort, I'll try Nordic's SDK and see if I get the same
results.

Thanks,

Steve

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

?
main.c

96boards Nitrogen

Steve Brown
 

Has anyone had success with samples/bluetooth/beacon on this device?

Even the nitrogen_beacon.hex file from 96boards.org won't transmit. The
console messages are as expected, but nothing on the air. Same results
on two recent boards from Seeed.

The same .hex file flashed to a redbear ble nano2 does transmit. There
is no console output because a different uart is used, but the beacons
are on the air.

The designation on the nRF52 is N52832/QFAAB0/1616BD. I looked at the
errata and didn't see anything obvious.

I'm waiting for a reply from Seeed as to what they use to test the ble
functionality of the devices before they ship.

As a last resort, I'll try Nordic's SDK and see if I get the same
results.

Thanks,

Steve
Re: UDP recvfrom

Paul Sokolovsky
 

On Wed, 13 Sep 2017 08:58:16 +0000
Vakul Garg <vakul.garg@nxp.com> wrote:

Hi

I am using UDP sockets (posix flavor) in my app.
I need to determine the incoming UDP datagram's source IP address and
port. For this, typically recvfrom() is used.

Since this call is not available, what are my options?
Indeed, it's not yet implemented. Initial patch was posted:
https://github.com/zephyrproject-rtos/zephyr/pull/1055 , but it's still
in review and needs some refactors. You can try if it applies to the
current tree and can get you going in the meantime.

Anticipating a further question, getaddrinfo() is also not yet
available, I hope to post a patch for it today-tomorrow.


Can someone please advise?

Regards,
Vakul


--
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: TCP assert error logs

Paul Sokolovsky
 

On Wed, 13 Sep 2017 08:50:02 +0000
Vakul Garg <vakul.garg@nxp.com> wrote:

UDP loopback works and I can make progress with it for now.

(Ultimately, I need to move to some non-networking IPC such as
mailbox or pipe. The problem I face with that now is that I cannot
multiplex these zephyr IPC in POSIX poll() along with socket
descriptors.)
Yes, POSIX bits is Zephyr are very initial and very bare so far - a bit
of threads and a bit of sockets support. There're neither
full-featured poll() implementation, nor fd's (file descriptors), nor
other POSIX IPC.

But there's definitely desire to extend POSIX support in Zephyr, so
any feedback is appreciated. (You may also want to route this feedback
via Maureen Helm, who's both on Zephyr and Linaro LITE TSCs, so with her
input, specific things may get planned and prioritized.)


Thanks & Regards

Vakul
[]

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

Vakul Garg <vakul.garg@...>
 

Hi

 

I am using UDP sockets (posix flavor) in my app.

I need to determine the incoming UDP datagram’s source IP address and port.

For this, typically recvfrom() is used.

 

Since this call is not available, what are my options?

 

Can someone please advise?

 

Regards,

Vakul

 
Re: TCP assert error logs

Vakul Garg <vakul.garg@...>
 

Hi Paul

UDP loopback works and I can make progress with it for now.

(Ultimately, I need to move to some non-networking IPC such as mailbox or pipe.
The problem I face with that now is that I cannot multiplex these zephyr IPC in POSIX poll() along with socket descriptors.)

Thanks & Regards

Vakul

-----Original Message-----
From: Paul Sokolovsky [mailto:paul.sokolovsky@linaro.org]
Sent: Wednesday, September 13, 2017 1:08 PM
To: Vakul Garg <vakul.garg@nxp.com>
Cc: zephyr-users@lists.zephyrproject.org
Subject: Re: [Zephyr-users] TCP assert error logs

Hello Vakul,

On Tue, 12 Sep 2017 09:09:10 +0000
Vakul Garg <vakul.garg@nxp.com> wrote:

Hello Paul

I have attached a test case with the given ticket.
Thanks for that! It's on my todo list to look into that issue again, the testcase will be helpful then. In the meantime, following may be helpful for you:

1. UDP communication using a local interface works in Zephyr, we have a testcase for that in tests/net/socket/udp/

2. If you need TCP communication, you would need to use HOST-Zephyr communication. (Well, there is also a setup to allow 2 Zephyr QEMU instances to communicate with each other, I didn't check it for a while though).


Regards

Vakul


-----Original Message-----
From: Paul Sokolovsky [mailto:paul.sokolovsky@linaro.org]
Sent: Monday, September 11, 2017 4:52 PM
To: Vakul Garg <vakul.garg@nxp.com>
Cc: zephyr-users@lists.zephyrproject.org
Subject: Re: [Zephyr-users] TCP assert error logs

Hello Vakul,

On Sat, 9 Sep 2017 09:31:14 +0000
Vakul Garg <vakul.garg@nxp.com> wrote:

I just open a TCP server socket and let it listen for new
connections on 127.0.0.1 on a given server port.
Right, that might work, thanks to
https://gerrit.zephyrproject.org/r/#/c/7007/ , and if you verified, it
apparently does (I don't remember if I ever using 127.0.0.1 address, I
usually tried to use a local interface address in such cases, i.e.
192.0.2.1 by default). But just to get terminology right, there's no
explicit loopback interface in Zephyr, it's just an adhoc check for
the conventional loopback address (though this note is probably
irrelevant for your usecase, so feel free to ignore it [for now]).

Then another thread creates a TCP client socket and connects to the
127.0.0.1 on the same server port. After connection is successful,
client sends one data message on the socket.
What can I say? With such scenario, you went farther than I. Last time
I tried, it wasn't possible to establish a TCP connection under such
conditions at all:
https://jira.zephyrproject.org/browse/ZEP-2001 .

I'd suggest to add some comments to the above ticket, describing your
usecase. And ultimately, we'd need a typical small testcase to
reproduce the issue, so feel free to post your code to make a step
towards progress in that direction. I faced that issue when testing
networking support in Zephyr.JS and MicroPython projects, so there're
no readily available minimal testcases.



Thanks,
Paul



-----Original Message-----
From: Paul Sokolovsky [mailto:paul.sokolovsky@linaro.org]
Sent: Saturday, September 09, 2017 2:57 PM
To: Vakul Garg <vakul.garg@nxp.com>
Cc: zephyr-users@lists.zephyrproject.org
Subject: Re: [Zephyr-users] TCP assert error logs

Hello Vakul,

On Sat, 9 Sep 2017 06:47:35 +0000
Vakul Garg <vakul.garg@nxp.com> wrote:

Hi

I have two threads on my system communicating using TCP over
loopback interface. I am getting following errors.
To the best of my knowledge, there is (was) no loopback interface
support in Zephyr. So, I'd interested to know how to achieved the
setup above.


[net/tcp] [ERR] net_tcp_get_hdr: {assert: 'frag' failed} [net/tcp]
[ERR] net_tcp_send_pkt: Packet 0x20004664 does not contain TCP
header [net/tcp] [ERR] net_tcp_get_hdr: {assert:
'frag' failed} [net/tcp] [ERR] net_tcp_send_pkt: Packet
0x20004664 does not contain TCP header [net/tcp] [ERR]
net_tcp_get_hdr: {assert: 'frag' failed} [net/tcp] [ERR]
net_tcp_send_pkt: Packet 0x20004664 does not contain TCP header
[net/buf] [ERR] net_buf_unref_debug: net_pkt_frag_unref():826:
buf 0x200046a0 double free [net/buf] [ERR] net_buf_unref_debug:
net_pkt_frag_unref():826: buf 0x200046a0 double free [net/buf]
[ERR] net_buf_unref_debug: net_pkt_frag_unref():826: buf
0x20004830 double free

Can someone help?

Regards, Vakul

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


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


--
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: TCP assert error logs

Paul Sokolovsky
 

Hello Vakul,

On Tue, 12 Sep 2017 09:09:10 +0000
Vakul Garg <vakul.garg@nxp.com> wrote:

Hello Paul

I have attached a test case with the given ticket.
Thanks for that! It's on my todo list to look into that issue again,
the testcase will be helpful then. In the meantime, following may be
helpful for you:

1. UDP communication using a local interface works in Zephyr, we have
a testcase for that in tests/net/socket/udp/

2. If you need TCP communication, you would need to use HOST-Zephyr
communication. (Well, there is also a setup to allow 2 Zephyr QEMU
instances to communicate with each other, I didn't check it for a while
though).


Regards

Vakul


-----Original Message-----
From: Paul Sokolovsky [mailto:paul.sokolovsky@linaro.org]
Sent: Monday, September 11, 2017 4:52 PM
To: Vakul Garg <vakul.garg@nxp.com>
Cc: zephyr-users@lists.zephyrproject.org
Subject: Re: [Zephyr-users] TCP assert error logs

Hello Vakul,

On Sat, 9 Sep 2017 09:31:14 +0000
Vakul Garg <vakul.garg@nxp.com> wrote:

I just open a TCP server socket and let it listen for new
connections on 127.0.0.1 on a given server port.
Right, that might work, thanks to
https://gerrit.zephyrproject.org/r/#/c/7007/ , and if you verified,
it apparently does (I don't remember if I ever using 127.0.0.1
address, I usually tried to use a local interface address in such
cases, i.e. 192.0.2.1 by default). But just to get terminology right,
there's no explicit loopback interface in Zephyr, it's just an adhoc
check for the conventional loopback address (though this note is
probably irrelevant for your usecase, so feel free to ignore it [for
now]).

Then another thread creates a TCP client socket and connects to the
127.0.0.1 on the same server port. After connection is successful,
client sends one data message on the socket.
What can I say? With such scenario, you went farther than I. Last
time I tried, it wasn't possible to establish a TCP connection under
such conditions at all:
https://jira.zephyrproject.org/browse/ZEP-2001 .

I'd suggest to add some comments to the above ticket, describing your
usecase. And ultimately, we'd need a typical small testcase to
reproduce the issue, so feel free to post your code to make a step
towards progress in that direction. I faced that issue when testing
networking support in Zephyr.JS and MicroPython projects, so there're
no readily available minimal testcases.



Thanks,
Paul



-----Original Message-----
From: Paul Sokolovsky [mailto:paul.sokolovsky@linaro.org]
Sent: Saturday, September 09, 2017 2:57 PM
To: Vakul Garg <vakul.garg@nxp.com>
Cc: zephyr-users@lists.zephyrproject.org
Subject: Re: [Zephyr-users] TCP assert error logs

Hello Vakul,

On Sat, 9 Sep 2017 06:47:35 +0000
Vakul Garg <vakul.garg@nxp.com> wrote:

Hi

I have two threads on my system communicating using TCP over
loopback interface. I am getting following errors.
To the best of my knowledge, there is (was) no loopback interface
support in Zephyr. So, I'd interested to know how to achieved the
setup above.


[net/tcp] [ERR] net_tcp_get_hdr: {assert: 'frag' failed}
[net/tcp] [ERR] net_tcp_send_pkt: Packet 0x20004664 does not
contain TCP header [net/tcp] [ERR] net_tcp_get_hdr: {assert:
'frag' failed} [net/tcp] [ERR] net_tcp_send_pkt: Packet
0x20004664 does not contain TCP header [net/tcp] [ERR]
net_tcp_get_hdr: {assert: 'frag' failed} [net/tcp] [ERR]
net_tcp_send_pkt: Packet 0x20004664 does not contain TCP header
[net/buf] [ERR] net_buf_unref_debug: net_pkt_frag_unref():826:
buf 0x200046a0 double free [net/buf] [ERR] net_buf_unref_debug:
net_pkt_frag_unref():826: buf 0x200046a0 double free [net/buf]
[ERR] net_buf_unref_debug: net_pkt_frag_unref():826: buf
0x20004830 double free

Can someone help?

Regards, Vakul

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


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


--
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: TCP assert error logs

Vakul Garg <vakul.garg@...>
 

Hello Paul

I have attached a test case with the given ticket.

Regards

Vakul

-----Original Message-----
From: Paul Sokolovsky [mailto:paul.sokolovsky@linaro.org]
Sent: Monday, September 11, 2017 4:52 PM
To: Vakul Garg <vakul.garg@nxp.com>
Cc: zephyr-users@lists.zephyrproject.org
Subject: Re: [Zephyr-users] TCP assert error logs

Hello Vakul,

On Sat, 9 Sep 2017 09:31:14 +0000
Vakul Garg <vakul.garg@nxp.com> wrote:

I just open a TCP server socket and let it listen for new connections
on 127.0.0.1 on a given server port.
Right, that might work, thanks to
https://gerrit.zephyrproject.org/r/#/c/7007/ , and if you verified, it apparently does (I don't remember if I ever using 127.0.0.1 address, I usually tried to use a local interface address in such cases, i.e.
192.0.2.1 by default). But just to get terminology right, there's no explicit loopback interface in Zephyr, it's just an adhoc check for the conventional loopback address (though this note is probably irrelevant for your usecase, so feel free to ignore it [for now]).

Then another thread creates a TCP client socket and connects to the
127.0.0.1 on the same server port. After connection is successful,
client sends one data message on the socket.
What can I say? With such scenario, you went farther than I. Last time I tried, it wasn't possible to establish a TCP connection under such conditions at all: https://jira.zephyrproject.org/browse/ZEP-2001 .

I'd suggest to add some comments to the above ticket, describing your usecase. And ultimately, we'd need a typical small testcase to reproduce the issue, so feel free to post your code to make a step towards progress in that direction. I faced that issue when testing networking support in Zephyr.JS and MicroPython projects, so there're no readily available minimal testcases.



Thanks,
Paul



-----Original Message-----
From: Paul Sokolovsky [mailto:paul.sokolovsky@linaro.org]
Sent: Saturday, September 09, 2017 2:57 PM
To: Vakul Garg <vakul.garg@nxp.com>
Cc: zephyr-users@lists.zephyrproject.org
Subject: Re: [Zephyr-users] TCP assert error logs

Hello Vakul,

On Sat, 9 Sep 2017 06:47:35 +0000
Vakul Garg <vakul.garg@nxp.com> wrote:

Hi

I have two threads on my system communicating using TCP over
loopback interface. I am getting following errors.
To the best of my knowledge, there is (was) no loopback interface
support in Zephyr. So, I'd interested to know how to achieved the
setup above.


[net/tcp] [ERR] net_tcp_get_hdr: {assert: 'frag' failed} [net/tcp]
[ERR] net_tcp_send_pkt: Packet 0x20004664 does not contain TCP
header [net/tcp] [ERR] net_tcp_get_hdr: {assert: 'frag' failed}
[net/tcp] [ERR] net_tcp_send_pkt: Packet 0x20004664 does not contain
TCP header [net/tcp] [ERR] net_tcp_get_hdr: {assert: 'frag'
failed} [net/tcp] [ERR] net_tcp_send_pkt: Packet 0x20004664 does not
contain TCP header [net/buf] [ERR] net_buf_unref_debug:
net_pkt_frag_unref():826: buf 0x200046a0 double free [net/buf] [ERR]
net_buf_unref_debug: net_pkt_frag_unref():826: buf 0x200046a0 double
free [net/buf] [ERR] net_buf_unref_debug:
net_pkt_frag_unref():826: buf 0x20004830 double free

Can someone help?

Regards, Vakul

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


--
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: TCP assert error logs

Paul Sokolovsky
 

Hello Vakul,

On Sat, 9 Sep 2017 09:31:14 +0000
Vakul Garg <vakul.garg@nxp.com> wrote:

I just open a TCP server socket and let it listen for new connections
on 127.0.0.1 on a given server port.
Right, that might work, thanks to
https://gerrit.zephyrproject.org/r/#/c/7007/ , and if you verified, it
apparently does (I don't remember if I ever using 127.0.0.1 address,
I usually tried to use a local interface address in such cases, i.e.
192.0.2.1 by default). But just to get terminology right, there's no
explicit loopback interface in Zephyr, it's just an adhoc check for
the conventional loopback address (though this note is probably
irrelevant for your usecase, so feel free to ignore it [for now]).

Then another thread creates a TCP client socket and connects to the
127.0.0.1 on the same server port. After connection is successful,
client sends one data message on the socket.
What can I say? With such scenario, you went farther than I. Last time I
tried, it wasn't possible to establish a TCP connection under such
conditions at all: https://jira.zephyrproject.org/browse/ZEP-2001 .

I'd suggest to add some comments to the above ticket, describing your
usecase. And ultimately, we'd need a typical small testcase to
reproduce the issue, so feel free to post your code to make a step
towards progress in that direction. I faced that issue when testing
networking support in Zephyr.JS and MicroPython projects, so there're
no readily available minimal testcases.



Thanks,
Paul



-----Original Message-----
From: Paul Sokolovsky [mailto:paul.sokolovsky@linaro.org]
Sent: Saturday, September 09, 2017 2:57 PM
To: Vakul Garg <vakul.garg@nxp.com>
Cc: zephyr-users@lists.zephyrproject.org
Subject: Re: [Zephyr-users] TCP assert error logs

Hello Vakul,

On Sat, 9 Sep 2017 06:47:35 +0000
Vakul Garg <vakul.garg@nxp.com> wrote:

Hi

I have two threads on my system communicating using TCP over
loopback interface. I am getting following errors.
To the best of my knowledge, there is (was) no loopback interface
support in Zephyr. So, I'd interested to know how to achieved the
setup above.


[net/tcp] [ERR] net_tcp_get_hdr: {assert: 'frag' failed} [net/tcp]
[ERR] net_tcp_send_pkt: Packet 0x20004664 does not contain TCP
header [net/tcp] [ERR] net_tcp_get_hdr: {assert: 'frag' failed}
[net/tcp] [ERR] net_tcp_send_pkt: Packet 0x20004664 does not
contain TCP header [net/tcp] [ERR] net_tcp_get_hdr: {assert: 'frag'
failed} [net/tcp] [ERR] net_tcp_send_pkt: Packet 0x20004664 does
not contain TCP header [net/buf] [ERR] net_buf_unref_debug:
net_pkt_frag_unref():826: buf 0x200046a0 double free [net/buf] [ERR]
net_buf_unref_debug: net_pkt_frag_unref():826: buf 0x200046a0
double free [net/buf] [ERR] net_buf_unref_debug:
net_pkt_frag_unref():826: buf 0x20004830 double free

Can someone help?

Regards, Vakul

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


--
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: TCP assert error logs

Vakul Garg <vakul.garg@...>
 

I just open a TCP server socket and let it listen for new connections on 127.0.0.1 on a given server port.

Then another thread creates a TCP client socket and connects to the 127.0.0.1 on the same server port.
After connection is successful, client sends one data message on the socket.

-----Original Message-----
From: Paul Sokolovsky [mailto:paul.sokolovsky@linaro.org]
Sent: Saturday, September 09, 2017 2:57 PM
To: Vakul Garg <vakul.garg@nxp.com>
Cc: zephyr-users@lists.zephyrproject.org
Subject: Re: [Zephyr-users] TCP assert error logs

Hello Vakul,

On Sat, 9 Sep 2017 06:47:35 +0000
Vakul Garg <vakul.garg@nxp.com> wrote:

Hi

I have two threads on my system communicating using TCP over loopback
interface. I am getting following errors.
To the best of my knowledge, there is (was) no loopback interface support in Zephyr. So, I'd interested to know how to achieved the setup above.


[net/tcp] [ERR] net_tcp_get_hdr: {assert: 'frag' failed} [net/tcp]
[ERR] net_tcp_send_pkt: Packet 0x20004664 does not contain TCP header
[net/tcp] [ERR] net_tcp_get_hdr: {assert: 'frag' failed} [net/tcp]
[ERR] net_tcp_send_pkt: Packet 0x20004664 does not contain TCP header
[net/tcp] [ERR] net_tcp_get_hdr: {assert: 'frag' failed} [net/tcp]
[ERR] net_tcp_send_pkt: Packet 0x20004664 does not contain TCP header
[net/buf] [ERR] net_buf_unref_debug:
net_pkt_frag_unref():826: buf 0x200046a0 double free [net/buf] [ERR]
net_buf_unref_debug: net_pkt_frag_unref():826: buf 0x200046a0 double
free [net/buf] [ERR] net_buf_unref_debug: net_pkt_frag_unref():826:
buf 0x20004830 double free

Can someone help?

Regards, Vakul

--
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: TCP assert error logs

Paul Sokolovsky
 

Hello Vakul,

On Sat, 9 Sep 2017 06:47:35 +0000
Vakul Garg <vakul.garg@nxp.com> wrote:

Hi

I have two threads on my system communicating using TCP over loopback
interface. I am getting following errors.
To the best of my knowledge, there is (was) no loopback interface
support in Zephyr. So, I'd interested to know how to achieved the
setup above.


[net/tcp] [ERR] net_tcp_get_hdr: {assert: 'frag' failed}
[net/tcp] [ERR] net_tcp_send_pkt: Packet 0x20004664 does not contain
TCP header [net/tcp] [ERR] net_tcp_get_hdr: {assert: 'frag' failed}
[net/tcp] [ERR] net_tcp_send_pkt: Packet 0x20004664 does not contain
TCP header [net/tcp] [ERR] net_tcp_get_hdr: {assert: 'frag' failed}
[net/tcp] [ERR] net_tcp_send_pkt: Packet 0x20004664 does not contain
TCP header [net/buf] [ERR] net_buf_unref_debug:
net_pkt_frag_unref():826: buf 0x200046a0 double free [net/buf] [ERR]
net_buf_unref_debug: net_pkt_frag_unref():826: buf 0x200046a0 double
free [net/buf] [ERR] net_buf_unref_debug: net_pkt_frag_unref():826:
buf 0x20004830 double free

Can someone help?

Regards, Vakul

--
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
TCP assert error logs

Vakul Garg <vakul.garg@...>
 

Hi

 

I have two threads on my system communicating using TCP over loopback interface.

I am getting following errors.

 

[net/tcp] [ERR] net_tcp_get_hdr: {assert: 'frag' failed}

[net/tcp] [ERR] net_tcp_send_pkt: Packet 0x20004664 does not contain TCP header

[net/tcp] [ERR] net_tcp_get_hdr: {assert: 'frag' failed}

[net/tcp] [ERR] net_tcp_send_pkt: Packet 0x20004664 does not contain TCP header

[net/tcp] [ERR] net_tcp_get_hdr: {assert: 'frag' failed}

[net/tcp] [ERR] net_tcp_send_pkt: Packet 0x20004664 does not contain TCP header

[net/buf] [ERR] net_buf_unref_debug: net_pkt_frag_unref():826: buf 0x200046a0 double free

[net/buf] [ERR] net_buf_unref_debug: net_pkt_frag_unref():826: buf 0x200046a0 double free

[net/buf] [ERR] net_buf_unref_debug: net_pkt_frag_unref():826: buf 0x20004830 double free

 

Can someone help?

 

Regards, Vakul
Re: Help with compiling for qemu ARM cortex m3

Vakul Garg <vakul.garg@...>
 

Hi Andrew

The suggested commands are very useful.
Thanks for your advice.

Regards, Vakul

-----Original Message-----
From: zephyr-users-bounces@lists.zephyrproject.org [mailto:zephyr-users-bounces@lists.zephyrproject.org] On Behalf Of Boie, Andrew P
Sent: Thursday, September 07, 2017 9:39 PM
To: Kumar Gala <kumar.gala@linaro.org>; Priyanka Rawat <priyanka.rawat@nxp.com>
Cc: zephyr-users@lists.zephyrproject.org
Subject: Re: [Zephyr-users] Help with compiling for qemu ARM cortex m3

However, I want to test with the same SRAM value as in real hardware
(e.g.,
eventually I want to test with KW41Z board). So instead of increasing
the current SRAM value, I would rather modify proj.conf.

Could someone please tell me what would be the right approach to
address
this issue of SRAM overflow for qemu ARM ?
"make ram_report" and "make rom_report" dump out some helpful information to see what in your code is using so much memory.

Andrew
_______________________________________________
Zephyr-users mailing list
Zephyr-users@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-users
Re: Help with compiling for qemu ARM cortex m3

Boie, Andrew P
 

However, I want to test with the same SRAM value as in real hardware (e.g.,
eventually I want to test with KW41Z board). So instead of increasing the current
SRAM value, I would rather modify proj.conf.

Could someone please tell me what would be the right approach to address
this issue of SRAM overflow for qemu ARM ?
"make ram_report" and "make rom_report" dump out some helpful information to see what in your code is using so much memory.

Andrew
Re: Help with compiling for qemu ARM cortex m3

Kumar Gala
 

On Sep 7, 2017, at 4:37 AM, Priyanka Rawat <priyanka.rawat@nxp.com> wrote:

Hi

I tried to compile my sample application code for the target
BOARD ?= qemu_cortex_m3

It compiles for qemu_x86 however for qemu_cortex_m3 it gives me errors related to SRAM overflowed.

$zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-zephyr-eabi/gcc/arm-zephyr-eabi/6.2.0/real-ld: zephyr_prebuilt.elf section `noinit' will not fit in region `SRAM'
$zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-zephyr-eabi/gcc/arm-zephyr-eabi/6.2.0/real-ld: section .intList VMA [0000000020010000,0000000020010043] overlaps section noinit VMA [000000002000d5a0,000000002002413b]
$zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-zephyr-eabi/gcc/arm-zephyr-eabi/6.2.0/real-ld: region `SRAM' overflowed by 82236 bytes
collect2: error: ld returned 1 exit status
$zephyr/Makefile:878: recipe for target 'zephyr_prebuilt.elf' failed


I test with the recent zephyr version (master branch).
In dts/arm/ti/lm3s6965.dtsi the SRAM for qemu_cortex_m3 defined is 64 KB.

I can manage to compile for qemu_cortex_m3 by increasing the value of SRAM from 64 KB to 128 KB in
dts/arm/ti/lm3s6965.dtsi

sram0: memory@20000000 {
device_type = "memory";
compatible = "mmio-sram";
reg = <0x20000000 (64*1024)>;
};

However, I want to test with the same SRAM value as in real hardware (e.g., eventually I want to test with KW41Z board). So instead of increasing the current SRAM value, I would rather modify proj.conf.

Could someone please tell me what would be the right approach to address this issue of SRAM overflow for qemu ARM ?

Thanks
Priyanka
I don’t believe there is a way to change the amount of memory in qemu. Even with switching to the KW41Z guess you are going to run into memory issues (as it has 128k). So are you building your own application or one of the samples/tests? You can try and remove config options to reduce memory, but if you are 82K overflowing than I’m guessing you need to look at how your application is utilizing memory and see if you can reduce that.

- k
2781 - 2800 of 2948