×

Discussion Board

Results 1 to 8 of 8
  1. #1
    Regular Contributor
    Join Date
    Feb 2006
    Posts
    150

    Arrow SOS: SYMBIAN PANIC ERRORS in a BT connecton! Can you solve this?

    Hi people!

    That issue is driving me crazy! I think it isn't due to a firmware/J2ME implementation problem but I'm not sure. Maybe I'm doing something wrong!

    I've been working 6 months with a Nokia 9500 phone. I'm programming a bluetooth application which intends to connect with other BT device (SPP profile). The application reads information from one side , processes it and then sends it to a server which hostes in a PC.

    My problem takes place in the Nokia 9500 which paints the most of times the same SYMBIAN PANIC ERROR and closes inmediately the app when I'm reading data from the SPP BT connection or when I'm starting to read from it.
    It's very rare because it sometimes appears other times doesn't appear and I've tested the same program in other MIDP 2.0 mobiles (Nokia N70 and Nokia 6680) and I've never observed that SYMBIAN PANIC ERROR.

    This particular panic error is:

    Program: Main
    Reason code: KERN-EXEC
    Number Code: 3

    Do you know reading this Symbian message if I may do something wrong in the Inquiry BT process?

    On the other hand, other SYMBIAN PANIC messages appear when the BT
    connection is dropped and I try to RECONNECT to the same device! I make
    the reconnection 3-5 seconds after the link is dropped! In Nokia 9500 the reconnection fails and appears other SYMBIAN ERRORS like this:

    Program: jes-dc-java-comms@14435d OR jes-e3-java-comms@14435d ...
    Reason code: E32USER-CBase
    Number Code:40

    But in N70 the reconnection works perfectly! Do I have to wait any time (10-30 seconds or more) before trying to reconnect?

    I've read some information about those PANIC ERRORS in the SYMBIAN website (http://www.symbian.com/developer/tec...erence%2eindex) but I haven't found the way to sort this problem out!

    In other Thread (http://www3.symbian.com/faq.nsf/0/F1...D?OpenDocument)a SYMBIAN developer says that it's a manufacturer's problem because
    the J2ME-BT implementation has an underlying defect in the implementation!

    What about udgrading my firmware? Will the update change the VM and fix the possible J2ME bugs ?

    Some SW and HW DATA: firmware version=4.51(0), HW revision =1, SW revision=256 and
    SW build=592 (Data obtained from SysExplorer application).

    Thanks in advance. I admit all type of suggestions!
    Last edited by Summerman; 2006-08-21 at 11:59.

  2. #2
    Registered User
    Join Date
    Dec 2005
    Location
    Brazil
    Posts
    1,884

    Re: SOS: SYMBIAN PANIC ERRORS in a BT connecton! Can you solve this?

    Hi Summerman,

    Regarding the description on the link you provided (below), it seems you'll need a firmware update in order to get rid of this problem, the error description is very clear in this regard, there's a problem with the underlying implementation...and considering your code works well on other devices the it seems the problem is really related to your Nokia 9500.

    http://www3.symbian.com/faq.nsf/0/F1...D?OpenDocument

    I am not sure if you will get that fixed by updating or if your firmware version is the latest, though.

    I've checked one issue regarding 9500 and BTooth that's available on Forum_Nokia_Technical_Library_v1_24_en.chm, look for it here in FN. Below is the summary:

    2.7 Using Bluetooth Serial Port in MIDlets
    "When the Bluetooth Serial Port Profile (RFCOMM protocol) is used, reading incoming stream is sometimes interrupted with IOException. The read() method of the InputStream class may throw an IOException if the other end has closed the stream while the InputStream is still reading it.
    Another issue is that the InputStream cannot use a bigger array than 512 bytes when reading stream. A bigger byte array may crash the MIDlet."

    Solution:

    "Solution to the IOException issue: Ensure that the InputStream.read() has finished before closing the output stream in the other end.
    Solution to the stream size issue: Do not use a bigger byte array than 512 bytes. Read the input stream in a loop or keep the whole length of the stream under 512 bytes.
    Generic workaround to both issues: Use L2CAP connection instead of SPP (RFCOMM), if appropriate. This is feasible when you have access to the L2CAP protocol in both ends of your application (for example, connections between two devices).
    "

    HTH!

    Juarez Jr
    Last edited by juarezjunior; 2006-08-21 at 13:54.

  3. #3
    Regular Contributor
    Join Date
    Feb 2006
    Posts
    150

    Thumbs up Re: SOS: SYMBIAN PANIC ERRORS in a BT connecton! Can you solve this?

    Thanks for your help, JuarezJunior! My firmware version, as you know, is 4.51(0) and the latest is 5.22. I don't know if this update changes the KVM implementation and improves the J2ME implementation.

    Do you know something about this issue?

    Before upgrading the firmware I must demonstrate that the Nokia 9500 J2ME implementation fails and therefore my code is OK!

    I must tell you that my application needs to use RFCOMM connection (SPP) and the OutputStream closing doesn't depend on my device: this issue depends on the other end device!

    In resume: my device has to use Serial Port Profile because is reading from a BT device which only has the BT SPP and it can't control the OutputStream closing because it takes place when the other end BT device is dropped! When this issue occurs, my device try to reconnect inmediately, but I'm testing if I can avoid the PANIC ERRORS waiting some time (30-60-120 seconds)!

    Thanks in advance! I wait for some of your suggestions!

  4. #4
    Registered User
    Join Date
    Dec 2005
    Location
    Brazil
    Posts
    1,884

    Re: SOS: SYMBIAN PANIC ERRORS in a BT connecton! Can you solve this?

    Hi Summerman,

    "Do you know something about this issue?"
    No, i don't. I think only the FN Experts will be able to reply on that regarding that they may have access to what changed from firmware version 4.51(0) to the latest, 5.22 as you informed. I cannot further help you in this regard, unfortunately.

    I do understand the SPP issue and also that the workaround by FN doc will not meet your requirements.

    "Generic workaround to both issues: Use L2CAP connection instead of SPP (RFCOMM), if appropriate. This is feasible when you have access to the L2CAP protocol in both ends of your application (for example, connections between two devices)."

    BR,

    Juarez Jr

  5. #5
    Registered User
    Join Date
    Mar 2003
    Posts
    4,105

    Talking

    Same here on Nokia 9300i with latest firmware
    Code:
    Program: jes-31f-java-comms@…
    Reason code: KERN-EXEC
    Number Code: 3
    and this MIDlet works on so, so many phones … I think this will be a longer debugging session, this time. Lukily, it is 100% and quite easy reproducable, here. Anyway, I more and more like that phone for its screen dimensions. I play a bit, perhaps I find something especially because Nokia Series 80 is dead since the Nokia E90.
    Last edited by traud; 2007-02-27 at 13:01.

  6. #6
    Registered User
    Join Date
    Feb 2007
    Posts
    18

    Re: SOS: SYMBIAN PANIC ERRORS in a BT connecton! Can you solve this?

    Hi All,

    I think I ran into the same problem when trying to read from a BT GPS device. Please take a look at the post below, any help would be GREATLY appreciated!

    http://discussion.forum.nokia.com/forum/showthread.php?t=102222

    Thanks!
    Örs

  7. #7
    Registered User
    Join Date
    Dec 2005
    Location
    Brazil
    Posts
    1,884

    Re: SOS: SYMBIAN PANIC ERRORS in a BT connecton! Can you solve this?

    Hi traud,

    "I play a bit, perhaps I find something especially because Nokia Series 80 is dead since the Nokia N90."

    I think the same as you. Nokia seemts to be focusing on S60 as we can conclude. Smart choices by Nokia
    Juarez Alvares Barbosa Junior - Brazil

  8. #8
    Registered User
    Join Date
    Mar 2003
    Posts
    4,105
    -1 is returned when the underlying RFComm packet is finished. This causes EOFException in DataInput classes. As there should never be an EOF in Bluetooth IMHO, simply ignore it. However, then the MIDlet might crash. Although garzotto provided a solution, already, waiting only after -1 was returned, fixed this issue for me in all my MIDlets especially in tight loops.
    Code:
    package xy.yourcompany.java.io // change this line
    import java.io.IOException;
    
    public class InputStream extends java.io.InputStream {
    	
        protected java.io.InputStream in;
        private final byte[] b = new byte[1];
    
        public InputStream(java.io.InputStream in) {
            this.in = in;
        }
        public int read() throws IOException {
            int r = -1;
            while (r < 0)
            {
                r = in.read(b);
                try {
                    if (r < 0) {
                        Thread.sleep(500);
                    }
                }
                catch (InterruptedException ie) {}
            }
            return (0x000000ff & b[0]);
        }
        public int available() throws IOException {
            return in.available();
        }
        public void close() throws IOException {
        	in.close();
        }
        public synchronized void mark(int readlimit) {
        	in.mark(readlimit);
        }
        public synchronized void reset() throws IOException {
            in.reset();
        }
        public boolean markSupported() {
            return in.markSupported();
        }
    }
    If this trick is a performance issue in your case, please debug this further and tell us how long one should wait.

    You place the above code in your JAR and call it after obtaining the StreamConnection from Connector.open(…)
    Code:
    StreamConnection con = (StreamConnection) Connector.open("btspp://…");
    DataInputStream in = new DataInputStream(new xy.yourcompany.java.io.InputStream(con.openInputStream()));
    I am unsure which phone models are affected, my current guess is Nokia S60 2nd Edition Feature Pack 1 and Nokia Series 80 2nd Edition. In the archives you find reports for Nokia 6620, Nokia 7610 and Nokia 9300i which sound similar.

    And, yes, this debug session was a bit longer than usual.
    Last edited by traud; 2008-06-07 at 12:04. Reason: Updated about EOFException/-1, changed from Yield to Wait, avoid a Samsung issue (high bits are always 1) and how to fix this more easily rather tha rewriting a DataInput class.

Similar Threads

  1. 7650 Symbian Connect
    By alexbas in forum Symbian Tools & SDKs
    Replies: 4
    Last Post: 2008-11-16, 10:40
  2. setting of Series 60 MIDP SDK for Symbian OS version 1.2 for networking
    By servigo in forum Mobile Java Networking & Messaging & Security
    Replies: 2
    Last Post: 2003-07-31, 07:47
  3. Replies: 0
    Last Post: 2003-06-13, 01:11
  4. Replies: 0
    Last Post: 2003-06-13, 01:10
  5. Replies: 0
    Last Post: 2003-06-13, 01:09

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
×