Close

Good news Bad news

A project log for RPi WiFi

Fast RPi WiFi without USB

ajlittajlitt 01/06/2016 at 06:3512 Comments

Good news first: AP mode works with the standard hostapd setup. That means Zero-based routers, WiFi VPN tunnels, honeypots,...

Bad news: If you want your own, you're going to have to make it yourself. FCC type certification is too costly for a niche product like this, even more so when it's already shaping up to be a more expensive board than the Pi itself.

I had a plan to work around this by using the exposed SDIO signals on the FCC approved ESP-12E module. The trick was to force the SPI flash, normally used for the program flash and shared with the SDIO, to stay quiet. This would have had the side effect of forcing the ESP8266 into 1-bit SDIO mode and lowering throughput, but it would make the board easier to assemble and satisfied the FCC. I experimented on an ESP-03, wiring all but the uppert 2 bits of the SDIO bus and forcing the SPI flash's /HOLD signal to ground to keep the flash chip in tristate. In practice, this didn't work:

It looks messy, but the edges on the SDIO handshake look nice and clean.

Edit after sleeping:

Last night I noticed that the SD_D0 signal had some "toothiness" while high, as if another device were trying to drive the signal. SD_D0 is multiplexed with the DO pin of the SPI flash. The other signals we're hijacking (DI, CLK, /CS) are all inputs to the flash in 1-bit SPI mode. Now that my brain is on right, this suggests that the SPI flash wasn't honoring the /HOLD request. I can think of a few reasons for this, so ignore my doom and gloom.

If this scheme does work, the main side effect would be that SDIO would be reduced to 1 bit mode. Throughput between the Pi and ESP would drop from 200Mbits/s to 50Mbits/s and would become the bottleneck. This is probably a good trade-off: no certifications needed, simpler assembly and BOM, and much better availability in the US of ESP-12E modules vs. bare ESP8266 or ESP8089 parts.

If someone has a hook-up at AI-Thinker, suggest to them that they make an ESP-12E (or -F or whatever) with the SPI flash left unpopulated. That would be ideal.

Discussions

jacksonliam wrote 01/06/2016 at 17:51 point

Are you sure you cleared the Quad Enable Bit in the SPI flash status register?

I wonder if this snippet from the flash datasheet is the issue:

"To initiate a /HOLD condition, the device must be selected with /CS low. A /HOLD condition will activate on
the falling edge of the /HOLD signal if the CLK signal is already low. If the CLK is not already low the
/HOLD condition will activate after the next falling edge of CLK."

I'm assuming the ESP chip still pays attention to CS in SDIO mode? So you can't just disable the flash with CS as that would also silence the ESP chip?

  Are you sure? yes | no

ajlitt wrote 01/06/2016 at 18:56 point

Those are my concerns too.

It occurred to me this morning that these are wired for QSPI and so probably are preconfigured as such.  I can break out the Bus Pirate, read status2, and change it if necessary.

I went through my collection of SPI NOR datasheets (I do a lot with them at work) and noticed that this is the standard.  Different manufacturers seem to have slightly different descriptions of the hold function.  On some other parts the behavior can be boiled down to activating the HOLD state when the AND of /HOLD, /CS, and /CLK goes low, and exiting the state on the rising edge of the AND of /HOLD and not /CS.  That doesn't seem to be exactly how the Winbond text describes it for W25Q32, and seems to vary slightly from part-to-part.  On parts where /HOLD is actually /RESET, you're not supposed to release /CS while /HOLD is asserted or risk resetting the part.

Remember too, that DO won't leave tristate until a command word has been sent, which is /CS asserted and more than 8 clocks.  As long as we can get away with having /HOLD asserted ahead of /CS, then the part should enter the HOLD state well before it would have a reason to drive DO.  And of course if the part wants to treat the pin as /RESET then the end result is the same.

If the only problem is that QE is set then this shouldn't be a big issue.  I'm not sure if you can generate arbitrary SPI flash commands with the ESP ROM, but if so then maybe this could be done under esptool.py and UART boot.

  Are you sure? yes | no

jacksonliam wrote 01/06/2016 at 20:31 point

Here's some info here about how to get dual io mode by flashing the module. Though quite how changing a 0x0 to 0x2 in the .bin ends up clearing a bit in the flash register I'm not sure! 

