NetBurner Community Forum

I have a Wifi dev board that I want to connect to a Nano54415 dev board. Is there a cheat sheet for which pins should be connected between these two?

Thanks,
Lance

Here's the connection guide I have; critical pins on the wifi adapter board are as follows:

50 - VCC3V
49 - GND
1 - GND

25 - SPI CLK
27 - SPI MISO
28 - SPI MOSI
30 - SPI CS0

41 - Master UART RX
44 - Master UART TX

42 - Wifi Reset

IRQ notification pin as jumpered on board

The default software configuration uses DSPI1 or uart 9 pin connections
for connecting to the Nano are:
For SPI:
(Adapter - Nano)
25 - 31
27 - 33
28 - 35
30 - 15
42 - 42 Reset
IRQ - IRQ (depends on which IRQ is being used) (example, IRQ3)
[26 - 49]

For UART:
(Adapter - Nano)
42 - 42 Reset
41 - 20
44 - 22

Connect power in addition. And be aware of the numbering issue with rev 1.1 carrier boards (Silkscreen even pins refer to module odd pins).


-Dan

Thank you. I'm up and running in SPI mode now.

FYI, the silkscreen documentation for the jumpers on the Wifi dev board is wrong. SPI mode needs a jumper on J6. The quick start guide has this documented correctly.

Ok, couple quick things. You're right about the pin 42 issue, I'm not sure what I was thinking when I wrote this up. Basically, pin 42 is what the default reset pin for the driver call is. To change it, you'll need to more fully flesh out the call to InitWifi_SPI() instead of using the defaults.

As for the jumpers, that appears to be a strapping problem in the firmware that shipped. Long story short, I misread the truth table from the schematic and thought that it had been referring to the placement of jumpers; in fact I changed the firmware because I thought it was conflicting with what the silkscreen had! The jumper settings in the quickstart was then created from a completed module while running.

We have a corrected version of the firmware where the silkscreen matches the required jumper settings. We'll be publishing this update firmware in the next week to rectify the issue, along with an example for how to perform the update. The quickstart guide will also be updated to reflect the changed jumper settings.

Thanks for the feedback. I'm just glad my requisite instance of shipping a not-quite-right product got caught with as little wrong as this!

-Dan

I eventually figured out that the reset pin does need to be connected in order to change Wifi settings. I used pin 30 on the nano and have switched between AP mode and client mode successfully.

I did notice that AP mode requires a 8 digit password. I suppose that encouraging people to use security is good, but there are times when I'd prefer to just have an open Wifi network, which it wouldn't let me do.

For anyone reading this thread in the future, use SPI mode if you can, it's faster than Serial. The pins you need connected for SPI are:
Nano dev board - function - Wifi dev board
17 - 3.3v - 50
18 - GND - 49
31 - CLK - 25
33 - MISO - 27
35 - MOSI - 28
15 - CS0 - 30
* - Wifi Reset - 42
49 - IRQ3 - 26

* You can use any unused GPIO pin for the Wifi Reset pin. I used pin 30 on the Netburner. You'll need to specify what pin to use in the InitWifi_SPI() function. For example, InitWifi_SPI("MySSID", "MyPassword", 30); Alternately, you can change the default pin to use in nbWifi.h starting around line 54.

The 8 character key minimum issue is fixed in the version awaiting release. In the fixed version if you give no key or a null string key, it will revert to OPEN mode. The 8 character minimum is a feature/limitation (depends on who you ask) of the framework used for the slave device.

[Edit: I should clarify; IF we're requesting security (aka WEP, WPA, WPA2, not open), then there is a 8 character minimum in the framework. If we're not, then it will happily accept a black key.]

-Dan

I just got a wifi module and I'm a little confused. I'm using nndk 2.6.8, should I follow the jumper settings on the silkscreen or the ones listed in the July 2014 quick start guide that came with it. I'm trying to run the examples in SPI mode and it the driver seems to stop at "Starting WIFI..."

The issue is that the DSPI driver got shot in the face in 2.6.8. Here's the fixed files that will be coming in the next rev (2.6.9?) that we're working on getting out the door to address this and other issues.

-Dan

dciliske wrote:The issue is that the DSPI driver got shot in the face in 2.6.8. Here's the fixed files that will be coming in the next rev (2.6.9?) that we're working on getting out the door to address this and other issues.

-Dan

Hi Dan, is there any more information on:
1) when the 2.6.9 will be released,
2) what are the known problems with 2.6.8.

I want to release my NB app (runs in a MOD54415), but I have been holding off for the last few days waiting for any info on when 2.6.9 will be available and what is wrong in 2.6.8
I have to decide within a few days, whether to wait for 2.6.9 or not, and the answers to the two questions above will determine what I do.

Thanks,
Roland.