Re: problems with TCP send sizes greater than ETH_PKTSIZE (SAMA5D36)
My question about MSS wasn't clear– what I mean is, to an application (like tcpecho or tcpblaster), the size of MSS shouldn't matter. Shouldn't the application be able to send as many bytes as it wants? The TCP stack divides the stream up into chunks (of MSS length) and transmits them... sending more than MSS bytes should not hang the application...? Yes, that is correct. That's not what I"m seeing with the NuttX that I'm using (SAMA5D36-Xplained using the gigabit ethernet port, built from the latest master). Do you have write buffering enabled? Do you have enough IOBs pre-allocated? Have you tried looking at the traffic with WireShark?
[PATCH] Add Ethernet SPI ENC28J60 board support to STM32F4Discovery
Please apply attached patch add support to ENC28J60 in the
STM32F4Discovery board.
BR,
Alan
From a68a785cb0d4914c75a702704e8060c0cfb4210b Mon Sep 17 00:00:00 2001
From: Alan Carvalho de Assis
Date: Sun, 9 Feb 2020 10:16:37 -0300
Subject: [PATCH] Add Ethernet SPI ENC28J60 board support to STM32F4Discovery
---
boards/arm/stm32/stm32f4discovery/README.txt | 18 ++
.../arm/stm32/stm32f4discovery/src/Makefile | 4 +
.../stm32f4discovery/src/stm32_enc28j60.c | 225 ++
.../stm32/stm32f4discovery/src/stm32_spi.c| 15 ++
.../stm32f4discovery/src/stm32f4discovery.h | 9 +
5 files changed, 271 insertions(+)
create mode 100644 boards/arm/stm32/stm32f4discovery/src/stm32_enc28j60.c
diff --git a/boards/arm/stm32/stm32f4discovery/README.txt b/boards/arm/stm32/stm32f4discovery/README.txt
index 900390..0d4e1cf932 100644
--- a/boards/arm/stm32/stm32f4discovery/README.txt
+++ b/boards/arm/stm32/stm32f4discovery/README.txt
@@ -42,6 +42,7 @@ Contents
- SSD1289
- UG-2864AMBAG01 / UG-2864HSWEG01
- NiceRF LoRa (2AD66-LoRa V2)
+ - Ethernet SPI Module ENC28J60
- HCI UART
- STM32F4Discovery-specific Configuration Options
- BASIC
@@ -652,6 +653,23 @@ First connect the GND and VCC (to 3.3V) and then connect the SCK label to PA5,
connnect the MISO to PA6, connect the MOSI to PA7, connect the NSS to PD8,
connect DIO0 to PD0 and finally connect NRESET to PD4.
+Ethernet SPI Module ENC28J60
+
+
+You can use an external Ethernet SPI Module ENC28J60 with STM32F4Discovery board.
+
+First connect the GND and VCC (to 3.3V). Note: according with ENC28J60 datasheet
+the Operating Voltage should be between 3.1V to 3.6V, but STM32F4Discover only
+supply 3.0V. You can modify your board to supply 3.3V: just remove the D3 diode
+and short-circuit the board pads where it was soldered).
+
+Connect the SCK label to PA5, connnect the SO to PA6, connect the SI to PA7,
+connect the CS to PA4, connect RST to PE1 and finally connect INT to PE4.
+
+The next step is to enable the ENC28J60 in the menuconfig ("make menuconfig")
+and the necessary Network configuration, you can use the
+boards/arm/stm32/fire-stm32v2/configs/nsh/defconfig as reference.
+
HCI UART
diff --git a/boards/arm/stm32/stm32f4discovery/src/Makefile b/boards/arm/stm32/stm32f4discovery/src/Makefile
index d242420ba3..86840217b9 100644
--- a/boards/arm/stm32/stm32f4discovery/src/Makefile
+++ b/boards/arm/stm32/stm32f4discovery/src/Makefile
@@ -81,6 +81,10 @@ ifeq ($(CONFIG_LCD_ST7567),y)
CSRCS += stm32_st7567.c
endif
+ifeq ($(CONFIG_ENC28J60),y)
+CSRCS += stm32_enc28j60.c
+endif
+
ifeq ($(CONFIG_LPWAN_SX127X),y)
CSRCS += stm32_sx127x.c
endif
diff --git a/boards/arm/stm32/stm32f4discovery/src/stm32_enc28j60.c b/boards/arm/stm32/stm32f4discovery/src/stm32_enc28j60.c
new file mode 100644
index 00..cc14d75e13
--- /dev/null
+++ b/boards/arm/stm32/stm32f4discovery/src/stm32_enc28j60.c
@@ -0,0 +1,225 @@
+/
+ * boards/arm/stm32/fire-stm32v2/src/stm32_enc28j60.c
+ *
+ * Copyright (C) 2012, 2017 Gregory Nutt. All rights reserved.
+ * Author: Gregory Nutt
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in
+ *the documentation and/or other materials provided with the
+ *distribution.
+ * 3. Neither the name NuttX nor the names of its contributors may be
+ *used to endorse or promote products derived from this software
+ *without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
+ * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
+ * COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
+ * BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
+ * OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
+ * AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
+ * ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ *
+ /
+
+/* 2MBit SPI FLASH OR ENC28J60
+ *
+ * --- -- -- -
+ * PIN NAME SIGNAL NOTES
+ * --- --
[GitHub] [incubator-nuttx-testing] liuguo09 opened a new pull request #7: cibuild.sh: decouple -b option to do run_builds only
liuguo09 opened a new pull request #7: cibuild.sh: decouple -b option to do run_builds only URL: https://github.com/apache/incubator-nuttx-testing/pull/7 1. In nuttx and apps PR check build, github action/jenkins/travis CI would checkout repos accordingly. So decouple -b option to do run_builds only. 2. And if do builds starting from testing repo, call cibuild.sh as below: ./cibuild.sh -i -s -b check or ./cibuild.sh -i -s -b full Change-Id: I5cd0b87aed37ddab117d17aa5b72744c2db2aac6 Signed-off-by: liuhaitao This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
Re: problems with TCP send sizes greater than ETH_PKTSIZE (SAMA5D36)
Greg, I have write buffering enabled: CONFIG_NET_WRITE_BUFFERS=y Here are my IOB settings: CONFIG_MM_IOB=y CONFIG_IOB_NBUFFERS=24 CONFIG_IOB_BUFSIZE=196 CONFIG_IOB_NCHAINS=24 CONFIG_IOB_THROTTLE=0 I do have some more data. I did a manual git bisect to find out where things started getting worse. I went back to Jan 1 and tested various commits with a custom program that talks to tcpecho (binary search to zero in on where the problems are). Commits before and after, up to the current tip, hang when I try to do consecutive TCP sends. Since Jan 1, most of the commits can't do more than 10 consecutive TCP sends of 1000 characters, that's a lot less than the MSS of 1447. However, commit c1f75af084010bd8a13b2481abc38d848cd545f2 seems to work the best. With that commit, as long as CONFIG_TIME_EXTENDED is not set, I can send as many 1400 character TCP sends as I want... thousands in a row. However, if I set CONFIG_TIME_EXTENDED=y, things stop working, I can only do a few TCP sends before the tcpecho hangs. Note that through all this, if I try to send more than about 1440 characters in a single TCP send, tcpecho will hang. That isn't right but I haven't tracked that problem down either. I tried to use a debugger and also syslog to trace what difference the CONFIG_TIME_EXTENDED was making– why it causes the hang if it is turned on. But I haven't figured that out yet. Do you have any ideas? Re: Wireshark, I have been using tcpdump extensively. The linux side seems to send the first TCP packet ok. tcpecho can echo back if CONFIG_TIME_EXTENDED is not set and the MSS is 1400 bytes or less. If MSS is larger than 1447 tcpecho will send a few packets and then hang. I haven't characterized the boundary (1400-1448 bytes). I also just figured out the CONFIG_TIME_EXTENDED thing this afternoon so haven't looked at tcpdump traces of it yet, but I will and report back. I can send some tcpdump traces if that would help. Would it? -adam On Sun, Feb 9, 2020 at 5:21 AM Gregory Nutt wrote: > > > My question about MSS wasn't clear– what I mean is, to an application > (like > > tcpecho or tcpblaster), the size of MSS shouldn't matter. Shouldn't the > > application be able to send as many bytes as it wants? The TCP stack > > divides the stream up into chunks (of MSS length) and transmits them... > > sending more than MSS bytes should not hang the application...? > Yes, that is correct. > > That's not what I"m seeing with the NuttX that I'm using > (SAMA5D36-Xplained > > using the gigabit ethernet port, built from the latest master). > Do you have write buffering enabled? Do you have enough IOBs > pre-allocated? Have you tried looking at the traffic with WireShark? > > > -- Adam Feuer
Re: problems with TCP send sizes greater than ETH_PKTSIZE (SAMA5D36)
Just to follow up with some more precise data, I just did a few more tests. On commit c1f75af084010bd8a13b2481abc38d848cd545f2 I can send any number of 1446 byte (or less) TCP sends. 1447 or more hangs. -adam On Sun, Feb 9, 2020 at 9:14 PM Adam Feuer wrote: > Greg, > > I have write buffering enabled: > CONFIG_NET_WRITE_BUFFERS=y > > Here are my IOB settings: > CONFIG_MM_IOB=y > CONFIG_IOB_NBUFFERS=24 > CONFIG_IOB_BUFSIZE=196 > CONFIG_IOB_NCHAINS=24 > CONFIG_IOB_THROTTLE=0 > > I do have some more data. I did a manual git bisect to find out where > things started getting worse. I went back to Jan 1 and tested various > commits with a custom program that talks to tcpecho (binary search to zero > in on where the problems are). > > Commits before and after, up to the current tip, hang when I try to do > consecutive TCP sends. Since Jan 1, most of the commits can't do more than > 10 consecutive TCP sends of 1000 characters, that's a lot less than the MSS > of 1447. > > However, commit c1f75af084010bd8a13b2481abc38d848cd545f2 seems to work > the best. With that commit, as long as CONFIG_TIME_EXTENDED is not set, I > can send as many 1400 character TCP sends as I want... thousands in a row. > However, if I set CONFIG_TIME_EXTENDED=y, things stop working, I can only > do a few TCP sends before the tcpecho hangs. > > Note that through all this, if I try to send more than about 1440 > characters in a single TCP send, tcpecho will hang. That isn't right but I > haven't tracked that problem down either. > > I tried to use a debugger and also syslog to trace what difference the > CONFIG_TIME_EXTENDED was making– why it causes the hang if it is turned on. > But I haven't figured that out yet. Do you have any ideas? > > Re: Wireshark, I have been using tcpdump extensively. The linux side seems > to send the first TCP packet ok. tcpecho can echo back if > CONFIG_TIME_EXTENDED is not set and the MSS is 1400 bytes or less. If MSS > is larger than 1447 tcpecho will send a few packets and then hang. I > haven't characterized the boundary (1400-1448 bytes). I also just figured > out the CONFIG_TIME_EXTENDED thing this afternoon so haven't looked at > tcpdump traces of it yet, but I will and report back. > > I can send some tcpdump traces if that would help. Would it? > > -adam > > On Sun, Feb 9, 2020 at 5:21 AM Gregory Nutt wrote: > >> >> > My question about MSS wasn't clear– what I mean is, to an application >> (like >> > tcpecho or tcpblaster), the size of MSS shouldn't matter. Shouldn't the >> > application be able to send as many bytes as it wants? The TCP stack >> > divides the stream up into chunks (of MSS length) and transmits them... >> > sending more than MSS bytes should not hang the application...? >> Yes, that is correct. >> > That's not what I"m seeing with the NuttX that I'm using >> (SAMA5D36-Xplained >> > using the gigabit ethernet port, built from the latest master). >> Do you have write buffering enabled? Do you have enough IOBs >> pre-allocated? Have you tried looking at the traffic with WireShark? >> >> >> > > -- > Adam Feuer > -- Adam Feuer
