In response to a report of failures when calling SerialDeviceRead() at a very high rate with the SERIAL_READ_NON_BLOCK flag set a deadlock condition was discovered in the internal functions UARTSerialDeviceReceive() and UARTSerialDeviceTransmit() due to the locking behavior of a secondary call to another function.

A fix has now been developed which addresses the issue and after extensive testing no further occurrences of the deadlock condition have been observed. If you are using the serial device API in your projects we recommend updating to the latest version of the RTL in order to apply this fix.

For details of how to apply the latest source to your Ultibo core installation and rebuild your run time library see the wiki page Building from Source or watch the Building the RTL video on YouTube.

With the version of Core on 19 Mar. I never saw the hanging after booting. When it works I see lots of messages in both the main & logging window.After Sending the kernel7.img

./run_demos.sh 185 gpstftping gps kernel7.imgto ultibo system 192.168.1.185tftp> tftp> Sent 2835896 bytes in 10.3 secondsSometimes it works okay and starts receiving the serial data from the gps only 9600 baud.Let me know if I can provide additional information.

develone wrote:With the version of Core on 19 Mar. I never saw the hanging after booting. When it works I see lots of messages in both the main & logging window....Sometimes it works okay and starts receiving the serial data from the gps only 9600 baud.Let me know if I can provide additional information.

Without having a GPS to test with we connected your project up to another Pi that was setup to send continuous messages over the UART.

After many reboots, power cycles and other tests we cannot reproduce anything that seems like what you describe.

Are you able to provide a sample of what the gps data looks like?

Can you narrow it down any further, for example leave out the call to the test() function, to come up with something we can reproduce?

Can you revert your UART unit to the version prior to this fix and retest if the problem occurs or not?

Ultibo wrote:In response to a report of failures when calling SerialDeviceRead() at a very high rate with the SERIAL_READ_NON_BLOCK flag set a deadlock condition was discovered in the internal functions UARTSerialDeviceReceive() and UARTSerialDeviceTransmit() due to the locking behavior of a secondary call to another function.

A fix has now been developed which addresses the issue and after extensive testing no further occurrences of the deadlock condition have been observed. If you are using the serial device API in your projects we recommend updating to the latest version of the RTL in order to apply this fix.

For details of how to apply the latest source to your Ultibo core installation and rebuild your run time library see the wiki page Building from Source or watch the Building the RTL video on YouTube.

As usual industrial-strength support. I just submitted $299 for April 2018 forum support which is the usual 99 plus 100 for this repair and another 100 in honor of Paul's basic work in getting the rpi3b/zerow bluetooth started. I have enough in place to add ble peripheral mode to the users' demo this week. Regards, Mark.

I think that this may have been the problem. The program that computes the checksum also writes to the file gps.dat.I just tftp the fileReceived 17059799 bytes in 59.7 secondsSince I have ofp = fopen("gps.dat","a+"); I deleted the file and it started right away.

Since the file was so big, the writes were causing it to take a log time.and hang.I have not seen the framing errors Let me if this makes sense, that the long write time was hanging it up?.