1

I have previously posted regarding the issue but haven't really found the problem. Recently, I found this post regarding detachbuffer and wonder if this could be the reason i encounter the problem.

I have my UART for RS485 using a FTDI USB to 485 cable connected to Raspberry Pi on Windows IoT Core. I set a dispatchertimer at every 1second to transmit polling to respective field devices. I am able to tx and rx the 485 data with no problem. However, after the polling loop to about 20 times it just crash and exited the debug mode. I used try & catch to trap the exception but could not get it. However, i manage to read the error message at the debug output pane - The program [0xBB0] PwD.exe' has exited with code -1073741811 (0xc000000d).

I wonder if i repeatedly transmit polling, dataWriteObject.DetachBuffer(); would cause the problem? Thanks.

snippets of my code are as follow;

 private void PollTimer_Tick(object sender, object e)
    {
        if (pollCounter <= maxDevice)
        {
            var a = pollCounter | 0x80;
            pollCounter++;

            TxAdr = Convert.ToByte(a);
            TxCmd = TxPoll;

            TxPollCard();

        }
        else pollCounter = 0;
    }

 private async void TxPollCard()
    {
        if (serialPort != null)
        {
            List<byte> data = new List<byte>();

            data.Add(TxHeader);
            data.Add(TxAdr);
            data.Add(TxCmd);

            TxChkSum = 0;
            foreach (byte a in data)
            {
                TxChkSum += a;
            }

            TxChkSum = (byte)(TxChkSum - 0x80);
            data.Add(TxChkSum);

            try
            {
                // Create the DataWriter object and attach to OutputStream
                dataWriteObject = new DataWriter(serialPort.OutputStream);

                dataWriteObject.WriteBytes(data.ToArray());

                Task<UInt32> storeAsyncTask;
                // Launch an async task to complete the write operation
                storeAsyncTask = dataWriteObject.StoreAsync().AsTask();

                UInt32 bytesWritten = await storeAsyncTask;
                
                dataWriteObject.DetachBuffer();
            }
            catch (Exception ex)
            {
                await Dispatcher.RunAsync(CoreDispatcherPriority.Normal, () =>
                {
                    MainStatusDisplay.Text = ex.Message;
                });
            }

        }
        else
        {
            await Dispatcher.RunAsync(CoreDispatcherPriority.Normal, () =>
            {
                MainStatusDisplay.Text = "No UART port found";
            });
        }
    }

Update:

Additional test i did which i disconnect the devices & keep transmitting without expecting response, it didn't crash. On the other hand, i stop transmit and only listen to the 485 bus, it didn't crash either.

mylim
  • 313
  • 4
  • 16
  • 2
    Add a wait before dataWriteObject.DetachBuffer();. You may be DetackBuffer before all the data is sent. The write data is putting the data into a stream and then the operating system is move the data to the UART when the buffer in the UART is not full. You could be running faster than UART can handle. Also make sure you have handshaking turned off preferably no wires attached to the CTS and RTS. I've seen cases like this with handshaking or cables with CTS/RTS causing crashes. – jdweng Oct 20 '20 at 15:54
  • @jdweng Thanks.. I only have Data+ & Data- connected..and no handshaking. `serialPort.Handshake = SerialHandshake.None;` I tried to add `await` in front of `dataWriteObject.DetachBuffer()` ... it shows error `iBuffer does not contain a definition for GetAwaiter` . – mylim Oct 20 '20 at 15:58
  • Just add a sleep(time). See : https://learn.microsoft.com/en-us/dotnet/api/system.threading.thread.sleep?view=netcore-3.1 – jdweng Oct 20 '20 at 16:10
  • @jdweng: OP is already awaiting the `StoreAsync()` call. It matters not whether the kernel is still buffering data out the port, it has already been transferred to the kernel-owned buffer. – Ben Voigt Oct 20 '20 at 16:41
  • @OP: Start with debugging, and take a look at the call stack when the SEH exception happens. – Ben Voigt Oct 20 '20 at 16:43
  • @Ben Voigt : Wrong. As I said it Async is only wait a very short period of time for the stream to be filled in c# application, and not wait for the transfer to UART to complete. Once in the stream the operating system does the transfer to the UART and application does not wait for the transfer to complete. So if you dispose the object before the data get put into UART you will loose data. – jdweng Oct 20 '20 at 16:51
  • "Once in the stream the operating system does the transfer to the UART". No. The operating system doesn't do anything with the data until it is safely stashed away in a buffer controlled by the UART driver. After that happens, it can be output on the actual serial port slowly as permitted by baudrate, flow control, etc. But the application-level buffer is no longer involved. If you dispose a "serial port" object and that calls CloseHandle on the serial port, you may lose data in the OS-controlled buffer. But freeing or reusing your buffer in the application memory space is no problem. – Ben Voigt Oct 20 '20 at 21:54
  • @jdweng @BenVoigt i tried adding `thread.sleep()` with 1000ms, 500ms, 200ms before `dataWriteObject.DetachBuffer();` ... same thing occur... Additional test i did.. i disconnect the devices & keep transmitting without expecting response .. it didn't crash.. on the other hand... if i dont transmit and only `listen` to the 485 bus... it didnt crash either.. – mylim Oct 21 '20 at 05:24
  • 1
    I have reproduced the issue on my device. But i found out that, if i start the app without debugging with Visual Studio, the app will not crash. – Michael Xu Oct 21 '20 at 07:38
  • @MichaelXu-MSFT meaning if I run the app on the device not in debugging it will not have the issue? I will try that.. Same time.. may I know what is causing the issue? – mylim Oct 21 '20 at 09:27
  • Check the date/timeon the executable in teh project bin folder and make sure the executable in the bin folder has been updated with all the changes. Often people only are recompiling the file in the release folder and not the debug folder. – jdweng Oct 21 '20 at 09:30
  • @jdweng I havent had any release for this project yet. Project still in debug. How does the date/time affect the serial communication? I am puzzled. – mylim Oct 21 '20 at 09:34
  • @MichaelXu-MSFT this most also probably related to my earlier ([post](https://www.example.com)) – mylim Oct 21 '20 at 09:38
  • 1
    Only if the debug executable is not getting compiled. The executable in the debug folder might be a month old while the release my be a few minutes old. – jdweng Oct 21 '20 at 09:46
  • @jdweng: An out of date binary is very unlikely to be the problem if the crash has been reproduced by MichaelXu – Ben Voigt Oct 21 '20 at 15:05
  • @MichaelXu-MSFT The same issue still persist even I run the program on raspberry pi not in debug mode. it will stop polling. – mylim Nov 11 '20 at 07:12

0 Answers0