TM4C1294NCPDT: TCP Setsocketopt issue

I have changed  for  static IP in .cfg  file.  I tried  tcp Echo with same changes and it works but due to semihosting it does not work with ought  debugger (on  power  reset) how  to solve this.

I  have checked that setsockopt does not return any thing  and remains there like while condition.

I have sure  about network as the development kit is directly connected to PC with Ethernet cable.

I will try 23 port and revert back to you.  

After all this test condition check , I shared you entire project as I have dought related to *cfg file  or NDK configuration.

Regards

Khodidas

Hi,

R & D said:

I tried  tcp Echo with same changes and it works but due to semihosting it does not work with ought  debugger (on  power  reset) how  to solve this.

You are saying that without semihosting, it is working. But with semihosting, it doesn't work. I never use semihosting before. I will suggest you try to get semihosting working on a simple program like a "hello world" type of example. If you can get the hello world working with semihosting then we can better assess if the problem is semihosting or what. 

  Here are some documentation about semihosting. 

https://software-dl.ti.com/ccs/esd/documents/ccs_semihosting.html

https://interrupt.memfault.com/blog/arm-semihosting

And also why do you want to use semihosting when you can just call System_flush() to display the message on the debugger console like below. 

if (setsockopt(server, SOL_SOCKET, SO_KEEPALIVE, &optval, optlen) < 0)
{
System_printf("Error: setsockopt failed\n");

/* SysMin will only print to the console when you call flush or exit */

System_flush();
goto shutdown;
}

The following System module APIs are useful in SYS/BIOS applications:
• System_printf() — Several functions similar to printf are provided. These include System_putch(),
System_sprintf(), System_vprintf(), System_aprintf() (arguments of type IArg), and
System_vsnprintf() (print a specified number of characters to a character buffer using a varargs list
to pass the arguments).

We strongly recommend that SYS/BIOS applications call System_printf() and its related functions in
place of the standard printf() function. The System module provides familiar printf-like functionality
but with fewer options. The memory footprint is much smaller than traditional printf(). System_printf()
allows users to specify to handling of the character output using a System provider (see Section 6.3.1
and Section 6.3.2).

The System module print functions are also recommended over Log module print functions, because
the System module functions are easier to use in many cases. The Log module is intended for use
with host instrumentation tools, and it has more options to disable/enable logging. See information
about UIA, which uses the Log module, in the System Analyzer User’s Guide (SPRUH43) for details.

• System_abort() — Your application can call this function when it needs to abort abnormally and
return an error message. This function allows you to return a string describing the error that occurred.
When this function is called, the System gate is entered, the SupportProxy's abort function is called,
and then System.abortFxn is called. No exit functions bound via System_atexit() or the ANSI C
Standard Library atexit() functions are called.

• System_flush() — This function sends any buffered output characters to the output device. It also
issues a break point to the IDE. Because this call halts the target, calling it can affect the details of
real-time execution. The destination for the output characters is determined by the SupportProxy
module.

• System_exit() — It is recommended that SYS/BIOS applications call BIOS_exit() instead of the
System_exit() function. The BIOS_exit() function performs internal cleanup before calling
System_exit(). The System_exit() may be called from a Task, but cannot be called from a Swi or Hwi.
• System_atexit() — Call this function to add an exit handler to the internal stack of functions to be
executed when System_exit() is called. The System.maxAtexitHandlers configuration property
controls how many exit handlers can be stacked. The default is 8.

Charles Tsai said:

ou are saying that without semihosting, it is working. But with semihosting, it doesn't work.

GNU examples for EK-TM4C123GXL fail to start unless debugger connected explains why semihosting means a program doesn't run unless the debugger is attached.

Charles Tsai said:

And also why do you want to use semihosting when you can just call System_flush() to display the message on the debugger console like below. 

My understanding is that when the GNU compiler is used for SYS/BIOS that System_flush() uses semihosting to get output on the debugger console.

Note that the CIO mechanism used by the TI compiler doesn't suffer the same problem, in that with the CIO mechanism if the debugger isn't attached then the program still runs - it is just that the console output gets discarded.

The difference is:

1. The CIO mechanism used by the TI compiler requires the debugger to set a breakpoint to capture the console output, so no debugger attached means the program still tuns.
2. The semihosting mechanism used by the GNU compiler uses a BKPT instruction to halt the target when the there is console output, and so if no debugger is attached the program just stays halted.

Hi Chester,

  Thanks for the explanation. The poster did mention he uses GNU compiler. I'm not familiar with the GNU toolchain. Do you think by unchecking the semihosting will solve the problem for GNU projects?

Hi 

Below link resolved issue of semihostig.

https://e2e.ti.com/support/legacy_forums/embedded/tirtos/f/ti-rtos-forum-read-only-archived/337566/gnu-examples-for-ek-tm4c123gxl-fail-to-start-unless-debugger-connected

Now My issue is  I  have  created server on one tm4c1294 board  and  client on other tm4c1294 device.

when i connect pc  as a  client with Tm4c  server it  works, as  well as pc  as a  server Tm4c1294 client connect to pc works,

but when connect  a tm4c client  to tm4c server  it  does not. I have connected both board  directly and through switch. Also y ethernet  cable is ok,  I cross  checked  Both devices IP  address  and  Mac address. they  are  different  and  within acceptable range.

Regards

Khodidas

HI,

Finally I resolved the issue, I just changed MAC address from {0x07, 0xff, 0x10, 0x1D, 0x6B, 0x17} to {0x70, 0xff, 0x10, 0x1D, 0x6B, 0x17}

and it works, but I don't understand why first byte of MAC not work on 0x07

Regards

Khodidas

R & D said:

but I don't understand why first byte of MAC not work on 0x07

Unicast vs. multicast (I/G bit) says:

The least significant bit of an address's first octet is referred to as the I/G, or Individual/Group, bit.

So, if the first byte of the MAC address is 0x07 the I/G bit is one which means a Multicast MAC address.

Whereas if the first byte of the MAC address is 0x70 the I/G bit is zero which means a Unicast MAC address.