AVR-iot WG demo works- but only when plugged into PC USB port

This demo works but only when connected to a pc usb port. Then the blue WIFI led lights, then the amber connection LED lights.
if you power the board via a USB adapter, or a LiPo cell connected to the battery port, the Blue LED lights indicating WIFI access point is found, but the amber led doesn’t light, and you can’t see the board in the Atmosphere IOS App. So, no cloud connection I assume.
Maybe the AVR firmware, which performs the USB thumb drive emulation is hanging when it doesn’t find a USB host i.e. the PC.
If the AVR-IOT WG has to be connected to a PC to work, then it’s pretty well useless.
Any ideas?


When did you build your firmware? We just released 1.3.0 late last week which contains improvements to the AVR-IoT WiFi functionality. Could you try rebuilding your firmware to see if the problem still persists?

I’ve just tried here with a wall adapter and a battery, and I’m able to get data to the cloud.


@bmillier - We saw something similar last week at the Sensors Expo, but it seemed to be hardware specific. We had one of three AVR kits that would always connect when plugged into a battery, but two others would only connect when plugged into the PC, and then the next time they were plugged in to a battery or a wall wart it was about 50/50 if they would connect or not.

In 1.3.0 - released last week, we upgraded the fw for the WINC1500 the AVR kit uses to make multiple attempts to connect to the wifi network when rebooted. Have you tried this process recently, or are you reporting something you have experienced in the past? We will dig out a couple of AVR kits and reprogram them on 1.3.0 and report back any change in behavior.

@Nick/Sven: Thanks for the quick response. I just started Atmosphere this weekend so I’m new to your platform, but have lots of experience with ESP32/8266/AVR/Particle running IoT applications.
I did this all over the weekend, so I assume I am using V1.3 of the Studio web software. I also have an ESP32 DevkitC which works fine in the same physical location (running the Atmosphere demo software example).
I originally tried out my AVR-IoT WG board using the Atmel demo program compiled using their smart configurator and Atmel Studio (when I purchased it 6 months ago). If my memory serves me correctly, in that scenario, the Blue LED lights when your WiFi access point is connected to, and the amber LED lights when the cloud connection is established.My board worked fine connecting to the sandboxed Google cloud server, per the Atmel firmware.
First blue, then amber LED lit, and data LED blinked during data transmission.
I am assuming your firmware emulates the Atmel firmware- even the rapid flash of all 4 LEDs at boot seems the same.
My AVR-IoT WG module definitely needs the PC. I am powering it thru a powered USB hub. As long as the hub is connected to the PC, everything is fine. As soon as I disconnect the USB cable from hub to the PC, and re-boot, the amber LED is not lit. I’ve tried several USB power adapters- up to a 10 Watt iPad power block, and all of them result in only the blue LED coming on. Same with a fully charged 4000 MaH LiPo battery.
As soon as I plug the AVR-IoT WG module into the PC’s USB port, the PC shows the Curiosity Flash drive in a new file manager window. Of course, this is how you program the board in the first place- Drag/drop the program hex file to it. I still see the Atmel “Click-me”,“Kit-Info”, “Pub key”,“status” files showing. The Atmosphere hex file no longer shows up at this point- I assume it gets erased after it is loaded into Flash.
The board is definitely running the Atmosphere firmware, as I can see the data being live-graphed on the PC dashboard (if I power it up without USB, I still see the graphs in the Studio dashboard, but the traces don’t update any more).
I am more interested in using my ESP32 board - I just had an AVR board on hand, so I tried playing with it. While it has nothing to do with this topic, I can’t figure out how to get data to an IOS Atmosphere app when using WiFi- like with the AVR-IoT WG. The ESP32 demo IOS app works fine, and is easy to understand, but that is communicating via Bluetooth characteristics. I am entering the SSID/Password when I provision the ESP32, but I still think it is using Bluetooth between the ESP32 and my iPad.I want to use the ESP32 in WiFi mode, as I do with my other projects.
But, this is another topic.

A Follow up to my last post.
I flashed the original AVR-IoT WG firmware back into my module.Plugged into the PC USB port, it connects to the Google cloud OK and I can see the data graphing on the dedicated Microchip AVR web page. Switching to using just a USB power adapter, it took about 40 seconds but eventually it connected and sent data to the cloud OK.
I then reverted to the Atmosphere firmware - I re-flashed firmware, deleted device and re-provisioned it. Oddly, for the first time, when it prompted for the SSID/password, it preemptively filled in my Atmosphere ID and password (blanked out but the right length). Those aren’t my WiFi credentials of course, so I corrected this.
Nothing has changed- it is OK on the PC USB port, but no connection to cloud- blue LED only on the USB power pack- the same one that worked with the AVR -IoT WG firmware.
I should add that where I referred to “Amber” LED in my earlier posts, the 2nd LED is actually green, but is so small that my eyes mistook it for amber. However with the original AVR firmware, the 3rd LED, Data, blinks regularly, and I can see that the data LED is actually the amber one. Sorry for my mistake.


We will look into this more, and we may need to contact Microchip for support. On our end, we have some people/kits able to replicate the problem, but I personally have not been able to. I’ve tried a wall outlet and a battery, and it always seems to connect just fine.

We have not changed the Microchip bootloader, so we have no influence over that USB drive mounting code. Maybe some boards ship with slightly different versions of either WINC1500 firmware or bootloader firmware, and they behave differently.

A couple questions for you:
1.) If your AVR IoT is connected to your PC and sending data to the cloud, and you unplug it then plug it back into your PC, does it reconnect and resume sending data?
2.) Can you try the attached .atmo while plugged into a wall outlet or battery? I want to determine if the board is hanging somewhere during early startup or if it’s actually running the user application. This should blink the ERR LED once per second. LED_BLINKER.atmo (19.9 KB)

Yes, it does. I will mention that I did your step 2 first, so I had
to reflash the “onboard sensor demo” into the chip and re-provision
it. After doing this, nothing worked until I physically unplugged
the USB cable and then re-connected it to the PC. Then it worked
Also, just in case some “magic” had occurred, I again tried this
firmware with the adapter only, and it did the same thing as before-
just a blue LED and no updating on the dashboard. This time it also
hung my Firefox (67.0.4) browser- I had to kill it in Task manager
to proceed. (this hadn’t happened before to the best of my
recollection) As soon as I compiled/downloaded the hex file, the AVR IoT Blue
LED lit and the red error LED flashed once per second. Even though I
had yet to provision it, the blue LED was lit- I thought that
indicated a successful WiFi Access point connection. Since I hadn’t
provisioned it yet, either the blue LED is for something else, or
it was using the SSID/PWD from the last time I provisioned it.
But, once I provisioned it, the green "conn: LED lit up, and blue
remained lit, red continued to flash.
Next, I tried it with just a USB power adapter (10 watt iPad
adapter + another misc. one). Blue LED lit, red LED lit but didn’t
flash, and green LED didn’t light up. So, I think you are correct that it is crashing early on. Its been 6
months since I looked at the Atmel firmware for this board, but I
don’t think the AVR MCU used a real RTOS.
If I had written this code myself, I wouldn’t believe what I’m
seeing either…
This board has a separate ARM chip for the USB
flashdrive/bootloader/USB serial port. This really should isolate
the '4808 MCU from any USB influence. Also, I was quite surprised to see that the WiFi/cloud connection
would be active in a blinky program that doesn’t have any wiFi/Cloud
elements. Thanks for your attention, Nick.
or reply to
this email to respond.