0

Two Feather M0's not being recognized by Win7
Moderators: adafruit_support_bill, adafruit

Please be positive and constructive with your questions and comments.

Two Feather M0's not being recognized by Win7

by posplayr on Thu Jun 17, 2021 12:57 am

I'm having an issue where I now seem to have two damaged USB interfaces on two different Feather M0's. I'm an EE with several years of experience and have programmed on Arduino and ARM M0 products including using professional tools ( Crossworks for ARM and Visual Studio) for code development, so I'm relatively careful about burning things up especially with 3.3V supplies.

I will try and briefly describe what success I had to try and rule out software problems as well as provide a general description of what I did electrically which seems to now have resulted in two dead feathers.

I purchased these two Feather MO's (AdaLogger and Bluefruit LE) back on September 26, 2017. At the time I was evaluating these and the Pololu A-star. I may (in 2017) have plugged the feathers into a USB port to see if they came on and blinked a light. Even if I did, I don't think I ever downloaded into either; basically still new. Recently ( June 5th 2021) I have another project that came up and I ordered the FeatherWing OLED, AHT20, and the MCP9808 sensor breakout boards to evaluate with the 2017 feathers.

1.) First I took the BLE M0 and soldered on stacking header to stack the OLED on top of the Feather M0. It worked and I played with the display for a few hours downloading the OLED example and making modifications to prototype the display.

2.) Then I used jumper wires with the AHT20 and a protoboard to jumper the Feather 3.3V, GND, SCL, and SDA for the corresponding pins on the AHT20. The scope traces of SCL,SDA confirm I'm using 3.3V voltages. The "adafruit_aht_test" sketch measured the temp and humidity.

3.) Then I used the same jumper wires to connect the MCP9808 to the Feather M0 BLE. It worked intermittently which attributed to the poor connections due to the short header not properly engaging into the proto board. In the next step it all worked.

4.) Then I took a second MCP9809 and wired a 16 ft shielded cable in order to assess the I2C signaling degradation. I don't think it worked and I shut down for the night. The next day with a clear head nothing seemed to work. After reloading all libraries in the Adruino IDE, I deduced that the M0 BLE was failing to properly register with Win 7 Pro (both a Dell Precision 490 desktop and a Dell Precision M6500 laptop). Windows reported the failure and would not install the driver. The MO Adlogger did work and registered (confirmed with Windows Device Manager)

5.) This last step was to solder headers to the Feather Adalogger to stack the OLED on it and resume testing of the I2C. 16 foot cable and MCP9808. The second go though I realized some of my self-inflicted errors in trying to use the Serial Monitor while uploading and stopped that. Because everything had already been wired I got the OLED demo, the AHT20 demo and the MCP9808 demos to run both on a breakout MCP9808 and an MCP9808 at the end of the 16 ft cable. I thought that the problems were now behind me and the M0 BLE has just suffered from infant mortality.

I put some pull-up 25K to 3.3V resistors(all I could find) that put on the SDA,SCL and looked for changes in rise time on my digital scope. I saw nothing changed. I decided to start doing some test code to merge the OLED demo code with the MCP9808 code.

At this point, I am de-powering the M0 adalogger from a USB hub rather than trying to pull the connector out of the feather. So all seems well and stable except when I do the first download of this merged code, Window 7 will not register the M0 adalogger . The lights come on but there is no display code I was in the process of changing it. No lights flash but the RED led next to the USB connection is solid Red. When I hit the M0 reset button Windows makes the thunking sound of USBs connecting and disconnecting but the device does not show in the Device Manager.

Any ideas what I'm doing wrong (if anything). these devices do not seem to last more than an hour with the external I2C connections. Circumstances might suggest it is the I2C failing from the long cable but why is that causing the USB to fail?

If you are wondering why I'm using a 16 foot cable (?) it is because I want to see if I can improve the rise times at this length and still be functional before cutting the cable down to 5-6 foot.

