enet function cause censored on s32r

[yi-linhsieh]

Hi ,

I used S32DS to load enet program on s32r platform.

It's okay to transmit UDP packets.

but when I try debug (reload) the program again.

It usually shows "Device may be censored."

It is easier to reproduce when increase TX loading.  EX: for(k = 0; k < 1024; k++)   ==>  for(k = 0; k < 10240; k++)

I can't understanding why enet function cause censored.

Is any one know why it happens?

Yi-Lin

Kuan Hung Lin

Original Attachment has been moved to: enet_test1.7z.zip

[yi-linhsieh]

Hi Martin,

I got our PCB board. 

and it seems okay now.

Thank you for you help!

Regards,

Yi-Lin

[martin_kovar]

Hi,

I tested your code, but I am not able to reproduce your problem. Could you please clarify me following points:

- which cut of microcontroller you have?

- which debug probe you use?

- do you use NXP EVB or you have your own design?

Could you please send me step-by-step instructions, which leads to the error?

Regards,

Martin

PS: This error is false positive. ENET function does not cause device censoring. It seems it is some kind of bug. I need the information above to reproduce the issue on my side and eventually for logging it.

[yi-linhsieh]

Hi, 

Thanks for your response.

I tested  the code in S32R274 EVB. and using P&E USB multilink.

If you try to reproduce the problem,

1. you have to modify loop number in main() 

for(k = 0; k < 1024; k++)   ==>  for(k = 0; k < 10240; k++)  and compiler.

2. Make sure the ethernet  cable is connected. 

3. Using S32Ds to debug the program (not debug ram)

4. Free run the program. 

5. stop program and reload(debug) the program.

Regards,

Yi-Lin

[martin_kovar]

Hello Yi-Lin,

Now I can reproduce your problem, but it is not caused by S32 Design Studio debugger. I tested your project with Lauterbach debugger and after UDP transmission, I was not able to reset microcontroller any way. I had to disconnect JTAG connector, do Power-On-Reset and connect again.

I do not know, what is the root cause of this behavior, but I have observed it happening when transmission runs. When I commented ENET.TDAR.B.TDAR = 1, or disconnect UTP cable, microcontroller was OK.

I need more time to investigation this issue. I will write you back as soon as I have any other information.

Regards,

Martin

[yi-linhsieh]

Hello Martin,

I tried fnet network stack on S32R274 platform. 

It leads to the same problem.

Do you have any update?

[martin_kovar]

Hello,

I have not had enough time to investigate the issue deeper, but I have one tip. S32R daughter card has own Ethernet transceiver and also there is Ethernet transceiver on MPC57xx Motherboard. This could cause some issues. Could you please try to disconnect MPC57xx Motherboard transceiver (disconnect all jumpers connected to transceiver)?

Lauterbach shows, there is problem with reset. It is possible that one of enet pins holds reset in logical 1 and debugger cannot reset microcontroller correctly. I will do deeper investigation later.

Regards,

Martin

[yi-linhsieh]

Hi Martin,

Thanks for your response.

I don't have the MPC57xx Motherboard. 

I test the S32R daughter without motherboard and the ethernet cable  is direct connect with my PC.

So I think it might not motherboard's issue.

Regards,

Yi-Lin

[martin_kovar]

Hello Yi-Lin,

I am sorry for long delay. I did another investigation and after ENET transmission, microcontroller is in some strange state. So I have created service request to our application team to make sure, if there is a bug or some misconfiguration.

I will keep you inform about result.

Regards,

Martin

[yi-linhsieh]

Hello Martin,

Thanks for your information.

Enet is very import function.

I still waiting for your solution.

Regards,

Yi-Lin

[martin_kovar]

Hello Yi-Lin,

I received answer from application engineer.

This sounds like an issue we have encountered before, and we believe it is due to the socket used on the EVB. The socket is a low cost unit which may have undesirable inductance parasitics. The issue is currently under investigation via TKT320144 (on dpdm), which has found that under certain circumstances the IRC can become stuck leading to the device hanging and requiring a full power cycle to recover.

I tried the code you sent and I can also reproduce the issue here on my setup. I then tried the code on the Dolphin demo sensor board and as expected the issue does not occur, therefore I believe it is the known issue regarding the EVB socket.

So your code is correct. I hope you do not have use-case where you need to send so many packet in loop (as you send in your project).

If you have any other question, please feel free to write me back.

Regards,

Martin

[martin_kovar]

Hello Yi-Lin,

this is good to know. I have to start from different side. Please give me some time. I will do an investigation and if I do not solve it myself, I will contact application team.

Regards,

Martin