Skip to content

Latest commit

 

History

History
158 lines (118 loc) · 6.92 KB

README.md

File metadata and controls

158 lines (118 loc) · 6.92 KB
Raw

Nx_UDP_Echo_Server application description

This application provides an example of Azure RTOS NetX/NetXDuo stack usage . It shows how to develop a NetX UDP server to communicate with a remote client using the NetX UDP socket API.

The main entry function tx_application_define() is called by ThreadX during kernel start, at this stage, all NetX resources are created.

  • A NX_PACKET_POOL_is allocated
  • A NX_IP instance using that pool is initialized
  • The ARP, ICMP, UDP and protocols are enabled for the NX_IP instance
  • A DHCP client is created.

The application then creates 2 threads with the same priorities:

  • AppMainThread (priority 10, PreemtionThreashold 10) : created with the TX_AUTO_START flag to start automatically.
  • AppUDPThread (priority 10, PreemtionThreashold 10) : created with the TX_DONT_START flag to be started later.

The AppMainThread starts and perform the following actions:

  • starts the DHCP client
  • waits for the IP address resolution
  • resumes the AppUDPThread

The AppUDPThread, once started:

  • creates an UDP server socket

  • listen indefinitely on new client connections.

  • As soon as a new connection is established, the UDP server socket starts receiving data packets from the client.

  • At each received message the server:

    • extracts the Client IP address and remote port
    • retrieve the data from the received packet
    • prints the info above on the HyperTerminal

  • Once the data exchange is completed the UDP server enters in an idle state an toggles the green led.

Expected success behavior

  • The board IP address is printed on the HyperTerminal
  • The response messages sent by the server are printed on the HyerTerminal
  • If the echotool utility is used the message sent by the client are displayed on the PC console.
  • A summary message similar to the following is printed on the HyperTerminal and the green LED is toggling.
 SUCCESS : 10 / 10 packets sent

Error behaviors

  • the Red LED is toggling to indicate any error that have occurred.
  • In case the message exchange is not completed the Hyperterminal is not printing the received messages.

Assumptions if any

  • The Application is using the DHCP to acquire IP address, thus a DHCP server should be reachable by the board in the LAN used to test the application.
  • The application is configuring the Ethernet IP with a static predefined MAC Address, make sure to change it in case multiple boards are connected on the same LAN to avoid any potential network traffic issues.
  • The MAC Address is defined in the main.c
void MX_ETH_Init(void)
{

  /* USER CODE BEGIN ETH_Init 0 */

  /* USER CODE END ETH_Init 0 */

   static uint8_t MACAddr[6];

  /* USER CODE BEGIN ETH_Init 1 */

  /* USER CODE END ETH_Init 1 */
  heth.Instance = ETH;
  heth.Init.AutoNegotiation = ETH_AUTONEGOTIATION_ENABLE;
  heth.Init.Speed = ETH_SPEED_100M;
  heth.Init.DuplexMode = ETH_MODE_FULLDUPLEX;
  heth.Init.PhyAddress = LAN8742A_PHY_ADDRESS;
  MACAddr[0] = 0x00;
  MACAddr[1] = 0x80;
  MACAddr[2] = 0xE1;
  MACAddr[3] = 0x00;
  MACAddr[4] = 0x00;
  MACAddr[5] = 0x00;

Known limitations

None

ThreadX usage hints

  • ThreadX uses the Systick as time base, thus it is mandatory that the HAL uses a separate time base through the TIM IPs.

  • ThreadX is configured with 100 ticks/sec by default, this should be taken into account when using delays or timeouts at application. It is always possible to reconfigure it in the "tx_user.h", the "TX_TIMER_TICKS_PER_SECOND" define,but this should be reflected in "tx_initialize_low_level.s" file too.

  • ThreadX is disabling all interrupts during kernel start-up to avoid any unexpected behavior, therefore all system related calls (HAL, BSP) should be done either at the beginning of the application or inside the thread entry functions.

  • ThreadX offers the "tx_application_define()" function, that is automatically called by the tx_kernel_enter() API. It is highly recommended to use it to create all applications ThreadX related resources (threads, semaphores, memory pools...) but it should not in any way contain a system API call (HAL or BSP).

  • Using dynamic memory allocation requires to apply some changes to the linker file. ThreadX needs to pass a pointer to the first free memory location in RAM to the tx_application_define() function, using the "first_unused_memory" argument. This require changes in the linker files to expose this memory location.

    • For EWARM add the following section into the .icf file:
    place in RAM_region    { last section FREE_MEM };
    • For MDK-ARM:
    either define the RW_IRAM1 region in the ".sct" file
or modify the line below in "tx_low_level_initilize.s to match the memory region being used
    LDR r1, =|Image$$RW_IRAM1$$ZI$$Limit|
    • For STM32CubeIDE add the following section into the .ld file:
    ._threadx_heap :
  {
     . = ALIGN(8);
     __RAM_segment_used_end__ = .;
     . = . + 64K;
     . = ALIGN(8);
   } >RAM_D1 AT> RAM_D1

    The simplest way to provide memory for ThreadX is to define a new section, see ._threadx_heap above.
In the example above the ThreadX heap size is set to 64KBytes.
The ._threadx_heap must be located between the .bss and the ._user_heap_stack sections in the linker script.	 
Caution: Make sure that ThreadX does not need more than the provided heap memory (64KBytes in this example).	 
Read more in STM32CubeIDE User Guide, chapter: "Linker script".
    • The "tx_initialize_low_level.s" should be also modified to enable the "USE_DYNAMIC_MEMORY_ALLOCATION" flag.

Keywords

RTOS, Network, ThreadX, NetXDuo, UDP, UART

Hardware and Software environment

  • This application runs on STM32F429xx devices

  • This application has been tested with STMicroelectronics STM32F429ZI Nucleo boards Revision MB1137 B-01 and can be easily tailored to any other supported device and development board.

  • This application uses USART3 to display logs, the hyperterminal configuration is as follows:

    • BaudRate = 115200 baud
    • Word Length = 8 Bits
    • Stop Bit = 1
    • Parity = None
    • Flow control = None

How to use it ?

In order to make the program work, you must do the following :

  • Open your preferred toolchain

  • Optionally edit the file NetXDuo/App/app_netxduo.h and update the DEFAULT_PORT to connect on.

  • run the echotool utility on a windows console as following:

    c:\> echotool.exe  <board IP address> /p udp  /r  <DEFAULT_PORT> /n 10 /d "Hello World"

example :  c:\> echotool.exe 192.168.1.2 /p udp /r 6000 /n 10 /d "Hello World"

  • Rebuild all files and load your image into target memory

  • Run the application