TestSet.png
The devices with 3 different I2C temp sensors. Both M0's are now not registering with Windows 7 pro
TestSet.png (662.48 KiB) Viewed 718 times
SDS1202X-E8.png
I2C waveforms with 16 foot cable. The MCP9809 demo did not fail one it was properly loaded.
SDS1202X-E8.png (30.75 KiB) Viewed 718 times
SDS1202X-E11.png
This picture shows normal I2C waveform rise times when not using the 16 ft cable (2V/Div captured using Single shot Trigger mode).
SDS1202X-E11.png (30.34 KiB) Viewed 718 times

posplayr
 
Posts: 12
Joined: Tue Jun 13, 2017 10:04 am

Re: Two Feather M0's not being recognized by Win7

by posplayr on Thu Jun 17, 2021 4:13 pm

I don't need the USB interface for my intended application other than downloading the application so I will move to JTAG for development which is far more convenient.
I'm going to set up the Feather M0 for JTAG using a Segger J-Link and move from the Arduino IDE to MS Visual Studio using Visual Micro. Hopefully, my two Feather M0's are not completely dead.

https://www.visualmicro.com/

I was very concerned that I was running into a brick wall with the Feathers and contemplating a different platform, but it seems like there is a path forward using the Feather/OLED display so I will keep going.

posplayr
 
Posts: 12
Joined: Tue Jun 13, 2017 10:04 am

Re: Two Feather M0's not being recognized by Win7

by posplayr on Sat Jun 19, 2021 6:23 pm

This is just a quick update on progress. I have:
[list=]Wired both Feather M0's for JTAG/SWD (SWD is the stripped-down two-wire interface defined within the JTAG interface)
Reinstalled my J-Link JTAG debugger and verified it still works on an old project using Rowley Cross for ARM.
Updated my license to Visual Micro and
in the process of updating my MS Visual Studio 2017 and 2019 installations.[/list]

Here is what the MS Visual Studio 2017 tab for Visual Micro looks like now.
MSVS_VisualMicro.png
MSVS_VisualMicro.png (253.29 KiB) Viewed 672 times


I got the download to get this far
DownloadStatus.png
DownloadStatus.png (138.86 KiB) Viewed 672 times


It appears to be almost working. The reason I'm using MSVS is that it just handles larger multi-file projects much better and allows you to maintain projects (separate programs) and libraries (another project) all within a solution file. I use this for developing code and simulations where I run the simulation with embedded code on the desktop and use the visual studio debugger, or I can map the same relevant parts of the embedded code to a Rowley Crossworks for ARM solution to do cross-platform development of the same code. Visual Micro seems to do a very good job of bridging the same Arduino embedded with desktop cross-platform C++ development.

Anyway I'm still working this but the above screen shot shows I'm close.

As far as the lingering issues that are the subject of this thread,; 'What happened to my USB ports?" I have studied the Device Driver status more closely. There is an error code 43 that is apparently being reported by the USB driver because the USB device failed to do something. Various possibilities exist. The simple one listed by WDaytonTurner below to plug it into another computer failed as well.

I'm mainly concerned about having done something to physically destroy the part but it seems as if (for the moment at least) I can tentatively assume it is some type of a driver corruption issue. I have tried to delete the driver and using the Plug and Play to auto reinstall but that fails with windows reporting that the driver install has failed. It suggests three options the last of which is a manual installation. I assume I would need to install the Ada fruit USB driver.

Here goes nothing................. and nothing different happens.

[list=]With this version of Arduino a new all-in-one driver (with
security signature for Windows 8) is supplied.

The old (deprecated) drivers are still available in the
Old_Arduino_Drivers.zip
[i][/list]


https://github.com/adafruit/Adafruit_Wi ... ag/2.5.0.0


https://answers.microsoft.com/en-us/win ... 2dcb705c7f



USB_Status.png
USB_Status.png (284.84 KiB) Viewed 672 times

posplayr
 
Posts: 12
Joined: Tue Jun 13, 2017 10:04 am

