Hi team,
a customer is having an issue when trying to close the UART port with .DiscardInBuffer() and .Close(). The issue comes up if and only if, the module has the corresponding Iris’s RS232 transceiver off.
The thing is that this only happens with a single module and with any Iris CB this is tested on, so it is probably an RMA, but I wanted to check with you first.
To reproduce the issue, basically, you disable RS232-B and C with SODIMM_104 to 0. COM2 is open but not transmitting anything. COM1 and COM3 are connected to external peripherals but not set and not opened, but the module is receiving data (that it is ignoring).
The issue is that the module cannot close the application correctly after calling the mentioned 2 functions. More so, the module 1st core jumps to 100% and the other 3 stay at around 40% and after a few tens of seconds and error comes up (asking for the exact error message). Turning on SODIMM_104 back to 1, to enable the RS232 transceiver, the issue solves and the application correctly turns off.
The customer basically just wants to be able to gracefully close COM2 and the application.
Kind regards,
Alvaro.
Hi @alvaro.tx ,
I guess the 2 mentioned functions are part of some serial library from .net framework… i’m not familiar with what the exactly do, but from what you describe i would guess that somewhere in the .net code there is a wait for some control line (probably CTS), and that is the reason you see a difference if the RS232 transceiver is off.
Can you try to see if the problem is also there with a native tool like serialdiag?
https://share.toradex.com/2ou6e2wke7rpsxt
Hi @germano.tx , thanks. I have an update from the customer after forwarding your info:
We are not really sure what happens but when the communication is released, the following happens:
For the bottom five marks, at the OPEN, there is no change (the change below remains as it is even for another port)
At CLOSE, COM1 = all OFF, COM2 = Ring only ON, COM3 = CTS only ON
CLOSE completed immediately
When connecting to our board (data is sent only to COM1 and COM3):
COM1: The bottom 5 marks are all turned off at OPEN. At CLOSE, it closes in about 2 to 3 seconds, and the mark remains OFF.
COM2: The five marks at the bottom are unchanged from the state before OPEN. Only Ring is turned on at the time of CLOSE. CLOSE closes immediately
COM3: The lower mark turns ON only for CTS. Closed in about 2 to 3 seconds at CLOSE
The bottom mark remains the same.
It looks normal and COM2 isn’t stuck.
So it seems like the issue is withing the .NET library for this… How should we proceed? I think it would be a matter of adding some extra logic to avoid falling into the bug but not sure if we should take this as RMA in any case. Waiting for your feedback.
