I am having some problem getting a wifly sheild to initialize. After jumping the vin with +5v, I now show the lights, but when using the GHIElectronics.NETMF.FEZ.FEZ_Sheilds.WiFly, When it tests to see if it is initialized, it fails. When it writes 0x55 ot the register and then reads, I am always getting back 255.
WriteRegister(Register.SPR, 0x55);
byte data = ReadRegister(Register.SPR);
if (data != 0x55) // NOTE: this is where it is always 255 and not the value passed
throw new Exception("Failed to init SPI<->UART chip");
Any help would be much appreciated
Can you describe the light sequences?
Is this a new shield with factory settings?
yes. it is pretty much straight out of the box (after soldering on the headers.)
on the light sequence, PI04 (green) first lights up, then PI06 (orange) blinks about 15 times, with PI04 blinking every other blink of PI06. after about 15 times, then it seems to go through the sequence again.
What crystal is on that WiFly shield? You may need to alter the DLL register write.
See comments here, for more info… http://www.fezzer.com/project/168/sparkfun-wifly-shield-with-fez-domino/
I remember the WiFly shield made by sparkfun get powered from Vin.
So you need to connect external power (USB powered FEZ Panda will not help).
The crystal is 14.7456MHz. I changed my code to call the setup to look like this:
WiFlyShield.Setup((Cpu.Pin)FEZ_Pin.Digital.Di10,
SPI.SPI_module.SPI1,
WiFlyShield.ClockRate.Xtal_14MHz,
WiFlyShield.BaudRate.BaudRate_9600);
the heart of the Setup() method looks like below and, the debug is showing that it is going to the 14mhz setup.
I have also tried powered from non-USB external power and I get the same results. The response back is always 255 after the register write then read.
is there anything I should worry about on the baud rate?
#region SPI to WiFly UART Init
// Initialise the WiFly shield SPI<->UART chip
// Convert the enum to a baud rate
int baudRate = 1200;
int depth = Convert.ToInt32(baudRateIndex.ToString()) - (int)BaudRate.BaudRate_1200;
for (int i = 0; i < depth; i++)
{
baudRate += baudRate;
}
// Make DLL and DLH accessible
if (clockRate == ClockRate.Xtal_12Mhz)
{
// I doesn't look like a 12MHz clock can do 921600bps
if (baudRate == 921600)
baudRate = 460800;
int divisor = 12288000 / (baudRate * 16);
WriteRegister(Register.LCR, 0x80); // 0x80 to program baudrate
WriteRegister(Register.DLH, (byte)((divisor & 0x0000ff00) >> 8));
WriteRegister(Register.DLL, (byte)((divisor & 0x000000ff) >> 0));
}
else
{
int divisor = 14745600 / (baudRate * 16);
WriteRegister(Register.LCR, 0x80); // 0x80 to program baudrate
WriteRegister(Register.DLH, (byte)((divisor & 0x0000ff00) >> 8));
WriteRegister(Register.DLL, (byte)((divisor & 0x000000ff) >> 0));
}
// Make EFR accessible
WriteRegister(Register.LCR, 0xBF); // access EFR register
// Enable CTS, RTS, and Enhanced functions (IER[7:4], FCR[5:4], and MCR[7:5])
WriteRegister(Register.EFR, (1 << 7) | (1 << 6) | (1 << 4));
// Finally setup LCR
WriteRegister(Register.LCR, 0x03); // no parity, 1 stop bit, 8 data bit
WriteRegister(Register.FCR, 0x06); // reset TX and RX FIFO
WriteRegister(Register.FCR, 0x01); // enable FIFO mode
// Perform read/write test of scratchpad register to check if UART is working
WriteRegister(Register.SPR, 0x55);
byte data = ReadRegister(Register.SPR);
if (data != 0x55)
throw new IOException("Failed to init SPI<->UART chip");
#endregion
Bad reply… The original GHIElectronics.NETMF.FEZ.FEZ_Sheilds.WiFly class and the Fezzer code should work 
Can’t think of what else could be causing the SPI to UART bridge to not work. Could this be an upgraded WiFly shield, which board version?
the Shield is dated 6/10/2010
not sure how to tell from the wifly board. I see this on the board that kinda looks like a version: G2M5437-02.6
I purchased from Sparkfun. the wifi module is mounted on a Sparkfun shield.
I think that I will try the same shield on an arduino and see if I get any different results. wont be able to get to it until tomorrow. but if anyone has ideas on another way to get the card initialized on the panda, that would be great help!
well, I ran it on my arduino and had the same problem. so, when all else fails, check your solder points. and alas, there was some shoddy work (I am not the best with soldering). So, now I am getting it initialize.
Now to get it to join my network. I think I need to move closer to my WIFI router because it doesnt seem to be getting in. Will try that next.
thanks everyone for replying. this is a great forum.
brian
Glad to hear you have it initialising. Once setup, it does a decent job with it’s single socket.
If you use the Fezzer code, there may be a tweak needed when it tries to work out if a network has been joined. I’ll have a look later and check my local changes against Fezzer. It’s a change related to the messages received back from the GSX via UART. You should be able to see this, stepping through the code, and looking at the GSX feedback messages and how the code analyses those messages.
yeah. I got it to work all the way until it tries to get an IP address and it seems to have problems there. going to debug later today to see what messages are coming back.
Well I got everything to work. I used the arduino terminal tool that came with their alpha library to debug and manually run through each command one by one to see what is going on. Has anyone written such a terminal for .NETMF? if not, I might write one over the weekend to help debug in the future.
the things that I had to change were the authentication type (changed to WEP_128), and I had to chance some of the things that the system was “listening” to. In particular, right after the join SSID, instead of listening for the phrase "Listen on " + listeningPort.ToString(), I listened for the phrase “DHCP: Start” as shown below:
SendCommand("join " + SSID);
WaitForResponse("Associated!");
Debug.Print("Associated!");
//WaitForResponse("Listen on " + listeningPort.ToString());
WaitForResponse("DHCP: Start");
you can see that I commented out the original WaitForResponse("Listen on " + listeningPort.ToString()); and changed it to WaitForResponse(“DHCP: Start”);
after I did this, things worked pretty good and I no longer got into endless loops that were waiting for a response that would never come.
thanks for all the help.
Can’t think of what else could be causing the SPI to UART bridge to not work. Could this be an upgraded WiFly shield, which board version?