Weird problem with Debugin


Closed Thread
Results 1 to 10 of 10
  1. #1
    Join Date
    Jan 2010
    Posts
    51

    Default Weird problem with Debugin

    This is my code and my problem explained. I cannot store a byte into a variable:
    Code:
    '-----------------------CONFIGURATION----------------------
    DEFINE OSC 20
    Include "modedefs.bas"
    #CONFIG
        ifdef PM_USED
            device  pic16F877A, xt_osc, wdt_on, lvp_off, protect_off
        else
    	__Config _HS_OSC & _WRT_256 &_WDT_OFF &_PWRTE_ON &_BODEN_ON & _LVP_OFF  & _CP_ALL &_CPD_ON
        endif
    #ENDCONFIG
    
    @ ERRORLEVEL -306
    DEFINE DEBUG_REG PORTC
    DEFINE DEBUG_BIT 6
    DEFINE DEBUG_BAUD 9600
    DEFINE DEBUG_MODE 1
    
    DEFINE DEBUGIN_REG PORTC
    DEFINE DEBUGIN_BIT 7
    DEFINE DEBUGIN_MODE 0
    
    '--------------------REGISTERS-------------------------------
    PAUSE 100
    ADCON1=7
    CMCON=7
    OPTION_REG=%10000111
    TRISA=0 : PORTA=0
    TRISB=0 : PORTB=0
    TRISC=%10000000 : PORTC=0
    TRISD=0 : PORTD=0
    TRISE=0 : PORTE=0
    CCP1CON=0
    '----------------------------------------------------------------------
    
    LED Var PortD.1
    B0 Var byte
    
    
    
    '--------------------The below does not work i.e. LED does not toggle--------------
    Main:
    b0=0
    	Debugin [b0] ' Tried STR B0\1 as well but no luck
    	if b0="1" then GoSub TOG
    	Pause 200
    Goto Main
    '--------------------Change the Above with the following : The below works i.e. LED does toggle--------------
    Main:
    	Debugin [WAIT ("1")] ' I tried many inputs but only when I send 1 it works. So it does realises 1 somehow
    	GoSub TOG
    	Pause 200
    Goto Main
    
    
    
    Tog:
    	Toggle PortD.1
    Return
    What am I missing? please help.

  2. #2
    Join Date
    Oct 2005
    Location
    Sweden
    Posts
    3,516


    Did you find this post helpful? Yes | No

    Default Re: Weird problem with Debugin

    Hi,
    You know that the sender is sending '1' but have you verified that it is sending ONLY a '1' - ie a single byte?
    If, for example, the sender is sending 'xyz1abc' then the first example won't work because b0 will then contain 'x'. The second example will work since it automatically discards the 'xyz' part of the string.

    /Henrik.

  3. #3
    Join Date
    Jan 2010
    Posts
    51


    Did you find this post helpful? Yes | No

    Default Re: Weird problem with Debugin

    Quote Originally Posted by HenrikOlsson View Post
    Hi,
    You know that the sender is sending '1' but have you verified that it is sending ONLY a '1' - ie a single byte?
    If, for example, the sender is sending 'xyz1abc' then the first example won't work because b0 will then contain 'x'. The second example will work since it automatically discards the 'xyz' part of the string.

    /Henrik.
    Is there any tool available which can be installed on computer and can get all the bytes and may be auto determine the baud rate to check this? (Apart from Microcode Studio with serial communicator as it is not working)

  4. #4
    Join Date
    Oct 2005
    Location
    Sweden
    Posts
    3,516


    Did you find this post helpful? Yes | No

    Default Re: Weird problem with Debugin

    Hi,
    Google for serial port sniffer and you should find plenty of programs. Another REALLY handy tool is logic analyzer with protocol decoding. I've got a Saleae LOGIC and it's just a great little tool to use for things like this as it lets you see what is ACTUALLY going down the wires.

    Since you have another thread on a similar subject open I suspect the two to be about the same problem. The serial communicator in MCS works just fine, but it can only display ASCII data. If your device isn't sending pure ASCII data then it won't display it properly which MIGHT be why you see the byte count going up but no data being displayed. Then, of course, if the polarity is wrong - as Robert mentioned in the other thread, it won't work either.

    In the code you posted you have the mode (the polarity) set differently for DEBUG vs DEBUGIN.

    /Henrik.

  5. #5
    Join Date
    Dec 2004
    Location
    USA
    Posts
    36


    Did you find this post helpful? Yes | No

    Default Re: Weird problem with Debugin

    You beat me to it Henrik.

    www.saleae.com

  6. #6
    Join Date
    Jan 2010
    Posts
    51


    Did you find this post helpful? Yes | No

    Default Re: Weird problem with Debugin

    Thanks. That makes some sense now. I tried experimenting more with it and realized that ASCII is not the format (blame the Chinese).
    Has anyone used this: http://www.serialmon.com as a serial port sniffer?

    Also Debug and Debugin both work as mode 0. At that time I was only checking Debugin so left debug as mode 1 (please ignore it in the code above)

  7. #7
    Join Date
    Jan 2010
    Posts
    51


    Did you find this post helpful? Yes | No

    Default Update

    The character is coming in some UTF8 format! Does someone knows how to handle this type?

  8. #8
    Join Date
    Jan 2010
    Posts
    51


    Did you find this post helpful? Yes | No

    Default Re: Update

    Ok, here is the update. The serialMon pic is attached. The first HEX code is when I receive a '4' and the second is when I receive 'a'.
    I tried modifying the code and a few versions of it actually, but nothing worked. How do I capture the value coming as in the pic attached.

    My attempts were:
    1) b0...b4 var byte
    Debugin [B0,skip 1,B1,skip 1,b2,skip 1,b3,skip 1,b4]
    DIDN'T worked

    2) B0,B1 Var word : B2 var byte
    Debugin [B0,B1,B2]
    DIDN'T worked

    Any further pointers pleaseName:  Capture.PNG
