MicroMod Mainboard Double damaging STM32 MCU boards while using WizNet5500 ethernet function board?

[Sterny72]

Hi,

Thanks for your support.

Got my new Wiznet 5500 function boards in early this week, and today went to see if I could get Micropython ethernet working on a STM32 with a mainboard double and a STM32 MCU board.

Here’s what I observed initially.

1. Plugged Ethernet function board in slot 0.

2. STM32 MCU already installed.

3. Plugged in USB connection in PC using mainboard connector.

4. Used reset/boot pattern to enter boot loader, no USB device enumeration observed.

Next, decided to remove ethernet function board and retest. Still unable to enter STM32 boot loader from USB.

Following that, wanted to determine if MCU may have been faulty.

1. Removed MCU from mainboard and installed in a different carrier board (SparkX featherboard).

2. MCU cannot enter bootloader / no USB enumeration observed.

3. Thinking I have a bad/zapped MCU, in this case.

Next, still want to get Micropython working. I have spare STM32 MCUs installed in other carrier boards, so I:

1. Tested to ensure that STM32 boot loader would enumerate USB on an extra mainboard single. Tested OK - saw boot loader connection

2. Removed STM32 from mainboard single, and installed in mainboard double used previously above. (no function boards installed at this time).

3. USB boot loader NOT enumerating.

Lastly, since I just removed the STM32 MCU board from a just confirmed, working mainboard single, I wanted to see if the MCU was damaged, or if it was jus something amiss with the main board double. So I:

1. Removed newly installed STM32 MCU from suspect main board double, and placed in back into original main board single.

2. Observed NO USB enumeration. Also, noticed that while PWR LED is ON, did NOT see 3v3 LED turn ON.

3. After a few minutes, went to unplug the board and noticed that the bottom of the board near the USB connector was warm.

4. It appears to me that main board double is damaging the STM32 MCUs.

Next, reviewed function board hookup guide and read up on two jumpers settings to re-map power to MCU pins, depending on board. Jumpers for function 0 and 1 are in default position - slide to the ‘right’ of the battery JST connector. From my reading those two jumper positions should supply power to function cards properly.

However, since we’re dealing with a brand new function card, of which has the capability of a POE power supply to the main board, I wonder if there is some influence from this part. Note, the Ethernet function board was NOT plugged into any POE switch during any of this testing.

Novice/hobbyist conclusions

1. While I cannot say for sure the mainboard double was working properly prior to plugging in the POE function board, it is clear now that the mainboard double is now damaging STM32 MCU cards. I appeared to have lost two MCU so far, and am loathe to test any additional ones.

2. In the POE function board hookup guide is mention of several configuration options. Did not alter any jumpers, and installed as was shipped by SFE. I’m not skilled enough, nor willing to risk additional products, to further diagnose whether the POE function board created this situation, or to determine how the mainboard double is damaged.

3. Inspected M.2 pins for any contamination or bridging - all clean. Reseated boards during the work above.

Request

1. I’m welcome to any suggestions on how I can isolate the problem. I’ve got a scope and a multimeter.

2. Is it possible for SFE attempt to reproduce this issue, by:

A. Placing a STM32 MCU card in a Micromod main board double - using boot/reset button pattern confirm that boot loader enumerates USB connection to PC.

B. Next, place new Ethernet Wiz5500 function board in slot 0, and determine if the boot loader will continue to enumerate?

Regards,

Stern

[TS-Russell]

We’re going to try and replicate this on Thursday (while we are in-the-building), and will get back to this post with our findings

[Sterny72]

Hi Russell,

Thanks for your response and support.

I decided to test the second, thought to be malfunctioning processor board again today, and found that it is NOT damaged. It was able to enter boot loader.

I then put it in the original, suspected carrier board, and everything worked fine. Tried the ethernet function board, and after struggling a bit with what appears to be some inaccurate pinout information in the hookup guide, was able to confirm Micropython works well with it.

I still do have a damaged STM32 F4 processor board - that’s still refusing to be programmed and has some unexpected LED behavior.

My guess is at this point, something went awry with the local PC’s USB plumbing when I was doing my testing, which impacted the results I posted about.

Anyway, thanks again for your attention - no need to waste time trying to re-pro this - I’ve got Micropython working well with two carrier boards on STM32 and the ethernet function card.

Regards,

Stern

[paulvha]

I seem to have killed a MM SAMD51 (DEV-16791) and today the MM nRF52840(WRL-16984) because I installed them on a Mainboard double and in slot 0 I had put the ESP32 Wifi (WRL-1840).

I had used BOTH processor boards before for weeks and they worked without problems. Also on the double mainboard BUT without the ESP32 WIFI.

