New errors after getting the lenovo tab

[techknight]

EDIT:
Heck with it, My rambles wasnt getting much answer and probably didnt make any sense to anyone, So i gave up and got rid of prefix.

Conclusion:

Possible Bug alert in Asyncstreams Prefix
But in a nutshell the app crashes when using prefix mode IF the 4 bytes coming from the opposite end gets malformed in such a way that it isnt correct and doesnt correspond with the length of the datapacket.

4 bytes of the total packet length doesnt work. I have to send 3 0s, and then the packet length. Then it works. But if any of those 3 0s gets corrupt, and is NOT 0, it tries to allocate too much RAM for the incoming packet, crashing the device.

 

[thedesolatesoul]

I never used bluetooth but unless you post some code and what you are trying to do, noone will be able to help you,
From the logs it looks like you have a memory leak somewhere.

Where is the full stack trace for this error:

java.lang.OutOfMemoryError
at anywheresoftware.b4a.randomaccessfile.AsyncStreams $AIN.run(AsyncStreams.java:172)
at java.lang.Thread.run(Thread.java:856)

 

[thedesolatesoul]

If there was a way I could enable logging without the wifi being connected, I would. I think this is a lenovo problem, as my samsung tab2 and google G1 phone has none of these issues.

USB! USB is the fastest way and will not interfere with wifi/bluetooth. You can easily get the logs.

Without knowing what the exact error is (from the logs), how can you debug it.
By memory leak I meant something seems to be going over the allocated memory the OS has assigned to your process.

BTW which code do you need? I cant post the entire app because its systems control software for a commercial product.

We only need the code that causes the error. If you run with debugger attached, the logs will tell you the exact line number.

 

[techknight]

Hell with it. Put it in normal instead of prefix mode, and problem solved. I wanted prefix for data error redundancy, but its not... So out with it.

So, LRC checksumming of my datapackets should suffice. Should the Prefix mode bug get fixed, ill probably switch back.

 

[Erel]

But in a nutshell the app crashes when using prefix mode IF the 4 bytes coming from the opposite end gets malformed in such a way that it isnt correct and doesnt correspond with the length of the datapacket.

How come these bytes got malformed?

 

[techknight]

Radio issues. 99.5% of the time everything is fine. Thats my guess.

But that 0.5% of the time a byte or two gets corrupt in the prefix being receives, and it blows up the phone.

I wonder if its possible to get checks and balances put in the Async prefix to check for bad prefixes. Because when the prefix is bad, it tries to use all 4 bytes to open a buffer for the recieve, Even if the phone cant allocate the RAM required it still tries and of course, it crashes.

I would like to be able to specify the maximum receive length in the prefix mode. So, If i know my app is never going to handle more than 100 bytes at a time, set a cap of 100 bytes. Anything over this, throw the packet away and do NOT allocate the RAM.

The crash occures when java/android/async is trying to allocate an array or memory length larger than what is present in the phone, or app heap itself. so then the unhandled exception occures and the OS doesnt know how to handle it except to force quit the application. And in some cases, it kills the desktop manager and I have no menubar, or anything, loosing the android desktop background etc... and I have to reboot the entire tablet to recover.

 

[thedesolatesoul]

Radio issues. 99.5% of the time everything is fine.

Can you be sure of this? As far as I know, the lower levels of the network stack will deal with most radio issues, you will not see any corrupt data being sent up to the application layer.

 

[techknight]

Anyway, I turned prefix off and since my data communications contains a packet that has a length and an LRC, it doesnt matter anyway. So I updated the newdata routine to handle that, because without prefix the data packet never arrives all at once. it arrives in chunks.

Sub AStream_NewData (Buffer() As Byte) 'Serial Receive interrupt routine
If RxEnabled = False Then 
   Return
End If
RxPacket = RxPacket & BytesToString(Buffer, 0, Buffer.Length, "UTF8")
'Since we arnt using Prefix mode, The entire packet may not have arrived when this event is triggered. 
'Since we are doing length and checksummed packets, We test for a valid packet and length before releasing the packet.  
If Len(RxPacket) > 4 Then
   PacketLength = Len(RxPacket) / 2   'Length of packet
   TestLength = HexString(Mid(RxPacket, 3, 2)) 'Send Length byte
   TestLength = TestLength + 4       'Include header byte, Length byte, checksum byte, and character return (AVR Print) as part of the length. Ensure full data packet recpetion. 
   If TestLength = PacketLength Then
      RxHandler
      RxPacket = ""
   End If
End If
Return
End Sub

Lets me work ok without prefix, and I havent had any issues yet. no more crashing.

 

[techknight]

Can you be sure of this? As far as I know, the lower levels of the network stack will deal with most radio issues, you will not see any corrupt data being sent up to the application layer.

I have no other way of knowing... I understand that nothing will get corrupted when the packet arrives. But, there is still no guarantee that the transmission radio didnt produce the issue at that moment in time.

I am using a LM Technologies Bluetooth COM port radio at the other end. It is a high power radio that has about a 300 foot range in open spaces.

I know its not the Atmel AVR (BASCOM) code, Its setup to produce the prefix correctly. Here is the transmission code on my Acknowledge OK packet:

'We Drop here when a command process has succeeded, and no data has been requested or supported.
Sub Rsp90()
Prefixheader(1) = 0
Prefixheader(2) = 0
Prefixheader(3) = 0

If Ismaster = 0 Then
   If Slaveaddress <> 0 Then                                'If this board is configured as slave, we DONT respond.
      Reset Flags.4
      Reset Flags.6
      Exit Sub
   End If
End If

Packetbuffer = "120190"
Call Dochecksum
Packetbuffer = Packetbuffer + Hex(checksm)
Length = Len(packetbuffer)
Length = Length + 2
Prefixheader(4) = Length
Printbin Prefixheader(1) ; 4
Print Packetbuffer

Reset Flags.4
Reset Flags.6
End Sub

The packet sent in hex representation would be:

00 00 00 0A 31 32 30 31 39 30 38 33 0A 0D

0D is the carriage return, its part of the BASCOM-AVR Print statement.

I use Print, because I am working with HexStrings and not binary packets. But the Async has to be in binary, so its sent as binary.

the AVR code strips off the binary on a receive as It doesnt care about it, and this incoming direction NEVER has issues. its the outgoing direction.

Now I could work entirely in binary, But I am too lazy to do the conversions and all that jaz, So i did it this way and it works ok.