Views: 271
Size:  8.7 KB?

  9. #9
    Join Date
    Oct 2005
    Location
    Sweden
    Posts
    3,516


    Did you find this post helpful? Yes | No

    Default Re: Weird problem with Debugin

    Hi,
    34 is the ASCII code (in HEX) for '4' and 61 is the ASCII code (in HEX) for 'a' so the actual data you want to capture is the fifth byte in the received packet. How about
    Code:
    DEBUGIN[WAIT (1), B0]    ' Wait for the 01 part of the string then grab the next byte
    or
    Code:
    DEBUGIN[SKIP 4, B0]    ' Skip the first four bytes, grab the fifth.
    /Henrik.

    EDIT: Or, if it's actually the 01 part you want to capture (and it's NOT the ASCII code for the digit 1 by the way) then perhaps DEBUGIN[SKIP 3, B0]
    Last edited by HenrikOlsson; - 4th June 2013 at 07:03.

  10. #10
    Join Date
    Jan 2010
    Posts
    51


    Did you find this post helpful? Yes | No

    Default Job done!

    Quote Originally Posted by HenrikOlsson View Post
    Hi,
    34 is the ASCII code (in HEX) for '4' and 61 is the ASCII code (in HEX) for 'a' so the actual data you want to capture is the fifth byte in the received packet. How about
    Code:
    DEBUGIN[WAIT (1), B0]    ' Wait for the 01 part of the string then grab the next byte
    or
    Code:
    DEBUGIN[SKIP 4, B0]    ' Skip the first four bytes, grab the fifth.
    /Henrik.

    EDIT: Or, if it's actually the 01 part you want to capture (and it's NOT the ASCII code for the digit 1 by the way) then perhaps DEBUGIN[SKIP 3, B0]
    JOB DONE! Cheers for the help

Similar Threads

  1. Weird Random problem
    By Del Tapparo in forum mel PIC BASIC Pro
    Replies: 1
    Last Post: - 15th August 2012, 23:06
  2. Weird Problem
    By isaac in forum General
    Replies: 9
    Last Post: - 22nd September 2008, 20:30
  3. DebugIn problem
    By Mutiaz in forum mel PIC BASIC Pro
    Replies: 1
    Last Post: - 2nd January 2006, 16:51
  4. Weird Oscillator Problem
    By eoasap in forum mel PIC BASIC Pro
    Replies: 2
    Last Post: - 17th December 2005, 15:21
  5. Debugin problem
    By moby in forum mel PIC BASIC Pro
    Replies: 7
    Last Post: - 11th September 2004, 16:12

Members who have read this thread : 1

You do not have permission to view the list of names.

Posting Permissions

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