2 weeks ago I first installed the SAMD51 and ESP32 WIFI. Then uploaded the sketch from the ESP32 WIFI Hook-up guide, immediately after I can not find the /dev/ttyACM0 port anymore. No matter what I did, remove the ESP32 WIFI, rebooted the Ubuntu system, restarted the IDE a number of times. Installed the SAMD51 in a MM data logger board (where it worked before). I tried holding reset during power cycle, holding boot during power-cycle, holding both etc etc etc. Dead is it can be.

The thing that worries me also is that when I connected to power to the double mainboard AND USB-C to the ESP32 WIFI, with the power jumper manually enabled… I could not get any response from the ESP32 WIFI

Thinking I made a stupid mistake, I already wanted an nRF52840 and ordered also a new ESP32 WIFI. I took the nRF52840 today on the double mainboard, the new ESP32 WIFI in slot 0… the /dev/ttyACM0 turned up and I used the same sketch. After uploading… dead… the led on the MM board starts blinking 5 x slow, 5 x fast. NO matter what I do or try, no connection with the board anymore. Also trying again the ESP32 WIFI… no response… nothing…

Anyone any ideas or has anyone got this work?

IF YOU HAVE NOT TRIED, I WOULD ADVISE YOU TO WAIT FOR SPARKFUN. I was apparently not the only one ending up with (2) no-responsive processor boards following a standard procedure of uploading a sketch.

[Sterny72]

Hi Paul,

This is an interesting report.

I still haven’t been able to explain what happened to my STM32 processor board, only that it seems that the Ethernet function board didn’t cause the problem.

I also have the LORA and ESP32 function board, and while I haven’t done any work with them, I did install those function boards on the Double and power them up in the past. Maybe that’s when the STM processor board was damaged.

I also don’t want to risk damaging these processor boards with troubleshoot experiments without some assurances from SFE that they will replace them in the event we can reproduce the problem.

[paulvha]

Thanks Stern,

I just find it very weird that just uploading a sketch could damage 2 processor boards (and ESP32 WIFI) to become completely unresponsive. I have done many many projects with Sparkfun hardware and enjoyed them all. But something is not right here, at least I do not understand (yet).

[wonder_boom]

Hey I’m the engineer that designed the MicroMod Main boards and I am keen to discover the source of the issue, if there is one. Paulvha has been kind enough to post this on the Main Board Double hardware repository but I’ll try to post here first and close the issue when we find a solution.

Link to repository: https://github.com/sparkfun/SparkFun_Mi … e/issues/3

So far, I’ve tried to destroy my MM SAMD51 Processor Board with and ESP32 Function Board in slot zero following the steps Paulvha outlined. I’ve tried two other function boards with this particular Processor Board and I’ve done other unkind things to my Processor board like swapping the jumper mid upload, but no luck yet. I need more processor boards and more time.

I’ll update as I know more.

[paulvha]

Thanks for the prompt action and update.

[wonder_boom]

So no luck so far, I uploaded to my SAMD51 yesterday maybe 50 or so times. What surprises me is that what both of you are describing is basic use case and I tested that endlessly during the prototype phase. I unfortunately was not able to test the PoE Function Board yesterday like I intended to but I’ll get to that either today or tomorrow. I also tried jumping the three pins, “PWR_EN0”, “3.3V”, and “GND”, since they sit right next to each other, using my tweezers but I only succeeded in resetting the board.

If you have any more information that’d be very helpful. Have either of you toned out any of the surrounding pins, on both the function and the Main Board Double? My only guess is that we’re seeing some sort of manufacturing edge case OR production edge case, and I’d like to identify it if possible.

[paulvha]

Thanks for the update

I continued to use the Main double board with a MM Artemis processor board and the ESP32 Wifi. But I removed the function board so far with each upload of an adjusted sketch. Based on your findings I have now stopped remove and reinstalling the function board after each sketch upload. So far… so good…

[paulvha]

While uploading sketches to the MM mainboard double + function board ESP32WIFI, with either the MM ESP32 or the MM Artemis is working without any problems I did notice something weird today.

The charge led is flashing unregular all the time with the MM ESP32 processor

Situation :

ESP32 WIFI function board in place

No battery or LIPO connected.

Power jumpers are in the default place. (both right)

Charge switches in the default position (both on)

Measurement with analog logic analyzer (Saleae logic 8). The measured voltages are shown to be stable (< 0.05V noise)

With MM ESP32
5v   ->  4,825V (after the PTC)
3v3  ->  3.229V (on MEAS connector)

The charge led is flashing unregular all the time. Even when I push and hold reset it flashes unregular but much slower.
When I connect a probe to the battery '+' connector, it stops flashing, Charge LED is off. I have different probes and depending on the probe the '+ 'will read 0V or 4.165V. Probably an impedance issue.

