Adafruit Feather HUZZAH ESP8266 on macOS 10.13 High Sierra

Introduction

A long time ago I tried to use the EtherTen from freetronics to build a network-connected temperature and humidity sensor. Simple, right? Although I got it to work it was unreliable. I don't know how or why, but it would lock up and I had to power cycle it to restart it. So this project has been on the back burner for a long time.

Image: freetrhonics EtherTen

I recently bought an Adafruit HUZZAH ESP8266 Breakout board and RHT03 sensor and breadboarded the project again, as per my previous blog post Example Ruby on Rails Arduino Project. This time it was reliable.
Image: Adafruit HUZZAH ESP8266

When I bought a second round of hardware to build a seconds sensor (which now has a cool 3D printed case by the way) I saw the Adafruit Feather range which includes the Feather HUZZAH ESP8266. This has the same WiFi board so it should be as reliable as what I've been using. There's also a great range of "feather wings", so I grabbed a CharlieWing to use as a display for my temperature monitoring project. While reading up on Feathers I found there's no need to do the dance with the GPIO and Reset buttons to get the Arduino IDE to load to the board every ... single ... time.

The rest of this blog post is about getting the CharlieWing up and running on macOS 10.13 High Sierra.

Arduino

I followed Adafruit's instructions to get the Feather HUZZAH working but, as per as the boxout on the page, the built-in driver didn't work. Before I cover how I fixed it (using their instructions, naturally) I'll show you what I could find out about the issue.

Hardware Debugging

Plugging the Feather HUZZAH into a USB port caused a few LEDs to blink, so that was good. I went to the Arduino IDE to ensure the port appeared there but it didn't.

Arduino port missing.

I did some quick Googling to work out how to enumerate the USB devices connected to the system and came up with ioreg -p IOSUB

 ~: ioreg -p IOUSB  
 +-o Root <class IORegistryEntry, id 0x100000100, retain 15>  
  +-o AppleUSBXHCI Root Hub Simulation@14000000 <class AppleUSBRootHubDevice, id 0x10000032a, registered, matched, active, busy 0 (4 ms), retain 12>  
   +-o Apple Internal Keyboard / Trackpad@14400000 <class AppleUSBDevice, id 0x100000345, registered, matched, active, busy 0 (63 ms), retain 22>  
   +-o Bluetooth USB Host Controller@14300000 <class AppleUSBDevice, id 0x100000498, registered, matched, active, busy 0 (4 ms), retain 24>  
   +-o Expansion@14500000 <class AppleUSBDevice, id 0x100002d28, registered, matched, active, busy 0 (8 ms), retain 14>  
   +-o CP2104 USB to UART Bridge Controller@14200000 <class AppleUSBDevice, id 0x1000031c2, registered, matched, active, busy 0 (8 ms), retain 14>  
 ~:   

Ah, interesting. I guessed the last device (CP2104...) was the Feather HUZZAH. I unplugged it from the USB port and ran the command again. Bingo.

 ~: ioreg -p IOUSB  
 +-o Root <class IORegistryEntry, id 0x100000100, retain 15>  
  +-o AppleUSBXHCI Root Hub Simulation@14000000 <class AppleUSBRootHubDevice, id 0x10000032a, registered, matched, active, busy 0 (4 ms), retain 14>  
   +-o Apple Internal Keyboard / Trackpad@14400000 <class AppleUSBDevice, id 0x100000345, registered, matched, active, busy 0 (63 ms), retain 25>  
   +-o Bluetooth USB Host Controller@14300000 <class AppleUSBDevice, id 0x100000498, registered, matched, active, busy 0 (4 ms), retain 27>  
   +-o Expansion@14500000 <class AppleUSBDevice, id 0x100002d28, registered, matched, active, busy 0 (8 ms), retain 17>  
 ~:   

Yeah, you don't need to be Sherlock Holmes, but I thought it was interesting the device was correctly interpreted on the bus. That must be all part of the USB base specification. If we believe Adafruit's instructions, it's just the USB driver that's at fault. Maybe the only step missing here was getting the hardware device to be seen as a serial port and then it should appear in the Arduino IDE.

Not being familiar with loading/configuring/removing drivers on macOS I decided to pick this procedure apart to see what I could learn from it.
  1. I followed the Adafruit link to Silicon Labs for the Legacy OS Software and Driver Packages
  2. Then download the CP210x VCP Driver. (VCP? Virtual Communications Port?)
  3. Mounted the driver DMG file that was just downloaded.
  4. I opened the release notes in a text editor but didn't see anything interesting other than the instructions to remove and install the driver.
  5. I opened uninstaller.sh in a text editor. The driver would be in one of two locations and have  one of three names. Four options in total. The uninstall script would just delete the package recursively.
  6. I tried to locate any of the four file paths listed but struck out. I was just straight out missing the driver. This made me wonder if I shouldn't just install the latest driver. Later.
  7. Double clicking on the Silicon Labs VCP Driver.pkg I followed the wizard to install it.
With version 4 of the driver installed I wondered if the Arduino IDE would see the Feather HUZZAH? No. After a restart of the IDE? No. After a reboot of the machine? Well ...

After rebooting the machine I got a dialog titled System Extension Blocked. It states Silicon Laboratories Inc is trying to run a new signed system extension. Cool.
Image: System Extension Blocked 

As instructed I went into System Preferences, Security & Privacy, General tab and there it was. I clicked Allow.
Image: Security and Privacy

Now what happens with the Arduino IDE?

Image: Arduino IDE sees Feather HUZZAH as /dev/SLAB_USBtoUART

Excellent!