http://smarpl.com/content/esp8266-esp-201-module-freeing-gpio9-and-gpio10

I wonder if it might also be able to write the flash with SPI by holding the esp in reset? 

  Are you sure? yes | no

ajlitt wrote 01/06/2016 at 21:18 point

That field in the firmware header tells the ESP what SPI mode to use.  I suspect that the ROM functions that esptool.py calls also handle writing the QE bit.  The solution is probably as easy as flashing an image built for DIO mode.

You're probably right though.  It's easier to talk to the flash through the pins while the ESP is in reset.

  Are you sure? yes | no

ajlitt wrote 01/08/2016 at 02:14 point

So I was able to get a Bus Pirate to read status2, and indeed QE was enabled.  I cleared it and put it on the Pi but still the SDIO won't enumerate.

To rule out the otherwise untested hacked module, I shorted SD_D2 and SD_D3 to ground on one of my working prototypes to force it into 1-bit mode.  But the ESP on that board wouldn't be recognized by the Pi either.  Now I suspect something wrong with how the Pi sdmmc driver does a card detect.  I'll have to turn on debug in the driver and see what it says.

  Are you sure? yes | no

jacksonliam wrote 01/11/2016 at 10:47 point

Nice debugging!  I've seen the latest update, great work!

  Are you sure? yes | no

deʃhipu wrote 01/06/2016 at 09:25 point

I think that if you are soldering stuff to the flash pins, you might as well desolder the flash chip entirely -- the FCC would frown upon either of them anyways. 

  Are you sure? yes | no

ajlitt wrote 01/06/2016 at 14:58 point

I guess I wasn't clear in this log.  The module I have in the picture is an ESP-03.  It doesn't have FCC type certification, it doesn't have a soldered on RF shield, and it doesn't bring any of the SPI flash signals out to castellations.  I used this to test out this idea since that's what I have on hand.

The ESP-12E however has all those things.  All the SPI flash pins come out on castellations (not to be confused with the other SPI master the ESP's have).  My thought is that by constantly asserting the /HOLD (SD_D3) signal the SPI flash will stay tristated and let the interface work in SDIO mode.  It seems that there are a number of conditions where asserting /HOLD doesn't have the expected behavior.  The SPI flash is hidden under a soldered down RF can, and as you say modifying it in any way isn't kosher.  But if this scheme works, then the SPI flash would stay inert and SDIO would run in 1-bit mode without losing the FCC module certification.

If I didn't have to worry about certifications then I wouldn't be bothering with modules.  I think the antenna I'm using in my chips-and-discretes design has more gain than the ones used on any of the AI-Thinker modules, and is fairly easy to assemble in standard SMT processes.  Desoldering the flash and bodge-wiring to the remaining pads is tedious, and I'd much rather toaster reflow my current board for small quantity personal use.

  Are you sure? yes | no

deʃhipu wrote 01/06/2016 at 18:55 point

By the way, there is a way to sell this without FCC certification -- sell it as a kit. Just leave the pin headers unsoldered. At least that's what I've heard from various people -- I'm not a lawyer.

  Are you sure? yes | no

ajlitt wrote 01/06/2016 at 19:36 point

I considered that.  In fact if I were to sell it I'd leave the header unsoldered anyway to leave room for customization.  It would be cool to mount a long pin header to the front of this board, stack & solder the Zero on top, and stack additional HATs on top of that.

From what I hear the "kit" exception is very specific to TV accessories and is not well defined where almost-but-not-quite assembled boards are concerned.  Looking at FCC action reports they don't crack down on small hobbyist stuff like this unless you're selling jamming devices, so it's unlikely that I'd get in any trouble.

That said, I don't have money for lawyers or fines, so I'm not going to take the risk.

  Are you sure? yes | no

jarocks wrote 01/07/2016 at 17:27 point

Have you considered trying to partner with a maker company which may have more resources to push something like this through FCC certification?

  Are you sure? yes | no

ajlitt wrote 01/08/2016 at 02:07 point

I'd love the opportunity to work with a retail maker shop like Adafruit, Sparkfun, or Seeed to get these made.  There are other risks I'm not equipped to take on my own that shouldn't be a problem for these sites.

  Are you sure? yes | no