TMS320C6457: Inquiries about NDK library

Additional question.

1)
Since the current problem has not been solved, one of the countermeasures is to force a DSP reset.

At this time, if you check the network log, you will see NIC Link is Down → NIC Link is UP
Is this Link Down/Link Up controlled by DSP?

If it is the DSP, it takes about 5 seconds from Link Down to Link Up.
Is it possible to change this 5 seconds arbitrarily?

2)
Is there any possibility that the use of a debug monitor will affect the frequency of transfer stops?

3)
Is it theoretically possible that reducing the value of the "TCP send buffer size" setting will reduce the frequency of send () stops?

Hello Miyazaki-san & Ishida-san,

Please note that this is a "no design support" part as per the product page. We no longer have expertise on this part or its software, so we are limited in the support we can offer.

I am going to reassign your thread to another team member to see if they can help. Please ping the thread if you do not get a response in a day or so.

Regards,

Nick

Takayuki Miyazaki said:

• Customer would like to know all "Return value" of send() API.
• Are APIs/macro functions of NDK library "ANSI C" compliant?

Hi Miyazaki-San,

Has customer looked into packages/ti/ndk/stack/inc folder for all the macro defines on the return values?

Customer can go through the socket.c under (ti/ndk/stack/fdt folder) - source code is released with PDK.

Also, there is a UG for NDK:

https://software-dl.ti.com/simplelink/esd/simplelink_msp432e4_sdk/2.30.00.14/docs/ndk/NDK_Users_Guide.html

(I do not see compiled return values there).

PDF version: https://www.ti.com/lit/pdf/SPRU523K

If customer wants to rebuild NDK for debugging:

Here is the link: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/947275/faq-how-do-you-rebuild-the-ndk

AFAIK, it is ANSI C complaint.. did customer note any issue? Please let me know.

Hello Aravind,

Thank you for your clarification.

Ishida-san,

If you have any further questions or you need more detail information, please put your inquires into this E2E thread, please?

Best regards,

Miyazaki

Hi Miyazaki-San,

I will wait for further response from customer.

thanks

I am a hardware engineer, not a software engineer.
I checked the source code you provided, but it was difficult to understand.
I'm sorry, but can you please tell me where I can find the specific place to check or the source code that you have listed?

The following is an additional question

What is the source code for outputting ARP (e.g., ARP Announcement for 192.168.0.21) when connecting to a LAN with an external device?
In which library function is this done?
　
Similarly, in which function is the source code to output ARP (e.g. Who has 192.168.11.8? Tell 192.168.11.1)?
Tell 192.168.11.1) in which library function?

Hi Ishida-San,

If you are looking for BSD send() function not NDK_send() function, they are under the "ns" package. The BSD send() function return values are available under "ns_2_60_01_06\source\ti\net\slneterr.h" file.

Sample values to look for:

/*****************************************************************************/
/* Macro declarations */
/*****************************************************************************/

#define SLNETERR_RET_CODE_OK (0L) /**< Success */

#define SLNETERR_GENERAL_DEVICE (-6L) /**< General device error */

/* BSD SOCKET ERRORS CODES */

#define SLNETERR_BSD_SOC_ERROR (-1L) /**< Failure */
#define SLNETERR_BSD_ENXIO (-6L) /**< No such device or address */
#define SLNETERR_BSD_INEXE (-8L) /**< socket command in execution */
#define SLNETERR_BSD_EBADF (-9L) /**< Bad file number */
#define SLNETERR_BSD_ENSOCK (-10L) /**< The system limit on the total number of open sockets, has been reached */\

...

...

...

The ARP implementation is done under:

ndk/stack/lli/lliin.c:

to receive the ARP packet and send the reply, you can refer to the function:  void LLIRxPacket( PBM_Pkt *pPkt )

Thanks

Thank you for your answer.
I was able to confirm the ARP.

Regarding the return value of the send function.
In the source code we have created, there are only two return values for the send function: "send data size" and "-1" in case of an error.We do not expect any other return values.

Is this a mistake?Are there any other return values?

Additional questions

During TCP/IP communication, when I plug and unplug the LAN cable, communication is restored for a short time, but if I unplug it for more than ten seconds, the PHY is powered down.

How many seconds does it take to cause an error?
Also, please tell me which function detects the error.

Please tell me all the functions that make settings to the PHY.

Hi Ishida-San,

Is this the PHY that is used on the TI EVM or something from your custom board?

NDK library does not program the PHY. There is a transport (NIMU ETH layer, under packages\ti\transport\ndk\nimu\src\v6) interacts programs the necessary programming for PHY and other ethernet functionalities. Note that the NIMU function is built on top of the ti/drv/emac. So, you would need to check the emac drv source code as well. (packages\ti\drv\emac\src\v0)

I do not see any such time programmed there. I think, it may be specific to PHY hardware or something like that. Probably, you may need to refer to the PHY HW spec.

Thanks

Thanks for the answer.

I will check the HW specification of the PHY.

However, is the source code for resetting and initializing the PHY correct?
(packages/ti/csl/c6457/csl_c6457_src/src/mdio/csl_mdio.c)

I was wondering if you could give me an answer to my previous question about the return value of the send function.

Hi Ishida-San,

Takeshi Ishida said:

Regarding the return value of the send function.
In the source code we have created, there are only two return values for the send function: "send data size" and "-1" in case of an error.

Just wanted to check with you, if you are writing your own send function or are you asking for the NDK send function? I am not aware of any issues in NDK_send() function.

Again, please note that this product has no design support available: 

https://www.ti.com/product/TMS320C6457

Takeshi Ishida said:

However, is the source code for resetting and initializing the PHY correct?
(packages/ti/csl/c6457/csl_c6457_src/src/mdio/csl_mdio.c)

Can you please let me know how did you get the CSL for this SoC? If you provide the TI SW link, I can take a look on this and confirm.

Thanks

I'm sorry for the late reply.

> Sorry! I do not understand this.. Are you referring to NDK send() or did you create your own send function? AFAIK, there is no issue in send()function.

Answer to your question

It's not our own send function.
We just want to know the entire return value of the NDK send().

> Can you please let me know how did you get the CSL for this SoC?

Answer to your question

I don't have a software engineer who was in charge of this project in the past, and I may be wrong, but I think it is the following URL

http://software-dl.ti.com/sdoemb/sdoemb_public_sw/bios_mcsdk/01_00_00_08/index_FDS.html

Hi Ishida-San,

Thanks for the inputs.

Sorry to mention that we do not have support for BIOS MCSDK releases. 

As you noticed, NDK send() returns SOCKET_ERROR (-1) or txSize (send data size).

Thanks

＞　Sorry to mention that we do not have support for BIOS MCSDK releases.

Please let me check again.
Looking at the description of "bios_mcsdk_1_00_00_08_release_notes.pdf" in the following URL, C6457 is supported, isn't it?

software-dl.ti.com/.../index_FDS.html

Hello Ishida-San,

To clarify: Yes, that SDK release is for C6457. However, TI released that software back in 2012. As per my initial reply to your post, we no longer have the in-house expertise to answer hardware questions about C6457, or to support the software released for it almost 10 years ago.

Regards,

Nick

Thank you for your answer.
I understand in general.

If I have any more questions, please let me know.

Thank you.

I'm sorry many times, but let me check it additionally.

Code ourselves for unsupported CSL

Can I change it and use it?　At our responsibility.

Hello Ishida-san,

You are welcome to modify the CSL drivers. We will not be able to help with the modifications, or with debugging the modifications.

Regards,

Nick