Problems receiving what I thought were four HEX bytes?

[jellis00]

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:

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.

[aerostar]

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)

[Art]

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

[jellis00]

Thans, Art. My variable is defined in code variables as follows:

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

[mackrackit]

Try skipping a location when writing to the EEPROM.

[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.