Problems receiving what I thought were four HEX bytes?


Closed Thread
Results 1 to 9 of 9
  1. #1
    Join Date
    Mar 2009
    Location
    Colorado
    Posts
    378

    Default Problems receiving what I thought were four HEX bytes?

    I am using a ConnectOne iWiFi MiniSocket in my embedded microcontroller application that is programmed with PBP version 2.6. Each MiniSocket has a unique embedded serial no. that I am trying to recover and then send with an FTP message to a Website. The code I am using to recover the serial no. from the module is as follows:
    Code:
    SEROUT2 TX, 84, [ "AT+iRP5",$d ,$a ] 'Report the chip serial number
    SERIN2 RX ,84, 8000 ,BOOT ,[ serial_no[0],serial_no[1],serial_no[2],serial_no[3] ]
    WRITE 51,serial_no[0]
    WRITE 52,serial_no[1]
    WRITE 53,serial_no[2]
    WRITE 54,serial_no[3]
    The AT+iRP5 command is sent serially to the MiniSocket which is supposed to respond with the four HEX bytes ( 14 00 26 88 ) of the serial no.
    I am attempting to receive those four HEX bytes into a four byte array named serial_no.
    To check on what was received before sending it via FTP the four WRITE statements are used during testing to check post-run EEPROM to see what values were received. The values being received in EEPROM are 48 28 13 13 rather than 14 00 26 88. I can't figure out why the received values are different than what I know they should be from the published module seerial no.

    Can anyone tell me what is going wrong here on the receipt of the serial_no[] values.

  2. #2


    Did you find this post helpful? Yes | No

    Default Re: Problems receiving what I thought were four HEX bytes?

    Off the top of my head ! I THINK that you have the wrong brackets [] for serial_no, I think they should be () eg serial_no(0)

  3. #3
    Join Date
    Aug 2003
    Posts
    985


    Did you find this post helpful? Yes | No

    Default Re: Problems receiving what I thought were four HEX bytes?

    That looks like correct syntax for an array as long as it was defined as:
    serial_no var byte [4] 'define array
    or whatever.

  4. #4
    Join Date
    Mar 2009
    Location
    Colorado
    Posts
    378


    Did you find this post helpful? Yes | No

    Default Re: Problems receiving what I thought were four HEX bytes?

    Thans, Art. My variable is defined in code variables as follows:
    Code:
    serial_no   VAR BYTE[4]   ' Array stores unique serial no.of iChip in hex format
    So like you say, it looks like it should work. However, it is still writing the value to EEPROM as 48 28 13 13 rather than 14 00 26 88 which is what the HEX values should be for the serial number of the device. This is driving me crazy! Been troublshooting this problem for a couple of weeks.

    Any further suggestions would be greatly appreciated.

    John Ellis

  5. #5
    Join Date
    Nov 2003
    Location
    Wellton, U.S.A.
    Posts
    5,924


    Did you find this post helpful? Yes | No

    Default Re: Problems receiving what I thought were four HEX bytes?

    Try skipping a location when writing to the EEPROM.
    Dave
    Always wear safety glasses while programming.

  6. #6
    Join Date
    Mar 2009
    Location
    Colorado
    Posts
    378


    Did you find this post helpful? Yes | No

    Default Re: Problems receiving what I thought were four HEX bytes?

    Quote Originally Posted by mackrackit View Post
    Try skipping a location when writing to the EEPROM.
    I tried your suggestion, Dave, and it doesn't appear to make any difference.
    I have posted my latest code below and still have the same problem.
    Hopefully someone can review this code and tell me why the HEX version of the serial_no is not being read or posted as it really is in the chip. I know the code from the chip because of use of the ConfigUtility from ConnectOne that reads the code from the chip separately from my code. It is 14 04 26 88 but is being read and posted by my code as 48 28 13 13. Any help appreciated!

    I first use the following code to read the iChip serial_no from the MiniSocket module and store it in the EEPROM of my MCU so I can see it on a post-run test to see what was read/stored.
    Code:
            SEROUT2 TX, 84, [ "AT+iRP5",$d ,$a ] ' Command the Minisocket to report the chip serial number and write it to EEPROM in MCU
            SERIN2 RX ,84, 8000 ,BOOT ,[ serial_no(0),serial_no(1),serial_no(2),serial_no(3) ]
            WRITE 51,serial_no(0)
            WRITE 52,serial_no(1)
            WRITE 53,serial_no(2)
            WRITE 54,serial_no(3)
    Then when I receive an hourly driven alarm interrupt from my RTC I execute the following FTP routine to send the serial_no to my web site for posting and usage in PHP code on the website. It shows up on the website as the same values that were stored in the EEPROM as described above and not what the actual serial_no is known to be. The extra labels listed in this routine are to provide repeat paths for each SERIN2 statement in case of the WAIT failure in order to improve the reliability of the over all code in making a complete communications session.
    Code:
    FTP_serial_no:    'FTP the chip serial number
    '============
         Session2:    ' Command MiniSocket to Open Session 2
           SEROUT2 TX,84,["AT+iFOPN:lodestarassoc.com:jellis00,password",$d,$a]
           SERIN2 RX,84,4000,Session2,[WAIT("I/000")] :PAUSE 100
         Directory2:  ' Command MiniSocket to set the target directory name
           SEROUT2 TX,84,["AT+iFCWD:000,TempAlarm",$d,$a]
           SERIN2 RX,84,1000,Directory2,[WAIT("I/OK")]
         File2:         ' Command MiniSocket to set the target file name abd send serial_no in HEX format
           SEROUT2 TX,84,["AT+iFSTO:000,","serial_no.txt",$d,$a]
           SERIN2 RX,84,1000,File2,[WAIT("I/OK")]
           SEROUT2 TX,84,["AT+iFSND:000,8:",HEX2 serial_no(0),HEX2 serial_no(1),HEX2 serial_no(2),HEX2 serial_no(3),$d,$a]:PAUSE 200
         Close2: 'Close file
           SEROUT2 TX,84,["AT+iFCLF:000",$d,$a]
           SERIN2 RX,84,1000,Close2,[WAIT("I/OK")]:PAUSE 100
         Off2:   'Close Session
           SEROUT2 TX,84,["AT+i!FCLS:000",$d,$a]
           SERIN2 RX,84,1000,Off2,[WAIT("I/ONLINE")]:PAUSE 100
    RETURN
    Last edited by jellis00; - 14th January 2012 at 20:42.

  7. #7
    Join Date
    Nov 2005
    Location
    Bombay, India
    Posts
    953


    Did you find this post helpful? Yes | No

    Default Re: Problems receiving what I thought were four HEX bytes?

    Is there a way you can confirm the baud rate the device is seeing? One way to check could be to send some command that does something verifiable on the module like flashing some led or something. This way you can confirm that the device is indeed operating at the correct baud rate. Then comes the return information check. Are you able to see simple things like maybe a AT OK coming from the module? If not, is it possible you might be seeing inverted data?

    These are some thoughts that come to mind

  8. #8
    Join Date
    Mar 2009
    Location
    Colorado
    Posts
    378


    Did you find this post helpful? Yes | No

    Default Re: Problems receiving what I thought were four HEX bytes?

    I am confident that the baud rate is not a problem. Otherwise none of the commands I am sending to the module would result in the results I am seeing posted on the web site.
    Yes, I am seeing the OK returns on the commands, so I don't think that is a problem.
    Just the fact that my command to send the array sereial_no[ ] ends up with the same value posted on the web site that I am reading back from EEPROM tells me that the commands are getting through.

    However, I don't understand what you mean by "inverted data"....can you please explain?

  9. #9
    Join Date
    Nov 2005
    Location
    Bombay, India
    Posts
    953


    Did you find this post helpful? Yes | No

    Default Re: Problems receiving what I thought were four HEX bytes?

    Ok, my doubts about baud rate are clarified. Inverted data means I was thinking you are seeing the complement of the data due to the RxD line not being inverted by a line driver IC.

Members who have read this thread : 0

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

Tags for this Thread

Posting Permissions

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