Just for the sake of knowing I wondered where that driver was installed to. And which version exactly. I re-opened uninstall.sh to remind me of the paths used. My machine now had the folder /Library/Extensions/SiLabsUSBDriver.kext/. I:

  1. navigated to that folder (package) in Finder
  2. right-clicked on SiLabsUSBDriver.kext and selected Show Package Contents
  3. then opened the Contents folder.
  4. opened the Info.plist file in a text editor
  5. could then see the driver version in the XML below the CFBundleVersion key.
The version I had installed was 4.10.14. Then I wanted to see it work. I:
  1. opened the Arduino IDE
  2. opened the Blink example for this device File → Examples → ESP8266 → Blink
  3. setup the Feather HUZZAH (see image below)
  4. hit Verify
  5. hit Upload
  6. Boom! Blinky flashy goodness.
Image: Working Arduino IDE settings

Now for something more serious!

Latest Driver

I'll have a lash at upgrading to the latest driver.
  1. Get back into the original SiLabsUSBDriverDisk.dmg to run the uninstall.sh script. Actually you can't run it from the DMG file, so open the DMG and copy uninstall.sh to the desktop. Then run it at a bash prompt:
     ~: cd Desktop/  
     ~/Desktop: ls  
     $RECYCLE.BIN     Junk          Thumbs.db     desktop.ini     uninstaller.sh  
     ~/Desktop: . uninstaller.sh   
     Password:  
     ~/Desktop:   
    
  2. Check the file path in Finder to make sure the SiLabsUSBDriver.kext package is gone.
  3. Then download the latest driver from here (same location pointed to by the Adafruit tutorial). 
  4. Accept the EULA
  5. When the DMG file is mounted you should see four items. Double-click Silicon Labs VCP Driver.pkg to install the current driver.
  6. Follow the wizard
  7. Once the wizard completes, we'll need to reboot.
After reboot, you should find the driver package where the prior version was. Looking at the Info.plist file should show a later version. Mine is 5.0.1. A quick change to the Blink code for the ESP8266 and the first upload works fine. Tada!

CharlieWing

All that (above) just to get to the point we can reliably upload to the Feather HUZZAH before we even play with the CharlieWing. That actually feels pretty good after you've been doing the "button dance" on the regular HUZZAH.

And then a real road block popped up. I can follow the tutorial to get the "swirl" demo running but it only runs a little while before it stops and the microcontroller pukes out a stack dump. The first thing I think of is there's a memory leak. The sketch itself doesn't help much because it's only a few lines out of the hundreds (maybe) that are running; most of the lines of code are in the libraries I downloaded.

I adapted the Blink demo (because it requires no libraries) and made it Serial.print() a counter for each execution of the loop() function. 20,000 iterations and counting right now ...

Implementing the same counter on the Swirl demo prints:

 4, 5, 6, 7, 8, 9,   
 10, 11, 12, 13, 14, 15, 16, 17, 18, 19,   
 20, 21, 22, 23, 24, 25, 26, 27, 28, 29,   
 30, 31, 32, 33, 34, 35, 36, 37, 38, 39,   
 40, 41, 42, 43, 44, 45, 46, 47, 48,   
 Soft WDT reset  
 ctx: cont   
 sp: 3ffef310 end: 3ffef5c0 offset: 01b0  
 >>>stack>>>  
 3ffef4c0: feefeffe 00000001 3ffef52f 3ffee443   
 3ffef4d0: 3ffee445 00000000 00000006 4020120c   
 3ffef4e0: 00000002 00000001 3ffee445 4020131a   
 3ffef4f0: 00000074 00000001 3ffee445 40201331   
 3ffef500: 00000074 00000001 3ffef52d 00000000   
 3ffef510: 0000002c 00000000 3ffee441 4020225c   
 3ffef520: 00000042 3ffee40c 3ffee430 40202284   
 3ffef530: 00000000 00000001 3ffee430 402028f2   
 3ffef540: 00000009 3ffee40c 00000000 40202980   
 3ffef550: 40101180 018d80f2 3ffee4ac 00000000   
 3ffef560: 3ffee40c 00000008 00000000 402029d2   
 3ffef570: 3ffe8480 3ffee58c 402030bc 40202a8c   
 3ffef580: 00000018 3ffee408 3ffee568 3ffee58c   
 3ffef590: 00000017 00000000 0000000f 40202021   
 3ffef5a0: 3fffdad0 00000000 3ffee584 40203108   
 3ffef5b0: feefeffe feefeffe 3ffee5a0 40100718   
 <<<stack<<<  
 �8   �> 8 � >8888�8�8�� 8�� �8����>��88�� 8��>�>� 8>�>���8  >      8�8�>�>  �88 >8�88�888 8>� >8�8�8>� 8��>�>�>8�8>8>8���>�>88>8> >>>>���>88 ���8>�����>88 ���8� >8888� 88>8� >�  RISSI swirl test  
 IS31 found!  
 0, 1, 2, 3, 4, 5, 6, 7, 8, 9,   
 10, 11, 12, 13, 14, 15, 16, 17,   

Two things are interesting. First, the "Soft WTD reset". I know the watch dog timer is built into AVR microcontrollers and, when configured, needs to be "fed". The code implements an occasional call to feed the dog and, if the 'normal' code fails to run, the WDT will reboot the microcontroller, causing the program to start from the beginning. I've had no luck so far getting the WDT to run in Arduino projects of mine.

Second, after the WDT resets the microcontroller, the code runs from the start and seems to run reliably (10,000 iterations and counting ATM), printing the loop counter, but the CharlieWing is frozen. No updates are being displayed on the LEDs.

And that's the reason I'm going to need to hold this over to a different blog post. I can't imagine debugging this issue (with my limited knowledge) will be fast. So...

... that is all.

Comments

Post a Comment