sw_serial_to_ethernet.zip(2.1.0) exception issue

[goodfeather]

Dear Sirs,
We are testing sw_serial_to_ethernet.zip(2.1.0)+sliceKit 1V1L2 on our virtual serialport driver and Win 7 test tool. each CMOS Rx is connected to its Tx. test tool sends 600 bypse to one port of SliceKit ,following a sleep time(based on baudrate),then sends again. Another thread will read data from the port.8 channels work meantime.
Under 14400 baudrate, it will work well for some time, such as 20 minutes receiving 1.4MB data, and then exception happens as the picture shows. If the baudrate is too high, why the exception happens after 20 minutes later? Or what I should do to avoid this? If test tool communicates with 8 Hercules on any baudrate, it works well all time.

Many thanks

xtcp_recvi exception.png

[srinie]

Hi,
The channel resource looks fine from the snapshot.
Can you check if your telnet sockets are active at the time of crash?
It will be good to check the states of other cores as well - can you post the dumpstate?


What is the actual setup? Is the device directly connected to the Win host?
Does the issue happens only if you loopback at the Serial side? When using Hercules, and with the actual setup in place i.e. no loopbacks, but Telenet sockets to respective Serial COM port connections, is there no crash!? Pls confirm.


Regards,
Srinie

[goodfeather]

Dear Srinie,
Thanks for your quick feedback. On your advice, we check our design and enlarge virtual serial port buf. We also monitor S2E's Tx/Rx word and Telnet Tx/Rx buffer, it's all ok.

Our Virtual serial port driver builts in WinSocket, and each virtual COM will connect to one port of SliceKit. The test tool has Write/Read threads for each Virtual COM. The Write thread will wirte the COM about 600bytes, and then sleep some time(to simulate sending baudrate), meanwhile the Read thread will read from the virtual COM repeatly.

We open 8 hercule TCP server in another PC with echo selection to test our Virtual COM and test tool. It will work over 3 hours without wrong.

The SliceKit exception often happens half an hour later. The Winsockets in virtual COMs still work at that time as the Wireshark picture shows.

We do this to get the dump state: 1)xrun s2e.xe 2)when exception happens, xrun --dump-state s2e.xe. Is it the right way?

Many thanks

[peter]

I'm not sure how much this will help you debug the issue, but the exception you are getting is due to the application trying to write to an address which is outside of the data array. The exception type (ET_ECALL) is from the code that checks the safety of the index. In this case it is writing to index 128 of a 128-byte data array.

If you move to the latest tools (the 14 tools) then it will give much better error reporting and tell you this automatically without having to decipher it from the register values and disassembly. You could try those tools to see whether you get different behaviour. I checked that sw_serial_to_ethernet (2.1.0) compiles with tools 14.

[goodfeather]

Dear Peter,
Many thanks for your quick feedback. Your info is very useful. We will check more. The very good news is that we can work on 14 tool. It is easier to use.

And would you please help check if we could transfer original XS1-L2 to XL200 just only re-design the port MAP?

Best Regards

[henk]

Hello goodfeather,

Most XS1-L2 designs should run on an XL216.

The differences that may stop this are: (assuming a 500 MHz part)

1) If only 4 logical cores are used in an XS1 tile, then they will run at 125 MIPS each. XL216 threads are limited to 100 MIPS. If you use five or more logical cores on each tile there is no difference.

2) The XS1-L2 has one PLL per physical core, so the two cores can in theory run at different speeds; it is unlikely that any program uses this.

3) IO timings will be slightly different.

Other than that, the XL216 can execute dual issue code (making C/XC programs run faster), and has a much faster communication path between the two tiles. That should mean that any code that just runs on an XS1-L2 will comfortably run on an XL216.

Hope this helps,
Henk