[b]Changing over to the  MM Artemis[/b]
All seems normal when installing a MM Artemis.
5v   ->  4,877V (after the PTC)
3v3  ->  3.239V (on MEAS connector)

The charge led is OFF, seems to flash sporadically, and always flashes shortly when I touch the '+' on the battery connector. This is to be expected and measure 0V.

Alternatives I tried with the MM ESP32 processor board

1. Remove the ESP32 function board.
5v   ->  4.945V (after the PTC)
3v3  ->  3.294V (on MEAS connector)

The charge led stays OFF.

2. Standard situation, but both charge current resistor off .
5v   ->  4.907V (after the PTC)
3v3  ->  3.294V (on MEAS connector)

The charge led stays OFF.

3. Standard situation, but only the 100mA charge current resistor ON .
5v   ->  4.907V (after the PTC)
3v3  ->  3.294V (on MEAS connector)

The charge led flashes unregular.

3. Standard situation, but only the 500mA charge current resistor ON .
5v   ->  4.849V (after the PTC)
3v3  ->  3.294V (on MEAS connector)

The charge led flashes unregular.

4. Connect the board to a different PC (Standard situation, same cable, same setup)

With MM ESP32
5v   ->  4.976V (after the PTC)
3v3  ->  3.319V (on MEAS connector)

The charge led is NOT flashing. Charge LED is off. I have different probes and depending on the probe the '+ 'will read 0V or 4.165V. Probably an impedance issue.

5. Connectetd to an external USB-type-C power supply (Standard situation)
5v   ->  5.026V (after the PTC)
3v3  ->  3.32V  (on MEAS connector)

The charge led is NOT flashing. Charge LED is off.

Why the charge led is flashing with the ESP32 and not with Artemis. Don’t know. But clearly, the power supply has an impact.

[wonder_boom]

Thank you for the data. There seems to be something wrong with your Main Board Double but I’m not sure what. I do not see any flickering on the charge LED with any Processor Board. I’m not entirely sure where to go with the information but I’ll dedicate some time to this again tomorrow.

[TheHoff]

Just wanted to let the people following this thread know that we’re still digging into this. So far, we’ve not been able to duplicate the issue. With some behind the scenes help from others, hoping to find out the root cause of the behaviors seen. We will report back any findings later this week.

[F800]

Does anyone have an update on this topic? I’ve got a couple of STM32 Thing Plus boards that intermittently boot via DFU and suddenly stop booting for extend periods. Does anyone know where I can find a good copy of the bootloader that I re-load (via STM32 PRG)?

[Sterny72]

Hi,

Noticed revisions to both carrier boards. Hookup guide describes the differences (pasted below).

Seems in my hobbyist view a lot of changes incorporate several protection measures with the new revision.

Was anything discovered as a result of the investigation performed on this thread? If there’s potential to unintentionally zap hardware when using the old revisions, it would be nice to get any idea on any precautions available to avoid damaging components during normal usage.

Revision Changes

The following changes to the Main Board Single V2.1 and Main Board Double V2.2 include:

Rotate silkscreen for the connectors and a majority of the labels.

Add TVS diodes for ESD protection on the USB pins.

Add SHLD jumper to isolate the USB Type C connector’s shield pin.

Add a 5V MEAS PTH jumper as a measurement for 5V.

Remove the 500mA/100mA selector for the LiPo charge circuit. The board now charges at a default rate of 500mA only.

Add a DIVIDER jumper to remove the resistor divider that is connected to processor’s “BATT_VIN/3” pin for low power applications.

Add a dedicated 3.3V/500mA voltage regulator for the Qwiic port.

Add GPIO control of 3.3V voltage regulator (I2C_SCL1-Processor).

Add a LED for the 3.3V Qwiic port with a QWIIC LED jumper to disable.

Add a transistor to disable power to the microSD socket (can be controlled using I2C_SCL1-Processor).

Add multiplexed primary UART pins to send serial data to Function Board(s).

Add PTH pins for multiplexed UART (Main Board Single v2.1 only).

Move PWR_EN0 from SDIO_Data2_Processor to PWM1 (Main Board - Single v2.1 only)

Add two 2.2kΩ I2C pull-ups to the primary I2C pins with jumpers (I2C) to disable.

Replace male header pins and 2-pin shunt with SMD switches to adjust the Function Board Power enable pins (Main Board - Double v2.2 only).

Add option to adjust Function Board One’s secondary SPI CS pin (i.e. “CS1-processor” and “A1-processor”) with a SMD switch (Main Board - Double V2.2 only).