Making WiFly (RN-131C) work with Arduino Due (R3)

Wireless & IoT
1

I have a WiFly Shield (RN-131C, 6/15/10 rev).

When I plug it into an Arduino Uno (SMD ed.) and use the WiFly-Shield library, it works: no problems. Plugging it into an Arduino Due (R3) does not.

I’m still a relative newb when it comes to Arduino. However, my best guess is that communications over SPI is not working.

I see that the Due moved SPI pins to the center of the board on a 2x3 header. So I tried not plugging the WiFly shield directly into the Due, but jumping wires from the WiFly shield headers to the Due headers as seemed appropriate. That is:

WiFly VIN -> Due VIN
WiFly GND -> Due GND
WiFly  D7 -> Due  D7    (/IRQ)
WiFly D10 -> Due D10    (/CS)
WiFly D11 -> Due D75    (MOSI)
WiFly D12 -> Due D74    (MISO)
WiFly D13 -> Due D76    (SCK)

When I run SpiUartTerminal example, it fails in SpiUartDevice::uartConnected, where the readRegister(SPR) call returns 0xFF rather than the test character. Ideas?

Am I misunderstanding how things work here? As far as I can tell (looking at http://www.sparkfun.com/datasheets/DevT … ld-v17.pdf and http://www.robgray.com/temp/Due-pinout.pdf), the 10-13 pins on the WiFly shield are wired to the CS/MOSI/MISO/SCK of the WiFly’s SPI interface, and that’s my only option (no UART exposed). Shouldn’t jumpering those to the moved pins of the Due work?

2

You are likely running into an issue because the Due operates at 3.3v. The Wifly shield has on-board regulators that regulate down everything to 3.3v for the RN-131C module, and is designed to interface with boards that operate at 5v, like the Uno. Otherwise, running jumper wires to the ICSP header on the Due would be the correct action.

3

SFE-TS-Toni:
You are likely running into an issue because the Due operates at 3.3v. The Wifly shield has on-board regulators that regulate down everything to 3.3v for the RN-131C module, and is designed to interface with boards that operate at 5v, like the Uno. Otherwise, running jumper wires to the ICSP header on the Due would be the correct action.

Taking a multimeter to VIN/GND coming off the Due shows 9V, which is what the power supply is providing. Or should I be checking voltage elsewhere?

And I should be hooking up to the ICSP header or the SPI header? The Due has both…

4

Okay, I think I figured the issue. I looked at one of the included SPI examples; though I couldn’t immediately test that example, I noticed it had a call the SpiUartTerminal example did not:

pinMode(10, OUTPUT)

Added that to SpiUartTerminal, and I was able to get into CMD mode and send commands. Still a bit more to actually joining a network, but that seems to have been the problem.

Always the little things… :oops:

5

mattm0ss:
Taking a multimeter to VIN/GND coming off the Due shows 9V, which is what the power supply is providing. Or should I be checking voltage elsewhere?

And I should be hooking up to the ICSP header or the SPI header? The Due has both…

The Due does have a Vin pin that connects to the external power supply, which is why you are seeing 9v there. However, the logic of the Due board is only 3.3v. You can see more information on that here: http://arduino.cc/en/Main/ArduinoBoardDue.

Otherwise, glad to hear you got your shield up and running!

6

SFE-TS-Toni:
The Due does have a Vin pin that connects to the external power supply, which is why you are seeing 9v there. However, the logic of the Due board is only 3.3v. You can see more information on that here: http://arduino.cc/en/Main/ArduinoBoardDue.

I understand the basic gist, but you’ve said the same thing above in trying to get a point across, so maybe I’m just misunderstanding you or missing the point.

Due gets 9V, regulates down to 3.3v. Nice.

WiFly gets 9V, regulates down to 3.3V. Nice.

Fixed the code, everything seems swell.

Now, are you saying that I should still be concerned about a voltage issue somewhere?

7

No, you don’t need to be worried about a voltage supply issue if your board is working well. However, we have seen issues with the Due board not being able to properly power some units because it runs at 3.3v instead of the typical 5v on most Arduino boards. Any shield designed for a 5v Arduino can run into issues on the 3.3v Due because of the voltage regulation. Sometimes this just doesn’t provide enough juice to get wireless/gps devices working fully. Again though, if you aren’t seeing any issues, then hardware wise, your interface is fine.

8

Thank you so much!

I will second that this fixes the issue. But there was one more step for me. I had to delete the _Spi.h and _Spi.cpp files from the WiFly library.

So the full set of steps for me to connect to my wireless network with and WiFly and a Due were:

  1. Open Due box, install Arduino IDE, and open WiFly bag =)

  2. Connect the pins from the WiFly to the correct pins on the SPI header on the Due (I soldered them to a header+cable that matched the SPI header on the Due):

WiFly D11 → Due D75 (MOSI)

WiFly D12 → Due D74 (MISO)

WiFly D13 → Due D76 (SCK)

(I also did GND to the GND on the SPI header, just in case the speed will increase from 9600 at some point)

  1. Put the WiFly library in my libraries directory

  2. Delete the _Spi.h and _Spi.cpp files from the WiFly library

  3. Open the WiFly_Autoconnect_terminal example

  4. Add the following line as the first line after “void setup() {”

pinMode(10, OUTPUT);

  1. edit Credentials.h to have my wireless ssid and passphrase

  2. upload and open serial monitor

  3. I had mixed results getting good text out of the terminal, but whether I saw the right output or not, if I saw the LED on WiFly start flashing green rapidly then I can ping. Only the first time did I get my IP address output. I am not sure why I stopped getting it, but since I kept getting the same IP address assigned it didn’t matter for me. It seemed like something to do with increasing the debug level broke it, but reverting didn’t fix it.

9

A few other things issues I ran into before getting it stable:

  1. I would be able to get short bursts of characters correctly, but anything that returned a lot of text from the prompt would be garbled. This was fixed by decreasing the SPI speed from 4MHz to 2MHz (I didn’t try any intermediate values):

In hardware\arduino\sam\libraries\spi\SPI.cpp:

setClockDivider(BOARD_SPI_DEFAULT_SS, 42); //edit: was 21, now 42

  1. I was able to go to 115200 without any trouble, for both the USB->SAM and the SC16IS750 → WiFly links. The problem I had with the UART terminal was, regardless of baudrate setting, that you have to change the Serial Monitor mode from “send newline” or “send newline and carriage return” to be “send nothing” (or whatever the real setting is, I don’t have it in front of me), or else the “$$$” command won’t get you into command mode. Then you have to change it to “send carriage return” once you are in CMD mode.

For my SPI max frequency issue, the soldering is good. But I used maybe 5 inches of ribbon cable to get from the WiFly to the Due. If the problem is coupling between the lines, it is possible that if I cut the wires shorter or didn’t use ribbon cable that I would get back to 4MHz. I have had that problem with SPI interfaces before, but I was running at 24MHz was using a longer cable then. I didn’t expect an issue at 4MHz. For now that isn’t my slowest link, so I am not debugging it.