Calling tcp_tick 128X causes SPI errors

Rabbit Rabbit Software
, , ,
1

I am using the RCM5650W SPI library along with WiFi to log temperature and humidity from a HIH6000 SPI sensor. When I use this code, the values from the sensor are bogus:


   sock_init();
   while (ifpending(IF_DEFAULT) == IF_COMING_UP) {
		tcp_tick(NULL);
   }
   http_init();
   tcp_reserveport(80);
   brdInit();
   HIHinit();  //initialize SPI ports

but this version allows the correct SPI values to be returned


   sock_init();
   ifpending(IF_DEFAULT)
   tcp_tick(NULL);
   http_init();
   tcp_reserveport(80);
   brdInit();
   HIHinit();

So it is some aspect of the looping. I found that the while loop executes about 1800 times, so I started trying different loop values to understand where the problem occurs.
I found that looping <=127 times gave the correct values, but >= 128 times gave the bogus values. It is also something in tcp_tick() that is creating the issue.
The SPI library uses PB0 for the SPI clock which is also used by the WiFi, so I can see that there may be some potential conflict.
But why 127/128 is magic (other than being 0x7F/80) seems odd. I don’t see anything in the tcp_tick() code that would be dependent on the number of times the function is executed.
Would like to understand the sensitivity to the number of execution calls.