Problems receiving what I thought were four HEX bytes?

[jellis00]

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.

        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.

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

[Jerson]

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

[jellis00]

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?

[Jerson]

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.