How to trace out this bug?
T Chap
Posts: 4,223
I am using the 4port Tim Moore object. One cog is running an input from RS485(MAX3430 IC). The cog has a stack that is 48 longs. Another use of the 4port is driving an LCD from the main program. The program is very large and too much work to sift through if I posted it.
The problem I am having is that direction[1] keeps getting changed. Amongst the VAR items, the SerialReadBuffer is where the incoming 6 bytes of data come in from the RS485 input to the 4port. Changing the SerialReadBuffer to 16 has no effect on the issue. Direction[0] is always fine. Using a debug method to the LCD, the value of Direction[1] tends to change to 31, a decimal value 31 on the LCD using ser.dec(3, Direction[1]). The default for direction[1] is 1 on boot, and it only changes the second any data enters the RS485>port1 on the 4port.
I have added debug code to monitor if any of the stacks are getting ran over, but no stacks are running over. The test code for this is to park a dummy placeholder Long after each stack array, and monitor for a change.
I moved the Direction byte array to the bottom of the list, it no longer is affected when it gets placed somewhere else, so I know it is not being affected by it's name, but rather the location only. If I monitor instead ResponseArray[66], the same change takes place. ResponseArray is not in use at all.
I have concluded that this is some type of bug using the 4port, possible due to the object being used over several cogs, although I specifically recall Tim indicating that it should work fine over several cogs.
Any suggestions on how to track this down?
Byte ResponseArray1[64], direction[1]
Byte SerialReadBuffer[8], chksum, progmode, posmode
The problem I am having is that direction[1] keeps getting changed. Amongst the VAR items, the SerialReadBuffer is where the incoming 6 bytes of data come in from the RS485 input to the 4port. Changing the SerialReadBuffer to 16 has no effect on the issue. Direction[0] is always fine. Using a debug method to the LCD, the value of Direction[1] tends to change to 31, a decimal value 31 on the LCD using ser.dec(3, Direction[1]). The default for direction[1] is 1 on boot, and it only changes the second any data enters the RS485>port1 on the 4port.
I have added debug code to monitor if any of the stacks are getting ran over, but no stacks are running over. The test code for this is to park a dummy placeholder Long after each stack array, and monitor for a change.
I moved the Direction byte array to the bottom of the list, it no longer is affected when it gets placed somewhere else, so I know it is not being affected by it's name, but rather the location only. If I monitor instead ResponseArray[66], the same change takes place. ResponseArray is not in use at all.
I have concluded that this is some type of bug using the 4port, possible due to the object being used over several cogs, although I specifically recall Tim indicating that it should work fine over several cogs.
Any suggestions on how to track this down?
Comments
Not sure how I have never experienced that issue before after all these years. But in testing the results, that is correct. I always thought that unless you were using a zero terminated string, that if only two bytes were being affected, that you only needed the two elements Direction[ 0 ] and Direction[ 1 ], declared as Direction[ 1 ] in VAR. Changing the declaration from Direction[ 1 ] to Direction[ 2 ] solves it.