#trmd_error

1 messages · Page 1 of 1 (latest)

twilit zephyrBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1414570989399838821

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

empty minnow
#

hi there!

#

can you share the serial number of the Terminal device with this issue?

shadow shell
#

It happens on a number of terminals. One is: WPC323211043502.

#

Here are some device logs from the critical events on one of our stations.

The USB re-enumeration happens at line 31. The first failure signal at 61 (USB_NOT_READY_OR_CABLE_DISCONNECTED), the internal failure in line 79 and the "fake" reconnection success at line 98-101.

📎 error_logs_stripe_redacted.txt
pliant holly
#

Hey! Taking over for my colleague.

shadow shell
#

Hi @pliant holly ! We're mostly following that guide yes. Although the specific section you linked to (Automatic reconnection on application start) is not something we have done. We always have only one reader connected via USB, and we always connect to the first reader we discover.

pliant holly
#

Are you setting val autoReconnectOnUnexpectedDisconnect = true ?

shadow shell
#

No. We are getting that error after the terminal does its daily FIRMWARE_SELF_TEST and SECURITY_REBOOT.

pliant holly
#

Do you reboot your POS app too during that period ?

shadow shell
#

The logs in error_logs_stripe_redacted.txt pasted above show it quite clearly, I think.

The device starts its daily security reboot, and then the terminal performs an unexpected extra disconnect:
class=ReactiveReaderStatusListener message=handleReaderDisconnect cause=USB_NOT_READY_OR_CABLE_DISCONNECTED

Note that this is about 6 hours after our daily restart, so the system would have been alive here for quite some time and connected. The regular battery read operations before 10:48 all succeeded as they should, indicating no issues.

Do you reboot your POS app too during that period ?

No. The POS app is not restarted in the same time period.

pliant holly
#

Also, do you implement any custom logic under override fun onDisconnect(reason: DisconnectReason) { ?

pliant holly
#

Wait, according to the logs, the reader got connected at the end. Is that error blocking to the connection flow ?

shadow shell
#

Also, do you implement any custom logic under override fun onDisconnect(reason: DisconnectReason) { ?

Yes. There is some code that is effectively the following:

if (!isReconnecting) scheduleRediscovery()

Although, as shown in the critical logs I pasted above, this was not called at all.

Wait, according to the logs, the reader got connected at the end. Is that error blocking to the connection flow ?

Yes, the SDK reported after this entire flow that the connection was successful. However, it is quite clearly not as all subsequent calls to the Terminal results in an error similar to what is shown in the file subsequent_error.txt: COMM_LINK_UNINITIALIZED.

pliant holly
#

scheduleRediscovery()
And so you are doing a reconnect here ? if so that exaplins why there is duplicate reconnection?

#

One done automatically by the sdk (autoReconnectOnUnexpectedDisconnect=true) and one by your integration

shadow shell
#

And you are facing this always 🤔 ? after each reboot ?

No, it is a bit fuzzy. Sometimes the USB_NOT_READY_OR_CABLE_DISCONNECTED happens after the initial reconnection from the SECURITY_REBOOT happens. If this is the case, the SDK automatically reconnects again and this is successful.

twilit zephyrBOT
pliant holly
#

Have you had the chance to debug your flow and see that isReconnecting is true in that case ?

#

Otherwise, there is a duplciate reconnection to the reader...

shadow shell
#

And so you are doing a reconnect here ? if so that exaplins why there is duplicate reconnection?
One done automatically by the sdk (autoReconnectOnUnexpectedDisconnect=true) and one by your integration

Yes, I thought so too. But in the above logs that callback is not even called. I don't think that is the main culprit.

Have you had the chance to debug your flow and see that isReconnecting is true in that case ?

But let me try to remove as much extra fluff as possible and have only the single reconnection path via the internal handling in the SDK. I'll try to test that code.

Since this error only occurs on the FIRMWARE_SELF_TEST event (as far as we can see) it might take some time before I get back to you with the results. I have some more stations I can test against that have such events coming up soon, but they might not trigger the issue.

pliant holly
#

But let me try to remove as much extra fluff as possible and have only the single reconnection path via the internal handling in the SDK. I'll try to test that code.
Yes please, make sure to keep only the auto reconnection or disable the auto reconnect and use your own logic.

#

Since this error only occurs on the FIRMWARE_SELF_TEST event (as far as we can see) it might take some time before I get back to you with the results. I have some more stations I can test against that have such events coming up soon, but they might not trigger the issue.
Yeah no worries, take your time. Even if this thread got closed, open a new one and it will have reference to this old one.

wraith eagle
#

👋 taking over for my colleague. Let me know if there's any follow-up Qs I can answer!