Need a second set of eyes. Pub local variable oddity

Timothy D. Swieter

Attached is an archive of the work I am doing on the Brilldea W5100 driver. Today I made progress on creating the UDP send/receive code. Once I proved the concept I dove into making a more presentable and cleaned up code implementing what I prototyped. That is where the trouble started. In the attached code there is the top file, a Demo file of the W5100 driver and the W5100 driver. The demo is basic, it sets the addresses and initializes the W5100 and the drops into an infinite loop where it receives UDP packets and displays the contents in a serial terminal.

The problem: I can't say for sure what the problem is but it has to deal with local variables or writing to hub ram in an unintentional overwriting manner in one of the W5100 PUBs. Help me find the exact problem.

A clue: In the W5100 driver file you will see PUB rxUDP. You will actually see two lines like this:

PUB rxUDP(_socket, _dataPtr) | temp0, t9, RSR, pcktsize, pcktptr, pcktoffset, pcktstart, rolloverpoint    'This statement works
PUB rxUDP(_socket, _dataPtr) | temp0, RSR, pcktsize, pcktptr, pcktoffset, pcktstart, rolloverpoint         'This statement does not work

I alternately comment each one out. With a bogus local variable inserted, t9, the PUB executes as expected. What is expected is that when the overall demo is loaded the system goes into a waiting state waiting for data to arrive. Because the system just started there are no UDP packets to process. When data arrives it retrieves the packet properly from the W5100 and displays the correct contents.

When the bogus local variable is removed (the second line) it appears that RSR or temp0 is getting clobbered with data or is falsely getting info. What is happening is that the when the demo is first started RSR immediately thinks there is UDP packets to reads and grabs stall, ghost data from the W5100. The driver grabs a few packets and then the whole program goes wonky and eventually causes garbage and maybe even a reboot.

So, what is the cause of the trouble?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I.
www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, 3.0" LCD Composite video display, eProto for SunSPOT
www.tdswieter.com

kuroneko

if (W5100flags & _Flag_ASMstarted)

  'Check if there is data to receive from the W5100
  readSPI((_S0_RX_RSR0 + (_socket * $0100)), @temp0, 2)
  RSR.byte[noparse][[/noparse] 1] := temp0.byte[noparse][[/noparse] 0]
  RSR.byte[noparse][[/noparse] 0] := temp0.byte[noparse][[/noparse] 1]
    
  'process if there is data
  if RSR <> 0

Local variables (like RSR) are not initialised to zero (like their global relatives). And they always take up a long. In the fragment above you effectively only initialise half of RSR which will give you unexpected side-effects later.

Erik Friesen

If that doesn't fix it, I'd say look for an alignment problem somewhere.

Timothy D. Swieter

HOT DOG!! Thanks for the look over the code guys! I understood that local variables were longs, however my flaw was thinking they were initialized to zero. Thanks for the tips, I adjusted the code to initialize the values and all looks good for the moment.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I.
www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, 3.0" LCD Composite video display, eProto for SunSPOT
www.tdswieter.com