Re: Two Feather M0's not being recognized by Win7

by posplayr on Sun Jun 20, 2021 12:04 am

A little more progress and I got accepted to the VisualMicro forum and posted the following support thread.

https://www.visualmicro.com/forums/YaBB ... 24161137/0

Apparently, the Feather M0 is failing to clear its NVM (non-volatile memory). This is the FLASH so it is failing to respond to Segger commands to clear FLASH. The CPU might still be functioning, but if the FLASH is busted then it is a paperweight and not a very good one considering its moniker.

The verbose VS output is captured in the attached text file.
The first error is an NV lock error which waterfalls into what amount to a failure to program the device.

Error: SAMD: NVM lock error
Error: Failed to erase row containing 00000000
Error: SAMD: failed to erase sector 0 at 0x00000000
Error: failed erasing sectors 0 to 81
embedded:startup.tcl:510: Error: ** Programming Failed **


Is overwriting the SAMD boot loader going to help this?

https://learn.adafruit.com/how-to-progr ... ashing-a-s


MSVS2019_FeatherM0_JLINK_DownLoadFail.txt
(2.11 KiB) Downloaded 2 times


PS I tried the same thing with the other feather M0 and it has virtually the same result. The only difference is the xPSR location. These are two different parts; one is a feather M0 BLW and the other is the feather M0 Adalogger.

posplayr
 
Posts: 12
Joined: Tue Jun 13, 2017 10:04 am

Re: Two Feather M0's not being recognized by Win7

by posplayr on Tue Jun 22, 2021 2:01 pm

A quick update. So Simon@Visual Micro has suggested trying to overwrite the SAMD boot loader to see if the same J-Link errors persist in MicroChip Studio. I working with the ESP32 now but will put this on my "short term" list of things to do. BTW I'm very impressed with the TTGO LoRa32 OLED V1 and its larger color display.

posplayr
 
Posts: 12
Joined: Tue Jun 13, 2017 10:04 am

Re: Two Feather M0's not being recognized by Win7

by posplayr on Wed Jun 23, 2021 6:13 pm

I had some success today with the help of the Visual Micro forum tech support. I was able to resurrect my 2017 copy of Atmel Studio 7 running under Win7 and enable the Segger J-Link download under Atmel Studio 7: tools>device programmer. .

I did follow the direction here for setting up JTAG SWD support on the feather M0.
https://learn.adafruit.com/how-to-progr ... -m4-wiring

It turns out the directions for doing setting up Atmel Studio are located here (now I find them).
https://learn.adafruit.com/how-to-progr ... mel-studio

As I look at these detailed instructions I can only imagine I'm not the first person to Brick their Feather M0's .

I got a successful download of the Feather M0 using J-Link on a device that will not virtual comm port load drives in Windows 7. This basically means the Boot loader is hoseded!
I'm going to wait on further recommendation from Visual Micro but I expect if I reflash the boot loader then hopefully this Feather M0 comes back from the edge of the abyss.

https://www.visualmicro.com/forums/YaBB ... 161137/9#9

posplayr
 
Posts: 12
Joined: Tue Jun 13, 2017 10:04 am

Re: Two Feather M0's not being recognized by Win7

by posplayr on Wed Jun 23, 2021 8:01 pm

I posted another update at Visual Micro. The Feather is not stable even with successive Bootloader downloads. It either fails to reload the Windows drives or to fails a checksum after the boot loader download.

I'm not sure it is worth pursuing anymore. I would like to think this is all software issues, but when a checksum check fails you are inclined to think more of H/W unless there is some NV flag blocking download in an area. I'm not familiar enough with the chip to diagnose this any further so it is largely speculation.

This is a pretty old board and I suspect they are not updating it or even trying to fix what is probably a pretty common problem. That is why there is silence in the thread from the moderators or support people.

posplayr
 
Posts: 12
Joined: Tue Jun 13, 2017 10:04 am

Please be positive and constructive with your questions and comments.