cannot find the reason for such a strange behavior
Code:
if Flg_15 = True then
@ INT_DISABLE RX_INT ; disable RX_INT interrupts
if Head = 15 & FlagTime = False then
W2 = 0
gosub XB1adc
gosub XB2adc
'gosub XB3adc
CIndex = 0
gosub XBee_Value
Pulse[0] = "1"
Pulse[1] = "5"
Pulse[2] = "0"
Pulse[3] = " "
Pulse[4] = "A"
Pulse[5] = "0"
Pulse[6] = "="
Pulse[7] = Decode[3]
Pulse[8] = Decode[2]
Pulse[9] = Decode[1]
Pulse[10] = Decode[0]
CIndex = 1
gosub XBee_Value
Pulse[11] = " "
Pulse[12] = "A"
Pulse[13] = "1"
Pulse[14] = "="
Pulse[15] = Decode[3]
Pulse[16] = Decode[2]
Pulse[17] = Decode[1]
Pulse[18] = Decode[0]
CIndex = 2
gosub XBee_Value
Pulse[19] = " "
Pulse[20] = "A"
Pulse[21] = "2"
Pulse[22] = "="
Pulse[23] = Decode[3]
Pulse[24] = Decode[2]
Pulse[25] = Decode[1]
Pulse[26] = Decode[0]
'------------------
CIndex = 3
gosub XBee_Value
Pulse[27] = " "
Pulse[28] = "A"
Pulse[29] = "3"
Pulse[30] = "="
Pulse[31] = Decode[3]
Pulse[32] = Decode[2]
Pulse[33] = Decode[1]
Pulse[34] = Decode[0]
CIndex = 4
gosub XBee_Value
Pulse[35] = " "
Pulse[36] = "A"
Pulse[37] = "4"
Pulse[38] = "="
Pulse[39] = Decode[3]
Pulse[40] = Decode[2]
Pulse[41] = Decode[1]
Pulse[42] = Decode[0]
CIndex = 5
gosub XBee_Value
Pulse[43] = " "
Pulse[44] = "A"
Pulse[45] = "5"
Pulse[46] = "="
Pulse[47] = Decode[3]
Pulse[48] = Decode[2]
Pulse[49] = Decode[1]
Pulse[50] = Decode[0]
'------------------
CIndex = 6
gosub XBee_Value
Pulse[51] = " "
Pulse[52] = "A"
Pulse[53] = "6"
Pulse[54] = "="
Pulse[55] = Decode[3]
Pulse[56] = Decode[2]
Pulse[57] = Decode[1]
Pulse[58] = Decode[0]
CIndex = 7
gosub XBee_Value
Pulse[59] = " "
Pulse[60] = "A"
Pulse[61] = "7"
Pulse[62] = "="
Pulse[63] = Decode[3]
Pulse[64] = Decode[2]
Pulse[65] = Decode[1]
Pulse[66] = Decode[0]
CIndex = 8
gosub XBee_Value
Pulse[67] = " "
Pulse[68] = "A"
Pulse[69] = "8"
Pulse[70] = "="
Pulse[71] = Decode[3]
Pulse[72] = Decode[2]
Pulse[73] = Decode[1]
Pulse[74] = Decode[0]
'------------------ Start CRC Function
W0 = 0
For DMY = 0 To 74
W0 = W0 + Pulse[DMY]
next DMY
DMY = W0//256
Pulse[75] = (255 - DMY)
' -------------------- End CRC function
gosub Check_Status
if Id > 51 then goto Skip_AK_15
Hserout ["AT+CIPSEND=",Id,44,55,55,13,10]
HSERIN 500,Skip_AK_20, [WAIT (">"), DMY]
Hserout [str Pulse\76,10]
endif
Skip_AK_15:
Flg_15 = false
@ INT_ENABLE RX_INT ; enable RX_INT interrupts
goto Skip_All
endif
The above subroutine reads adc values from two XBee and send the values out to a client, via ESP. All works fine except the CRC function that yields every time "253" whatever adc values are trasmitted!
All I am doing is to add up all the bytes in the word variable W0, extract the low byte and subtract this value to 255. But all I find everytime in Pulse[75] is the value 253. On the client the same algoritm yields the correct value!
I cannot find the reason for such a strange behaviour. What am I doing wrong? Any help is appreciated!
Pic 18F2620 @ 8 MHz + ESP8266 + XBee
Alberto
Re: cannot find the reason for such a strange behavior
Not very obvious since you haven't shown the variable declarations. I would guess your DMY variable is a word type which might be giving you the problem. Or, is there some other code section that is overwriting the Pulse[75] location?
Re: cannot find the reason for such a strange behavior
Thank you Jerson for your prompt answer!
I confirm that DMY variable is declared as byte and the byte variable pulse[75] is only used with the following two lines of code:
pulse[75] = (255 - DMY)
and
Hserout [str Pulse\76,10]
Both lines are inside the subroutine.
Alberto
Re: cannot find the reason for such a strange behavior
Quote:
I cannot find the reason for such a strange behaviour. What am I doing wrong? Any help is appreciated!
as jerson implies the problem most likely lies in the code not provided.
I suggest you make a complete compliable minimal example that demonstrates the problem, code snippets are impossible to debug if the problem is eslewhere
Re: cannot find the reason for such a strange behavior
I did it this once for you , problem is definitely elsewhere
and
Quote:
DMY = W0//256
Pulse[75] = (255 - DMY)
can be simplified to
Code:
#CONFIG
__config _CONFIG1, _FOSC_INTOSC & _CP_OFF & _WDTE_ON & _PWRTE_ON & _MCLRE_ON & _CLKOUTEN_OFF
__config _CONFIG2, _PLLEN_ON & _LVP_OFF
#ENDCONFIG
DEFINE OSC 32
OSCCON=$70
ANSELA=0
ANSELC=0
TRISA = %111110
TRISC = %11111111 ' set PORTC I/O
j var byte
k var word
l var byte
pulse var byte[76]
decode var byte[4]
w0 var word
dmy var byte
DEFINE DEBUG_REG PORTA
DEFINE DEBUG_BIT 0 ; if not used for pwr
DEFINE DEBUG_BAUD 9600
DEFINE DEBUG_MODE 0
pause 2000
Debug "Start",13 ,10
main:
gosub XBee_Value
Pulse[0] = "1"
Pulse[1] = "5"
Pulse[2] = "0"
Pulse[3] = " "
Pulse[4] = "A"
Pulse[5] = "0"
Pulse[6] = "="
Pulse[7] = Decode[3]
Pulse[8] = Decode[2]
Pulse[9] = Decode[1]
Pulse[10] = Decode[0]
' CIndex = 1
gosub XBee_Value
Pulse[11] = " "
Pulse[12] = "A"
Pulse[13] = "1"
Pulse[14] = "="
Pulse[15] = Decode[3]
Pulse[16] = Decode[2]
Pulse[17] = Decode[1]
Pulse[18] = Decode[0]
' CIndex = 2
gosub XBee_Value
Pulse[19] = " "
Pulse[20] = "A"
Pulse[21] = "2"
Pulse[22] = "="
Pulse[23] = Decode[3]
Pulse[24] = Decode[2]
Pulse[25] = Decode[1]
Pulse[26] = Decode[0]
'------------------
' CIndex = 3
gosub XBee_Value
Pulse[27] = " "
Pulse[28] = "A"
Pulse[29] = "3"
Pulse[30] = "="
Pulse[31] = Decode[3]
Pulse[32] = Decode[2]
Pulse[33] = Decode[1]
Pulse[34] = Decode[0]
' CIndex = 4
gosub XBee_Value
Pulse[35] = " "
Pulse[36] = "A"
Pulse[37] = "4"
Pulse[38] = "="
Pulse[39] = Decode[3]
Pulse[40] = Decode[2]
Pulse[41] = Decode[1]
Pulse[42] = Decode[0]
' CIndex = 5
gosub XBee_Value
Pulse[43] = " "
Pulse[44] = "A"
Pulse[45] = "5"
Pulse[46] = "="
Pulse[47] = Decode[3]
Pulse[48] = Decode[2]
Pulse[49] = Decode[1]
Pulse[50] = Decode[0]
'------------------
' CIndex = 6
gosub XBee_Value
Pulse[51] = " "
Pulse[52] = "A"
Pulse[53] = "6"
Pulse[54] = "="
Pulse[55] = Decode[3]
Pulse[56] = Decode[2]
Pulse[57] = Decode[1]
Pulse[58] = Decode[0]
' CIndex = 7
gosub XBee_Value
Pulse[59] = " "
Pulse[60] = "A"
Pulse[61] = "7"
Pulse[62] = "="
Pulse[63] = Decode[3]
Pulse[64] = Decode[2]
Pulse[65] = Decode[1]
Pulse[66] = Decode[0]
' CIndex = 8
gosub XBee_Value
Pulse[67] = " "
Pulse[68] = "A"
Pulse[69] = "8"
Pulse[70] = "="
Pulse[71] = Decode[3]
Pulse[72] = Decode[2]
Pulse[73] = Decode[1]
Pulse[74] = Decode[0]
'------------------ Start CRC Function
W0 = 0
For DMY = 0 To 74
W0 = W0 + Pulse[DMY]
next DMY
DMY = W0//256 ; why ?
Pulse[75] = (255 - DMY) ; why ?
; this line could replace the above two lines ie Pulse[75]=~w0
l=~w0 ;debug proof of above
j=w0 ;debug
' -------------------- End CRC function
Debug 13 ,10 ,#w0,9,#dmy,9,#j ,9,#Pulse[75],9 ,#l
pause 1000
goto main
XBee_Value:
for j=0 to 3
random k
Decode[j]=k
next
return
Re: cannot find the reason for such a strange behavior
Thank you Richard for the time taken to help me.
Yes the problem definetly was outside the subroutine. A stupid thing that I do very often, but this time I could not find it without somebody else telling me the problems was elsewhere! I did define byte variable Pulse as : "Pulse Var byte [75]" and wanted to load the 76th byte!
As far as not using the simpler code "Pulse[75] =~w0", it comes from having had several trouble in the past trying to tranfer the value "1" from a byte variable into a bit variable that I came to the conclusion that it was better working with bit to bit ; byte to byte and word to word.
So, "DMY = W0//256" was extacting the low byte from the word variable W0 into the byte variable "DMY"
Tested Pulse[75] =~w0 and found it working! so very likely the problem is only with bit variable!
Again, Tank you very much for the precious help received.
Alberto
Re: cannot find the reason for such a strange behavior
no problem alberto glad to see you got the issues resolved , it always serves as another good example of why code snippets for debugging are a pointless exercise.
snippets are fine to discuss or explain methodology but that's about all.
Quote:
it comes from having had several trouble in the past trying to tranfer the value "1" from a byte variable into a bit variable
if you can find the troublesome code i'd like to have a look at it with the view to seeing why it fails
Re: cannot find the reason for such a strange behavior
Quote:
if you can find the troublesome code i'd like to have a look at it with the view to seeing why it fails
Door_Lock var PortB.4
DmyFlg var bit
Report var byte[8]
Report[2] = !Door_Lock + 48 ' (didn't work! can't remember if it fails with True or false)
The work around was
DmyFlg = Door_Lock
DmyFlg = !DmyFlg
Report[2] = DmyFlg + 48
Sorry, not exactly as I mentioned in my previous post! I should say "bit into byte"
Alberto
Re: cannot find the reason for such a strange behavior
Quote:
The work around was
DmyFlg = Door_Lock
DmyFlg = !DmyFlg
Report[2] = DmyFlg + 48
I'M not sure you solution is correct
I did a few experiments as follows and conclude that,
if you invert a bit var (or bit alias) wether logical or bitwise only bit 0 in the result is valid , I you go on to use the result mathematically then all the other bits need to be masked off
for a correct calculation
D_Lck !D_Lck ~D_Lck D_Flg !D_Flg ~D_Flg R+!L R+~L R+!F R+~F
WRONG
0 65535 65535 0 65535 65535 47 47 47 47
CORRECT
0 255 65535 0 65535 65535 49 49 49 49
WRONG
1 65280 65534 1 65280 65534 48 46 48 46
CORRECT
1 0 65534 1 65280 65534 48 48 48 48
WRONG
0 65535 65535 0 65535 65535 47 47 47 47
CORRECT
0 255 65535 0 65535 65535 49 49 49 49
Code:
TRISC = %11101111 ' set PORTC I/O
D_Lck var Portc.4
D_Flg var bit
Report var byte[4]
DEFINE DEBUG_REG PORTA
DEFINE DEBUG_BIT 0 ; if not used for pwr
DEFINE DEBUG_BAUD 9600
DEFINE DEBUG_MODE 0
pause 2000
Debug "Start",13 ,10
Debug 13 ,10 ,"D_Lck",9 ,"!D_Lck",9, "~D_Lck",9, "D_Flg",9, "!D_Flg",9, "~D_Flg" ,9, "R+!L" ,9, "R+~L" ,9, "R+!F" ,9, "R+~F"
main:
PORTC.4=!PORTC.4
D_Flg=D_Lck
Debug 13 ,10 ,"WRONG"
Report[0] = !D_Lck + 48
Report[1] = ~D_Lck + 48
Report[2] = !D_Flg + 48
Report[3] = ~D_Flg + 48
Debug 13 ,10 ,#D_Lck,9 , #!D_Lck,9, #~D_Lck ,9, # D_Flg ,9, #!D_Flg, 9,# ~ D_Flg ,9,# Report[0] ,9,# Report[1] ,9,# Report[2] ,9,# Report[3]
Debug 13 ,10 ,"CORRECT"
Report[0] = (!D_Lck&1) + 48
Report[1] = (~D_Lck&1) + 48
Report[2] = (!D_Flg&1) + 48
Report[3] = (~D_Flg&1) + 48
Debug 13 ,10 ,#D_Lck,9 , #!D_Lck,9, #~D_Lck ,9, # D_Flg ,9, #!D_Flg, 9,# ~ D_Flg ,9,# Report[0] ,9,# Report[1] ,9,# Report[2] ,9,# Report[3]
pause 1000
goto main
Re: cannot find the reason for such a strange behavior
Today I have finaly found the time to implement the corrections to my code!
I have corrected the number of bytes int the array Pulse from 75 to 80. Next I have changed the following two lines of code:
Code:
DMY = W0//256
Pulse[75] = (255 - DMY)
with the simple form suggested by Richard
Compiled (22Kb of code) and updated the mcu. Power up and checked the packet transmitted via esp NOOOO! CRC is still txed as 253 all the time!
I did change the code again setting Pulse[75] = 123 (costant value) and re-checked. Well this time CRC was txed as 123! This proved that there is no byte corruption in the code, but the problem should be in setting the byte variable Pulse[75].
So I did change the setting of Pulse[75] = 123 to Pulse[75] = W0.lowbyte. Re-checked and it worked! CRC was txed correctly!
Hence I added : Pulse[75] = ~ Pulse[75] (inverting bits) and CRC was still txed as 253!!!!
I have removed Pulse[75] = ~ Pulse[75] and kept the CRC as the low byte of the packet sum that works!
But as I stated in this thread title: "I cannot find the reason for such a strange behavior"
Alberto
Re: cannot find the reason for such a strange behavior
try as I might I cannot produce any code where
Pulse[75] = ~W0
gives an incorrect result , the problem is elsewhere
I believe you are just masking the real problem/s
my challenge to you is :-
provide some fully compliable code that demonstrates the problem , I would bet you cannot
Pulse[75] = ~W0 converts to a 1 line macro when compiled
Code:
NOT?WB _w0, _Pulse + 00075h
where can that go wrong ?
Re: cannot find the reason for such a strange behavior
Quote:
my challenge to you is :-
provide some fully compliable code that demonstrates the problem , I would bet you cannot
To do that I should send to you all the project! Which is not possible!
But if you read better my first post, you will realize that I do see the CRC value of 253 on the client side, which is an android tablet. The CRC is sent by the pic via esp8266 (as you can easily observe from my code in post 1) and received by the android tablet (acting as a client via an apk written in basic4android by myself). Now the state of the art is: IF I DO NOT INVERT THE BYTE VALUE THE CRC RECEIVED IS CORRECT IF I DO INVERT INVERT THE BYTE VALUE THE CRC RECEIVED IS ALWAYS 253!
At this stage if we exclude the pic then the problem could be the esp or my apk! Need time to investigate in the meantime I will not invert the byte value (action that doesn't add much to the CRC) since everything works very well at the moment.
Alberto
Re: cannot find the reason for such a strange behavior
Quote:
To do that I should send to you all the project! Which is not possible!
that I understand but my point is that cause and effect are seemingly unrelated
Quote:
IF I DO NOT INVERT THE BYTE VALUE THE CRC RECEIVED IS CORRECT IF I DO INVERT INVERT THE BYTE VALUE THE CRC RECEIVED IS ALWAYS 253!
I don't doubt this is occurring for you but I believe the real cause is either elsewhere or that pbp has a major flaw . you can of course ignore this but it means your project may infact still have a flaw in it than will resurface some point further on . it should not be too difficult to simply paste together the relevant sections of you project code to demonstrate the failure point.
Re: cannot find the reason for such a strange behavior
Are you using any interrupts and if so of which type, pure ASM, DT-INTS with PBP ISR etc?
Perhaps PBP uses an internal variable when inverting and that variable gets corrupted by some other code (as in an interrupt).
I'm with Richard on this, to prove to yourself that is, or isn't, the actual inverting that is the problem you need to write a fully compilable snippet of code that shows this happening.
Richards code below shows (I think) the ~operator working but not really, at least not that I can see, in the exact way you're using it. Ie inverting the value within an array and writing the value back to the same location in the array. If there IS a problem with ~operator then you shouldn't have too much of a problem writing a small code snippet that the rest of use can verify.
Load an array up with values, print it out. Invert one of the values, print it out.
Don't use Bluetooth connections and android apps and other "weird" things, use a simple wired connection back to a terminal program.
/Henrik.
Re: cannot find the reason for such a strange behavior
Quote:
Richards code below shows (I think) the ~operator working but not really, at least not that I can see, in the exact way you're using it
thanks for that henrik lets see if we can agree to the problem definition it's possible the badgers have moved the goalposts.
my assumption is
the elements of a byte array [of less than 256 bytes] are summed from the first element to the penulitmate element into a word var
the low byte of this word var is inverted and placed into the last element.
the allegation is that :-
{note .w0 is the word sum of the array}
Code:
array[z] = ~w0 ; where w0 ia a word and the [byte]array is of z+1 elements
can produce and incorrect result in that, when read back array[z] is always $fd
or that
Quote:
IF I DO NOT INVERT THE BYTE VALUE THE CRC RECEIVED IS CORRECT
which i assume to be
Code:
array[z] = w0.lowbyte ; not inverted
is correct where as
Code:
array[z] = w0.lowbyte
array[z] = ~array[z] ; inverted
can produce and incorrect result in that, when read back array[z] is always $fd
Re: cannot find the reason for such a strange behavior
forgot to add I have tried 4 ways to implement this , none of which produces any error .
the subroutine below is run 1/sec in a working packet radio system with heaps or interrupts ,
no sign of sky falling yet
ps the result is displayed on a glcd using my glcd include as previously described in this forum
Code:
w0 var word
Report var byte[4]
albo var byte[4]
I var byte
alberto:
random w0
albo[0] = w0
random w0
albo[1] = w0
random w0
albo[2] = w0
w0=0
for i =0 to 2
w0=w0+albo[i]
next
crc: ; label to examine listing if required
;method 0
albo[3] = ~w0
Report[0] = albo[3]
;method 3
@ NOT?WB _w0,_Report+3
;method 2
Report[2] = w0 //256
Report[2] = ~ Report[2]
;method 1
asm
CHK?RP _w0
MOVF _w0,W
CHK?RP _Report
MOVWF _Report +1
COMF _Report +1,F
RST?RP
ENDASM
ecrc:
IF (Report[0]-Report[1])-(Report[2]-Report[3]) THEN
ARRAYWRITE BUFF,["The sky is falling",0]
led_cnt=KEY_BEEP_TIME ; set off the alarm
led_times=2 ; twice for good measure
ELSE
ARRAYWRITE BUFF,[#Report[0]," ",#Report[1]," ",#Report[2]," ",#Report[3],0]
endif
GLCD_CLR 0,43,100,8
GLCDC 1 ,43
GLCDSTR BUFF
return
Re: cannot find the reason for such a strange behavior
Following your suggestion I did check both bytes value (inverted and not inverted) txed by the pic 18f2620, removing everything and using a terminal connected to the pic in place of the esp8266. Well both bytes are txed correctly! This esclude the pic as responsible for such a wierd behavior and leave the esp8266 (the server) and the android (the client) as the probable responsible.
Next step is to write a small vb program using socket to act as a client and verify what the esp send out. I will post the result soon.
Alberto
Re: cannot find the reason for such a strange behavior
Finally I have got the VB program working! (I got rusty programming in VB)
The values are received as a string and decoded extracting the ASCII value from any single character of the string. Comparison with what has been sent was ok all the time for all the values including the CRC values (both inverted and not inverted).
So now I have to blame only ANDROID for the strange behavior, but still difficult to understand (at least for me) why the problem is only with the inverted byte! But since I have not too much knowledge of this OS, I could not dig any further at the moment.
Thanks to all.
Alberto
