Nov 16, 2016
11:07 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Nov 16, 2016
11:07 AM
Hello,
Is there a way to use Modbus TCP without RTOS? (for XMC4700)
Please, all advices are welcome.
I also asked here:
https://www.infineonforums.com/threads/4498-Modbus-TCP
Regards,
Koumak
Is there a way to use Modbus TCP without RTOS? (for XMC4700)
Please, all advices are welcome.
I also asked here:
https://www.infineonforums.com/threads/4498-Modbus-TCP
Regards,
Koumak
- Tags:
- IFX
6 Replies
Attachments are accessible only for community members.
Nov 21, 2016
12:42 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Nov 21, 2016
12:42 PM
Nov 24, 2016
06:13 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Nov 24, 2016
06:13 AM
Jesus,
Thank you very much.
Now it works 🙂
Regards,
Koumak
Thank you very much.
Now it works 🙂
Regards,
Koumak
Not applicable
Mar 10, 2017
06:09 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Mar 10, 2017
06:09 AM
Hi Jesus. I'm trying out 'MODBUS_TCP_MODE_NOOS_XMC47.zip'. Main has just the following while loop:
while(1)
{
sys_check_timeouts();
}
sys_check_timeout() normally takes microseconds to run.
But I've noticed that sys_check_timeouts() takes a whole 2 seconds to run, about a second after the while loop starts running.
Is this normal?
Can it be avoided?
Can it occur at other times, apart from a second after the while loop starts running.
The 2 second 'hang' in sys_check_timeouts(), will prevent other actions I want to perform within the while-loop, from being performed.
I found out this 2 second 'hang' was occurring, by turning an LED off just before the sys_check_timeouts() call, and turning it back on after
Most of the time, the LED just glows half-brightness, showing it's being turned on and off very rapidly.
But for the 2 second period mentioned, the LED goes off completely.
If I pause during the 2 second period, the debugger shows the code is within the following retry loop,
XMC_ETH_MAC_PHY_MAX_RETRIES being set to 65535 iterations!
:
/* Read physical layer and obtain status */
XMC_ETH_MAC_STATUS_t XMC_ETH_MAC_ReadPhy(XMC_ETH_MAC_t *eth_mac, uint8_t phy_addr, uint8_t reg_addr, uint16_t *data)
{
uint32_t retries;
:
/* Poll busy bit during max PHY_TIMEOUT time */
retries = 0U;
do
{
if ((eth_mac->regs->GMII_ADDRESS & ETH_GMII_ADDRESS_MB_Msk) == 0U)
{
*data = (uint16_t)(eth_mac->regs->GMII_DATA & ETH_GMII_DATA_MD_Msk);
return XMC_ETH_MAC_STATUS_OK;
}
++retries;
} while (retries < XMC_ETH_MAC_PHY_MAX_RETRIES);
:
Alternatively, within the following retry loop, likewise 65535 iterations:
/* Write physical layer and return status */
XMC_ETH_MAC_STATUS_t XMC_ETH_MAC_WritePhy(XMC_ETH_MAC_t *eth_mac, uint8_t phy_addr, uint8_t reg_addr, uint16_t data)
{
uint32_t retries;
:
/* Poll busy bit during max PHY_TIMEOUT time */
retries = 0U;
do
{
if ((eth_mac->regs->GMII_ADDRESS & ETH_GMII_ADDRESS_MB_Msk) == 0U)
{
return XMC_ETH_MAC_STATUS_OK;
}
++retries;
} while (retries < XMC_ETH_MAC_PHY_MAX_RETRIES);
:
Do you know if I can reduce XMC_ETH_MAC_PHY_MAX_RETRIES to something lower than 65535, and still accord with the TCP/IP spec? With Modbus TCP spec?
XMC_ETH_MAC_PHY_MAX_RETRIES is set within xmc_eth_mac.h:
:
* The Ethernet MAC (ETH) is a major communication peripheral that supports 10/100
* MBit/s data transfer rates in compliance with the IEEE 802.3-2002 standard. The ETH
* may be used to implement internet connected applications using IPv4 and IPv6. The
* ETH also includes support for IEEE1588 time synchronisation to allow implementation
* of Real Time Ethernet protocols.
:
/**********************************************************************************************************************
* MACROS
*********************************************************************************************************************/
:
#define XMC_ETH_MAC_PHY_MAX_RETRIES (0xffffUL) /**< Maximum retries */
:
Best regards,
David King
while(1)
{
sys_check_timeouts();
}
sys_check_timeout() normally takes microseconds to run.
But I've noticed that sys_check_timeouts() takes a whole 2 seconds to run, about a second after the while loop starts running.
Is this normal?
Can it be avoided?
Can it occur at other times, apart from a second after the while loop starts running.
The 2 second 'hang' in sys_check_timeouts(), will prevent other actions I want to perform within the while-loop, from being performed.
I found out this 2 second 'hang' was occurring, by turning an LED off just before the sys_check_timeouts() call, and turning it back on after
Most of the time, the LED just glows half-brightness, showing it's being turned on and off very rapidly.
But for the 2 second period mentioned, the LED goes off completely.
If I pause during the 2 second period, the debugger shows the code is within the following retry loop,
XMC_ETH_MAC_PHY_MAX_RETRIES being set to 65535 iterations!
:
/* Read physical layer and obtain status */
XMC_ETH_MAC_STATUS_t XMC_ETH_MAC_ReadPhy(XMC_ETH_MAC_t *eth_mac, uint8_t phy_addr, uint8_t reg_addr, uint16_t *data)
{
uint32_t retries;
:
/* Poll busy bit during max PHY_TIMEOUT time */
retries = 0U;
do
{
if ((eth_mac->regs->GMII_ADDRESS & ETH_GMII_ADDRESS_MB_Msk) == 0U)
{
*data = (uint16_t)(eth_mac->regs->GMII_DATA & ETH_GMII_DATA_MD_Msk);
return XMC_ETH_MAC_STATUS_OK;
}
++retries;
} while (retries < XMC_ETH_MAC_PHY_MAX_RETRIES);
:
Alternatively, within the following retry loop, likewise 65535 iterations:
/* Write physical layer and return status */
XMC_ETH_MAC_STATUS_t XMC_ETH_MAC_WritePhy(XMC_ETH_MAC_t *eth_mac, uint8_t phy_addr, uint8_t reg_addr, uint16_t data)
{
uint32_t retries;
:
/* Poll busy bit during max PHY_TIMEOUT time */
retries = 0U;
do
{
if ((eth_mac->regs->GMII_ADDRESS & ETH_GMII_ADDRESS_MB_Msk) == 0U)
{
return XMC_ETH_MAC_STATUS_OK;
}
++retries;
} while (retries < XMC_ETH_MAC_PHY_MAX_RETRIES);
:
Do you know if I can reduce XMC_ETH_MAC_PHY_MAX_RETRIES to something lower than 65535, and still accord with the TCP/IP spec? With Modbus TCP spec?
XMC_ETH_MAC_PHY_MAX_RETRIES is set within xmc_eth_mac.h:
:
* The Ethernet MAC (ETH) is a major communication peripheral that supports 10/100
* MBit/s data transfer rates in compliance with the IEEE 802.3-2002 standard. The ETH
* may be used to implement internet connected applications using IPv4 and IPv6. The
* ETH also includes support for IEEE1588 time synchronisation to allow implementation
* of Real Time Ethernet protocols.
:
/**********************************************************************************************************************
* MACROS
*********************************************************************************************************************/
:
#define XMC_ETH_MAC_PHY_MAX_RETRIES (0xffffUL) /**< Maximum retries */
:
Best regards,
David King
Mar 11, 2017
01:29 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Mar 11, 2017
01:29 AM
Hi David,
Quick response:
I had same problem... my first solution was disable autonegotiation
(i.e.: .enable_auto_negotiate = true
change to .enable_auto_negotiate = false ... and some related things - set speed and duplex manually)
But if you need autonegotiation enable - you can change the waiting on autnegotiation complete do while loop to if ... and than you can only check if is complete in your neverending loop 😉
Hope this helps.
Best regards,
Koumak
Quick response:
I had same problem... my first solution was disable autonegotiation
(i.e.: .enable_auto_negotiate = true
change to .enable_auto_negotiate = false ... and some related things - set speed and duplex manually)
But if you need autonegotiation enable - you can change the waiting on autnegotiation complete do while loop to if ... and than you can only check if is complete in your neverending loop 😉
Hope this helps.
Best regards,
Koumak
Not applicable
Oct 28, 2017
09:14 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Oct 28, 2017
09:14 PM
Hi,
I am using XMC4700 Modbus tcp with RTOS.
when i connect XMC directly to a PC .
1. Ping for the IP is good
2. Response is better.(I use FNC CODE -15)
3. It works continuous.
But when i connect it to a Huge network.
1.Ping is not good.(Time out occurs often)
2.As timeout is often request/response is not good.
3.Device lag in performance.
Can i get some help on this?
Is this a issue in networking or our XMC Ethernet module?
Is this a issue in networking or our XMC ethernet module?
I am using XMC4700 Modbus tcp with RTOS.
when i connect XMC directly to a PC .
1. Ping for the IP is good
2. Response is better.(I use FNC CODE -15)
3. It works continuous.
But when i connect it to a Huge network.
1.Ping is not good.(Time out occurs often)
2.As timeout is often request/response is not good.
3.Device lag in performance.
Can i get some help on this?
Is this a issue in networking or our XMC Ethernet module?
Is this a issue in networking or our XMC ethernet module?
Jan 17, 2020
01:23 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jan 17, 2020
01:23 AM
Hi,
I am Italian, sorry for my English
How do I receive and send a string of characters by TCP/IP?
is it possible to use the XMC4500 board for communication with the MODBUS protocol?
Is there an example of MODBUS TCP / IP for XMC4500?
the XMC4700 / 4800 MODBUS TCP Client Example is compatible for the XMC4500 board?
I am Italian, sorry for my English
How do I receive and send a string of characters by TCP/IP?
is it possible to use the XMC4500 board for communication with the MODBUS protocol?
Is there an example of MODBUS TCP / IP for XMC4500?
the XMC4700 / 4800 MODBUS TCP Client Example is compatible for the XMC4500 board?