Activity for Andrej Butok
-
Andrej Butok posted a comment on discussion FNET User Forum
Should be ok, if the destination adress is our address or a broadcast one.
-
By default, the server socket is configured to send data as soon as possible, without delay (TCP_NODELAY ). You can try to play with its TCP socket options: https://fnet.sourceforge.io/manual/group__fnet__socket_ga989481a2cee0291e70f9076a091eddf1.html#ga989481a2cee0291e70f9076a091eddf1
-
TCP segmentation it is a feature of TCP ;)
-
Think about the MCUBoot secondary bootloader. It has security, recovery and differeant FW update modes.
-
Yes you can.
-
Thank you for reporting, will look at it when have a time.
-
Hi, Agree, this is the bug. But do not add fnet_htons(). The right code should be (fnet_stack\service\dns\fnet_dns.c, line 421): && ((header->flags & FNET_HTONS(FNET_DNS_HEADER_FLAGS_QR)) == FNET_HTONS(FNET_DNS_HEADER_FLAGS_QR)) /* Is response.*/ Please confirm, that it works for you. Thank you, Andrej Butok
-
To have a MCUx example, it must be part of a MCUx SDK package. It is needed to convince NXP to add FNET support to the SDK.
-
You may search for FNET_TCP_SGT_FIN flag use, places where FIN is sent. For example, it sent with the last sent data ACK.
-
Also, if there is data in your receive queue, RST should be sent.
-
Most probably, you still have unsent data. Please look inside FNET services source code, how they handle session states.
-
Most probably, you still have unsent data. Please look inside FNET services source code, how they handles session states.
-
It sent FIN and waiting for FIN from other side. http://www.tcpipguide.com/free/t_TCPConnectionTermination-2.htm
-
This is TCP. To change behavior, read: https://fnet.sourceforge.io/manual/group__fnet__socket_ga6cb4c12c0fba44e02a019dc877fef373.html#ga6cb4c12c0fba44e02a019dc877fef373 https://fnet.sourceforge.io/manual/group__fnet__socket_ga989481a2cee0291e70f9076a091eddf1.html#gga989481a2cee0291e70f9076a091eddf1a6856768825eabef55d9d4175020da464
-
It can be related to: https://github.com/butok/FNET/issues/7
-
In this case call it by line. Just curious, what are doing in this 8K script? Example?
-
Just increase the command line buffer size.
-
It contains changes only in c file. Guess, missed .h changes.
-
Yes, stack supports multiple Ethernet and WiFi interfaces. Tested with two ENET Ethernet + one WiFi module. Search for FNET_CPU_NETIF_NUMBER, FNET_CFG_CPU_ETH1 and etc. to figure out.
-
6LoWPAN is not supported. Contribution is welcome.
-
It was not designed for the RAW Ethernet frame sending from a user application. You may look inside _fnet_ip4_output()=> fnetip4netifoutput(), but it is not trivial.
-
Look at the FNET DHCP server source code (fnet_dhcp_srv.c=>fnet_dhcp_srv_init()). It does what you need. BTW: FNET socket functions are not blocking. So fnet_socket_recvfrom() should be polled.
-
Or duplicate the code, and rely on a compiler to optimize it.
-
Good notice, will add a fix.
-
All porting code is placed in \fnet\fnet_stack\port You have to implement API in port\cpu\fnet_cpu.h And wrap your Ethernet/WiFi driver by fnet_eth_if_t interface structure. Use any supported platform as a reference.
-
You have to upgrade to the latest one.
-
Hi, yes, all reported vulnerabilities were fixed.
-
Fix type of variables to avoid warnings.
-
Fix some additional typos.
-
Fix typos in sources.
-
Yes, you may use FNET_DEBUG_PRINTF() where it is used for debugging.
-
For example I would like to send it to our the jtag (swo_debug) You can implement your JTAG stream (use existing ones as a reference) and set it as the default serial stream. OR modify the original code , add #ifndef FNET_DEBUG_PRINTF .... and set your own FNET_DEBUG_PRINTF definition for your project.
-
It is not so trivial, fnet_printf() outputs to a default serial stream. It can be a serial port, but in case of Telnet shell it sends data over Telnet protocol. It is not used by stack but an application, except debug needs. As this is an application specific, you may use any printf you need.
-
Point 3 contains more info: https://fnet.sourceforge.io/manual/how_to_add_boot.html
-
FNET TCP/IP stack: Version 4.7.1 released
-
FNET 4.7.1
-
It can be ported to any 32-bit MCU/MPU. It's written in the C language.
-
Ok. If you think, it is can be useful for others, you may share your changed sources.
-
Based on the log the packet is lost, what is causing retransmission. If everything is correct it should not happen. The goal is to figure out a source of the issue. 1) Try to switch to bare-metal (not RTOS) 2) To avoid stuck in ETH FIFOs, Ethernet FIFO buffers must be in non-cashable area. 3) Try to send 1, 2, 3 etc. packets till the packet lost happens. 4) Increase stack HEAP, just in case. I would find it soon or later, based on my past experience in porting, but for you it will take some time...
-
MCUx IDE is not supported by FNET examples. It may be caused: - your MCUx Bootloader footprint size more than it was reserved for it. So it erases himself. - the Flash ram code is not placed in RAM. - other MCUx reasons. You have to debug it.
-
MCUx IDE is not supported by FNET example. It may be caused: - your MCUx Bootloader footprint size more than it was reserved for it. So it erases himself. - the Flash ram code is not placed in RAM. - other MCUx reasons. You have to debug it.
-
It’s difficult to say exactly what happened, remotely. But the common issue with ethernet driver porting to be sure that all frames are sent/received without dropping; also solved corner cases and workaround bugs in HW. Try to send/receive just one packet. And see on behavior. After that increase it to 2, 3 and etc. Try to solve one issue at one time, otherwise it may become even worse.
-
It’s difficult to say exactly what happened, remotely. But the common issue with ethernet driver porting to be sure that all frames are sent/received without dropping; also solved corner cases and workaround bugs in HW. Try to send/receive just one packet. And see on behavior. After that increase it to 2, 3 and etc. Try to solve one issue at one time, otherwise it may become in worse.
-
You are right. I have just found: "As the client does not have a valid network address, the client must broadcast the DHCPDECLINE message."
-
Hi Timo, this is great. Try to stress your port to be sure that it is relible enough and the low level driver is not loosing TX and RX frames, for example by fnet_bench application.
-
Request is also brodcasted.
-
Discover is broadcast. Behaviour of your server, is your problem ;)
-
Most probably, you do not see it in your PC log because it is sent as a unicast datagram to the server.
-
fent_dhcp_cln.c line 1025, in case of an address conflict is detected, the client should send a DECLINE message directly to the server. Just put a breakpoint there, and look if it reached and where it goes after.
-
fent_dhcp_cln.c line 1025, in case of conflict is detected, the client should send DECLINE. Just put a breakpoint there, and look if it reached and where it goes after.
-
You have to modify the Source Code, to disable the print function calls.
-
Both cases are wrong, you must start on your application Reset Vector. Use debugger or map file to get it. Or even better, contact NXP customer support for asistence, as this is not the FNET TCP-IP stack related question.
-
Should be in a startup_'platfomname'.s file.
-
If you need to detect the start address automatically in run time, you may use the application Vector Table which contains the Reset Vector address: __Vectors: .long Image$$ARM_LIB_STACK_MSP$$ZI$$Limit / Top of Stack / .long Reset_Handler / Reset Handler /
-
Tip: look into the fnet_fec.h and you will see common registers. So existing FEC driver will work on you platform , Just needed a bit tuning in configuration. Also you already have working BSP => 100% of success. I am not that proficient with programming. So you just need to hire a clever developer ;)
-
Hello Timo, Do not sure that you will find somebody with real MCF5475 experience. “but there are no Circular Buffers but FIFOs.” I should be the same, but named different way. If not, it should be relatively easy to adopt to it.
-
FNET TCP/IP stack: Version 4.7.0 released
-
FNET 4.7.0
-
Hi Boleokin, K70 is not supported out of the box by FNET. Flash may be tricky on Kinetis. For example, look inside of fnet_ftfl_command( ), you will notice the workaround, covered by #if FNET_CFG_CPU_MK60N512 || FNET_CFG_CPU_MK60DN512 / This problem exists in first-released-version product (mask set: 0M33Z). / So different revisions of chip may require different settings. K70 should work, but something minor may be missing. Please ask NXP support for help. Andrej Butok
-
Hi Boleokin, K70 is not supported out of the box by FNET. Flash may be tricky on Kinetis. For example, look inside of fnet_ftfl_command( ), you will notice the workaround, covered by #if FNET_CFG_CPU_MK60N512 || FNET_CFG_CPU_MK60DN512 / This problem exists in first-released-version product (mask set: 0M33Z). / So different revision of chip may require different settings. K70 should work, but something minor may be is missing. Please ask NXP support for help. Andrej Butok
-
Is 4096 a correct value for FAPP_CFG_HEAP_SIZE ? If your application works - yes. It's used to store/buffer network packets inside the stack.
-
For interrupt table, look at the Note section: http://fnet.sourceforge.net/manual/how_to_add_fnet.html BTW: As the start point use existing projects.
-
Hi, I will look at this issue in several weeks when I will back from a trip.
-
No experience with EVN.
-
The best version is the latest one.
-
Hi, To save resources for testing and support, number of active projects was limited. It means that FNET is able to run on MK70FN1M, but the project files are not generated/icluded in the current version.
-
Hi BR, your proposal you may send directly to andrey.butok@gmail.com
-
For the current period of time, I have decided to do the main development, only if it is donated/sponsored ;)
-
Hi, VLAN is not supported.
-
1) TCP is not able change the UDP behavior. 2) Disabling UDP checksum is the feature of the protocol. But is not recommended to disable it. Old versions are not supported at all. So please do not expect any help!
-
1) TCP is not able change the UDP behavior. 2) Disabling UDP checksum is the feature of the protocol. But is not recommended to disable it. Old versions are not supported at all. So please do expect any help!
-
Good ;)
-
To check if your system is OK, use fbench UDP application with your port number. Also, very often the traffic is blocked by a PC antivirus firewall, so disable it. For example, my antivirus blocks UDP TFTP traffic.
-
To check if your system is OK, use fbench UDP application with your port number. Also, very aften the traffic is blocked by a PC antivirus firewall, so disable it. For example, my antivirus blocks UDP TFTP traffic.
-
No guess, it's needed a deeper investigation. BTW. The latest version is v4.6.2. Do not use old buggy versions.
-
No guess, it's need deeper investigation. BTW. The latest version is v4.6.2. Do not use old buggy versions.
-
When I will have time or will be donated ;)
-
Hi. These descriptors are accessed by DMA. So to avoid "dancing" with cache, it is better to have them in SRAM. Or you may invalidate them every time, that gives unwanted slowdown.
-
Hi. These descriptors are accessed by DMA. So to avoid "dancing" with cache, it is better to have them in SRAM. Or you may invalidate them every time, that gives unwanted slowdown. On Mon, 29 Jul 2019 at 18:26, unknowcoder unknowcoder@users.sourceforge.net wrote: I am looking into enabling caching on K65 (same for K66), to provide better throughput with the SDRAM. I noticed the stack has macros for invalidating cache when it comes to accessingfnet_fec_if_t structures. I have a few questions about...
-
It the peripheral clock, not PHY clock. On Mon, 22 Jul 2019 at 15:32, unknowcoder unknowcoder@users.sourceforge.net wrote: What peripheral clock does fnet_mk_periph_clk_khz() method refer to? Is the clock used for internal MAC? We are feeding 50MHz signal from our PHY to ENET_1588_CLKIN. So this method just need to return 50000Khz? Porting FNET over to MK65 from MKF64 Sent from sourceforge.net because you indicated interest in < https://sourceforge.net/p/fnet/discussion/920346/> To unsubscribe from...
-
Hi, There is no a step-by-step guide. But it should be relativly easy, as all platform-specifuc code is placed in the fnet_stack/port folder. As your platform is Kinetis, go to fnet_stack/port/mk. Choose a platform which is more close to your one, guess for you it is MK66. Add FNET_CFG_CPU_<new_platform> and all related staff to the port/cpu/fent_cpu_config.h Find all code which is cowered by FNET_CFG_CPU_MK66FN2 and add FNET_CFG_CPU_<new_platform> specific code the same way. A start-up code is part...
-
Hi, There is no a step-by-step guide. But it should be relativly easy, as all platform-specifuc code is placed in the fnet_stack/port folder. As your platform is Kinetis, go to fnet_stack/port/mk. Choose a platform which is more close to your one, guess for you it is MK66. Add FNET_CFG_CPU_<new_platform> and all related staff to the port/cpu/fent_cpu_config.h Find all code which is cowered by FNET_CFG_CPU_MK66FN2 and add FNET_CFG_CPU_<new_platform> specific code the same way. A start-up code is part...
-
Yes. This is the application-specific code, so the include of external file may have not expected content. Moving of this include to the top is good decision.
-
FNET has nothing with the CMSIS issue. BTW: MCUx is the worst IDE I have touched.
1 >