Close
0%
0%

Motor Shield Reprogramming

Create and flash new firmware for the WeMos D1 Mini Motor Shield.

Similar projects worth following
There is a motor shield for the WeMos D1 Mini ESP8266 board, and it uses an STM32F030 microcontroller for the communication. However, the code running on it is really sloppy, resulting in the firmware hanging and bringing the I2C bus down whenever you look at it funny. But we are hackers, we can fix it!

We have pretty good information about the motor shield:

The shield has a serial interface for programming broken out, and that chip is supposed to have a bootloader built-in, so hopefully we will be able to just use stm32flash and an USB2TTL adapter to program it.

There is a nice dev environment template for this family of microcontrollers: https://github.com/szczys/stm32f0-discovery-basic-template

motor_shield.bin

Compiled binary of the new firmware.

octet-stream - 3.04 kB - 05/12/2017 at 13:46

Download

  • Multiple I²C Addresses

    deʃhipu11/08/2017 at 10:54 0 comments

    As mentioned by @Matrix User in the comments, the new firmware doesn't support selecting of the I²C address with the jumper pads on the bottom of the board — instead the address is fixed in the firmware. There is an issue reported about this at https://github.com/pbugalski/wemos_motor_shield/issues/3 and some workarounds, including alternate builds of the firmware with different hard-coded addresses.

  • Reprogramming Without Soldering

    deʃhipu04/21/2017 at 18:10 8 comments

    Turns out that the procedure in the previous log can be greatly simplified. You don't need an ST-Link programmer, and you don't need to solder anything. Even if your shield is locked, you can unlock and program it with a simple serial adapter. Here is how.

    First, clone the repository:

    $ git clone https://github.com/pbugalski/wemos_motor_shield
    $ cd wemos_motor_shield

    Make sure you have arm-none-eabi-gcc installed, and compile it:

    $ make
    arm-none-eabi-gcc -Wall -g -std=c99 -Os -mlittle-endian -mcpu=cortex-m0 -march=armv6-m -mthumb -ffunction-sections -fdata-sections -Wl,--gc-sections -Wl,-Map=motor_shield.map -Iinc src/startup_stm32.s src/main.c src/user_i2c.c src/tb6612.c -o motor_shield.elf -Tstm32f030.ld
    arm-none-eabi-objcopy -O binary motor_shield.elf motor_shield.bin
    arm-none-eabi-size motor_shield.elf
       text	   data	    bss	    dec	    hex	filename
       2032	   1084	   1056	   4172	   104c	motor_shield.elf
    

    Now, make sure you have stm32flash utility installed. Short the RTS and the 3V pins on the shield together, like this:

    And the connect the main pins of the shield to your USB2TTL as follows:

    GND ↔ GND

    3V3 ↔ 3V3 (or VCC or whatever it is called on your USB2TTL)

    D2 ↔ TX

    D1 ↔ RX

    and connect it to your computer. Now, see if you can communicate with the device:

    $ stm32flash /dev/ttyUSB0
    stm32flash 0.5
    
    http://stm32flash.sourceforge.net/
    
    Interface serial_posix: 57600 8E1
    Version      : 0x31
    Option 1     : 0x00
    Option 2     : 0x00
    Device ID    : 0x0444 (STM32F03xx4/6)
    - RAM        : 4KiB  (2048b reserved by bootloader)
    - Flash      : 32KiB (size first sector: 4x1024)
    - Option RAM : 16b
    - System RAM : 3KiB

    Now, you can unlock your shield:

    $ stm32flash /dev/ttyUSB0 -k
    stm32flash 0.5
    
    http://stm32flash.sourceforge.net/
    
    Interface serial_posix: 57600 8E1
    Version      : 0x31
    Option 1     : 0x00
    Option 2     : 0x00
    Device ID    : 0x0444 (STM32F03xx4/6)
    - RAM        : 4KiB  (2048b reserved by bootloader)
    - Flash      : 32KiB (size first sector: 4x1024)
    - Option RAM : 16b
    - System RAM : 3KiB
    Read-UnProtecting flash
    Done.
    
    $ stm32flash /dev/ttyUSB0 -u
    stm32flash 0.5
    
    http://stm32flash.sourceforge.net/
    
    Interface serial_posix: 57600 8E1
    Version      : 0x31
    Option 1     : 0x00
    Option 2     : 0x00
    Device ID    : 0x0444 (STM32F03xx4/6)
    - RAM        : 4KiB  (2048b reserved by bootloader)
    - Flash      : 32KiB (size first sector: 4x1024)
    - Option RAM : 16b
    - System RAM : 3KiB
    Write-unprotecting flash
    Done.
    
    And now you can flash it:
    $ stm32flash /dev/ttyUSB0 -v -w motor_shield.bin
    stm32flash 0.5
    
    http://stm32flash.sourceforge.net/
    
    Using Parser : Raw BINARY
    Interface serial_posix: 57600 8E1
    Version      : 0x31
    Option 1     : 0x00
    Option 2     : 0x00
    Device ID    : 0x0444 (STM32F03xx4/6)
    - RAM        : 4KiB  (2048b reserved by bootloader)
    - Flash      : 32KiB (size first sector: 4x1024)
    - Option RAM : 16b
    - System RAM : 3KiB
    Write to memory
    Erasing memory
    Wrote and verified address 0x08000c2c (100.00%) Done.
    

    Then disconnect all the wires (including the RTS pin), connect the shield to your WeMos D1 Mini, and it should work.

  • We Have a Fixed Firmware!

    deʃhipu04/21/2017 at 17:21 5 comments

    @Piotr Bugalski has recently re-written the firmware for this motor shield, and published it at https://github.com/pbugalski/wemos_motor_shield. From what I can tell, the new firmware is compatible with the old one, minus the hanging and crashing, so it should be perfect for a drop-in replacement.

    Here is how you can flash it to your shield:

    Solder two wires to the first two legs of the microcontroller, counting from the top, like this:

    Be careful to not short them with the legs next to them. This is probably the hardest part.

    Next, connect you ST-Link programmer as follows:

    SWCLK ↔ first wire

    SWDIO ↔ second wire

    GND ↔ GND

    3V3 ↔ 3V3

    T_JRST ↔ RST

    Note that, this is with the shiled *not* connected to the D1 Mini.

    Now, clone the repository:

    $ git clone https://github.com/pbugalski/wemos_motor_shield
    $ cd wemos_motor_shield

    Make sure you have installed openocd and arm-none-eabi-gcc. Compile the firmware:

    $ make
    arm-none-eabi-gcc -Wall -g -std=c99 -Os -mlittle-endian -mcpu=cortex-m0 -march=armv6-m -mthumb -ffunction-sections -fdata-sections -Wl,--gc-sections -Wl,-Map=motor_shield.map -Iinc src/startup_stm32.s src/main.c src/user_i2c.c src/tb6612.c -o motor_shield.elf -Tstm32f030.ld
    arm-none-eabi-objcopy -O binary motor_shield.elf motor_shield.bin
    arm-none-eabi-size motor_shield.elf
       text	   data	    bss	    dec	    hex	filename
       2032	   1084	   1056	   4172	   104c	motor_shield.elf
    

    And flash it onto the shield:

    $ make program
    openocd -f stm32f0motor.cfg -f stm32f0-openocd.cfg -c "stm_flash motor_shield.bin" -c shutdown
    Open On-Chip Debugger 0.9.0 (2015-09-02-10:42)
    Licensed under GNU GPL v2
    For bug reports, read
    	http://openocd.org/doc/doxygen/bugs.html
    Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
    adapter speed: 1000 kHz
    adapter_nsrst_delay: 100
    none separate
    srst_only separate srst_nogate srst_open_drain connect_deassert_srst
    Info : Unable to match requested speed 1000 kHz, using 950 kHz
    Info : Unable to match requested speed 1000 kHz, using 950 kHz
    Info : clock speed 950 kHz
    Info : STLINK v2 JTAG v17 API v2 SWIM v4 VID 0x0483 PID 0x3748
    Info : using stlink api v2
    Info : Target voltage: 3.490340
    Info : stm32f0x.cpu: hardware has 4 breakpoints, 2 watchpoints
    stm_erase
    target state: halted
    target halted due to debug-request, current mode: Thread 
    xPSR: 0xc1000000 pc: 0xfffffffe msp: 0xfffffffc
    auto erase enabled
    Info : device id = 0x10006444
    Info : flash size = 16kbytes
    target state: halted
    target halted due to breakpoint, current mode: Thread 
    xPSR: 0x61000000 pc: 0x2000003a msp: 0xfffffffc
    wrote 4096 bytes from file motor_shield.bin in 0.287988s (13.889 KiB/s)
    target state: halted
    target halted due to breakpoint, current mode: Thread 
    xPSR: 0x61000000 pc: 0x2000002e msp: 0xfffffffc
    verified 3116 bytes in 0.057512s (52.910 KiB/s)
    shutdown command invoked
    
    Now, disconnect everything. Your board has the new firmware on it. You can test it, and then desolder the two wires -- you won't be needing them anymore.

  • SWD Programming Continued

    deʃhipu11/22/2016 at 20:59 1 comment

    On a quest to configure OpenOCD properly. First of all, the error I'm getting was described in an issue and seems like adding "reset_config none separate" fixes that. I got a new error with this:

    openocd -f extra/fff.cfg -f extra/stm32f0-openocd.cfg -c "stm_flash `pwd`/main.bin" -c shutdown
    Open On-Chip Debugger 0.9.0 (2015-09-02-10:42)
    Licensed under GNU GPL v2
    For bug reports, read
    	http://openocd.org/doc/doxygen/bugs.html
    Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
    adapter speed: 1000 kHz
    adapter_nsrst_delay: 100
    none separate
    srst_only separate srst_nogate srst_open_drain connect_deassert_srst
    Info : Unable to match requested speed 1000 kHz, using 950 kHz
    Info : Unable to match requested speed 1000 kHz, using 950 kHz
    Info : clock speed 950 kHz
    Info : STLINK v2 JTAG v17 API v2 SWIM v4 VID 0x0483 PID 0x3748
    Info : using stlink api v2
    Info : Target voltage: 3.504912
    Info : stm32f0x.cpu: hardware has 4 breakpoints, 2 watchpoints
    none separate
    stm_erase
    target state: halted
    target halted due to debug-request, current mode: Handler HardFault
    xPSR: 0xc1000003 pc: 0xfffffffe msp: 0xfffffffc
    auto erase enabled
    Info : device id = 0x10006444
    Info : flash size = 16kbytes
    Error: stm32x device protected
    Error: failed erasing sectors 0 to 0
    OK, so apparently the chip is write-protected. No problem, we can unlock it with "stm32x unlock 0". After running that, and resetting the chip, I finally got:
    openocd -f extra/fff.cfg -f extra/stm32f0-openocd.cfg -c "stm_flash `pwd`/main.bin" -c shutdown
    Open On-Chip Debugger 0.9.0 (2015-09-02-10:42)
    Licensed under GNU GPL v2
    For bug reports, read
    	http://openocd.org/doc/doxygen/bugs.html
    Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
    adapter speed: 1000 kHz
    adapter_nsrst_delay: 100
    none separate
    srst_only separate srst_nogate srst_open_drain connect_deassert_srst
    Info : Unable to match requested speed 1000 kHz, using 950 kHz
    Info : Unable to match requested speed 1000 kHz, using 950 kHz
    Info : clock speed 950 kHz
    Info : STLINK v2 JTAG v17 API v2 SWIM v4 VID 0x0483 PID 0x3748
    Info : using stlink api v2
    Info : Target voltage: 3.506483
    Info : stm32f0x.cpu: hardware has 4 breakpoints, 2 watchpoints
    none separate
    stm_erase
    target state: halted
    target halted due to debug-request, current mode: Thread 
    xPSR: 0xc1000000 pc: 0xfffffffe msp: 0xfffffffc
    auto erase enabled
    Info : device id = 0x10006444
    Info : flash size = 16kbytes
    target state: halted
    target halted due to breakpoint, current mode: Thread 
    xPSR: 0x61000000 pc: 0x2000003a msp: 0xfffffffc
    wrote 1024 bytes from file /home/sheep/dev/3rdparty/stm32f0-discovery-basic-template/main.bin in 0.104813s (9.541 KiB/s)
    target state: halted
    target halted due to breakpoint, current mode: Thread 
    xPSR: 0x61000000 pc: 0x2000002e msp: 0xfffffffc
    verified 980 bytes in 0.030723s (31.150 KiB/s)
    shutdown command invoked
    

    Which seems to be a correct flashing.

    All this thanks to advice from @jaromir.sukuba, great thanks!

    Now let's see if I can get a blink example to work...

  • SWD Programming

    deʃhipu11/22/2016 at 20:06 0 comments

    Second approach to this is using the SWD protocol with my Chinese ST-Link V2 clone. That requires getting at the SWD pins. Fortunately, they are near the edge of the chip:

    Then I connected it according to the pinout of my programmer (the second one):

    Now just "make program" in that template, and...

    openocd -f /usr/share/openocd/scripts/board/stm32f0discovery.cfg -f extra/stm32f0-openocd.cfg -c "stm_flash `pwd`/main.bin" -c shutdown
    Open On-Chip Debugger 0.9.0 (2015-09-02-10:42)
    Licensed under GNU GPL v2
    For bug reports, read
    	http://openocd.org/doc/doxygen/bugs.html
    Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
    adapter speed: 1000 kHz
    adapter_nsrst_delay: 100
    none separate
    srst_only separate srst_nogate srst_open_drain connect_deassert_srst
    Info : Unable to match requested speed 1000 kHz, using 950 kHz
    Info : Unable to match requested speed 1000 kHz, using 950 kHz
    Info : clock speed 950 kHz
    Info : STLINK v2 JTAG v17 API v2 SWIM v4 VID 0x0483 PID 0x3748
    Info : using stlink api v2
    Info : Target voltage: 3.497322
    Info : stm32f0x.cpu: hardware has 4 breakpoints, 2 watchpoints
    stm_erase
    Error: timed out while waiting for target halted
    TARGET: stm32f0x.cpu - Not halted
    in procedure 'stm_flash' 
    in procedure 'reset' called at file "extra/stm32f0-openocd.cfg", line 8
    in procedure 'ocd_bouncer'
    
    
    Makefile:72: recipe for target 'program' failed
    make: *** [program] Error 1
    

    Failure.

    I suspect that I shouldn't be using the configuration for the discovery board, but somehow write my own, however, I can't seem to be able to find any examples...

  • Serial Programming

    deʃhipu11/21/2016 at 10:12 1 comment

    Last evening I made the first try at programming this thing. From the datasheet and the schematic it looks straightforward: the BOOT0 pin is connected to the RTC pin of the serial, the NRST pin is connected to DTR, it should just work. So I connected the USB2TTL (also a WeMos one), and gave it a go:

    $ stm32flash /dev/ttyUSB0
    stm32flash 0.5
    
    http://stm32flash.sourceforge.net/
    
    Interface serial_posix: 57600 8E1
    Failed to init device.

    No joy. To the datasheet then! Hmm, they mention a BOOT1 there too, but it's nowhere to be seen as a pin... Let's google for it... http://stackoverflow.com/questions/22351703/stm32f030-and-boot0-pin Ah-ha! It looks like BOOT1 is a flag in something called "user flash option byte", and it has to be set to 0 for the bootloader to start. Shame I have no way to check it.

    If that flag is set to 1 in this firmware, then the only way to reprogram this board is to use an stlink programmer. Fortunately, I do have one! Unfortunately, the SWD and SWC pins are not broken out, so I guess I will need to do some precision soldering directly to the chip's legs. Oh well.

View all 6 project logs

Enjoy this project?

Share

Discussions

yigalb wrote 11/13/2020 at 08:54 point

After cloning from GitHub, the make doesn't work. What do I need to do in order to do it?

I run it from cmd window.

More details: I have several motor shields from AliExpress. None of them is detected during I2C scan. The Ad0/1 resistors are not attached to the boards, yet the I2C scanner doesn't recognize at Hex 2D. I have no idea what is the Motor shield's version: no marking on the pcb. I use WEMOS D1 mini on top of the shield. 

  Are you sure? yes | no

deʃhipu wrote 11/13/2020 at 09:14 point

Perhaps contact the seller for support.

  Are you sure? yes | no

yigalb wrote 11/17/2020 at 14:28 point

Thanks, but I don't think Ali Express will support me with that, but see my post: I found the answer. 

  Are you sure? yes | no

deʃhipu wrote 11/17/2020 at 14:54 point

Despite selling on Aliexpress, WeMos supports their products and answers if you contact them. Not sure about other random sellers who just cloned the design without understanding it, but that's a price you pay by paying lower price, I guess.

  Are you sure? yes | no

yigalb wrote 11/17/2020 at 14:27 point

OK, I found the answer: on the back of the shield, there is a jumper to set the standby mode, either controlled by I2C bus (what I want), or by the S signal from the shield's pinout. I soldered the I2C mode, and now it is functioning well. So few things need to be done with the shields: upgrade firmware and solder the jumper before usage.

  Are you sure? yes | no

Daniel Herrera wrote 10/10/2020 at 22:35 point

Hi! Do you know if there is the firmware for the v2.0 motor shield around? I would like to see if we can add a stepper feature since sending step by step commands through i2c does not look appropriate. Thanks.

  Are you sure? yes | no

raichea wrote 08/11/2020 at 18:41 point

I bought a v1.0.0 motor shield a couple of months or so ago... pretty sure it's a clone. Anyway, I had problems with getting it going. First off, I had to bridge the standby jumper on the back (I chose i2c rather than IO). It kind of worked then but not great.

Then I discovered this page. I flashed the new firmware and it works pretty well but the PWM settings are way off. Looking at some of the forks of the pbugalski software, I found this one: https://github.com/fabiuz7/wemos_motor_shield. It needs a rewrite of the bootloader as well as the main code as he's added the ability to update the firmware  using i2c (I haven't tried it). However, there are fixes in there so that the i2c address jumpers work as expected and the pwm accurately gives the %age pulse width going to the motors. Recommended!

  Are you sure? yes | no

Dmitry wrote 07/25/2020 at 12:04 point

Hello!

I connected this Motor driver to Arduino UNO.

It detected on address 0x30 very well but nothing happens when I'm trying to control it with Wemos library.

Can somebody help me?

  Are you sure? yes | no

deʃhipu wrote 07/25/2020 at 19:47 point

Perhaps you should contact their support. This is not the right place.

  Are you sure? yes | no

Dmitry wrote 07/27/2020 at 07:56 point

Ok.

Thank you.

  Are you sure? yes | no

Angelote wrote 12/14/2018 at 09:03 point

I wrote firmware for STM23f030 to drive a stepper  in microstep mode,at this time working version  use serial port but in testing I2C interface,I used Libopencm3 libraries,it lacks of I2C slaves examples but i think is almost ready .

https://www.youtube.com/watch?v=7XQXp-VcUK8

Stepper  runs quiet and smooth  ,not as my two daugthers in background.

  Are you sure? yes | no

tof wrote 10/23/2018 at 19:19 point

Thank you for this. I found out you don't even need any additional hardware to update your Wemos Motor Shield. Only a Wemos. See here: https://github.com/thomasfredericks/wemos_motor_shield

  Are you sure? yes | no

deʃhipu wrote 10/23/2018 at 19:39 point

Nice trick! Thanks!

  Are you sure? yes | no

trulala wrote 08/29/2018 at 13:13 point

Wemos Motor Shield Plugin is now in official ESPeasy mega release!

See wiki:
https://www.letscontrolit.com/wiki/index.php/WemosMotorshield

  Are you sure? yes | no

trulala wrote 08/19/2018 at 11:14 point

Hi all,
does anybody know why there is 2x a  'delay(100); ' in WEMOS_Motor.cpp of the original wemos library? Is this really needed? I am trying to get my plugin included by pull request into ESPeasy, but developers complain about it as blocking.

thx

  Are you sure? yes | no

deʃhipu wrote 08/19/2018 at 15:39 point

I think you should ask the author, but judging by the quality of that code, they don't know either.

  Are you sure? yes | no

Daniel Oliveira wrote 08/10/2018 at 19:45 point

Hello all,
Just wondering if someone got the firmware working/building with platformIO.
I gonna try myself but please let me know if you have any hints (newbie here)

  Are you sure? yes | no

deʃhipu wrote 08/10/2018 at 21:37 point

Sorry, I really have no idea about platformio, can't help you there. I don't even understand why you would want to build it with that, when it builds with standard gcc just fine.

  Are you sure? yes | no

trulala wrote 05/23/2018 at 19:46 point
Hi all, thx for the fix. I would like to use ESPeasy with the D1 mini and motorshield. But currently there is no plugin available, only for the Adafruit motor shield. Is anybody able to support me in writing a plugin for ESPeasy?

https://www.letscontrolit.com/forum/viewtopic.php?f=6&t=2844&p=28237#p28237

  Are you sure? yes | no

JackJamesHoward wrote 04/09/2018 at 15:07 point

Does anybody know how to reprogram the STM32F030 to step a stepper motor instead of running two DC motors at a speed.?

  Are you sure? yes | no

janitammi wrote 03/24/2018 at 21:15 point

Profound thank you for this project!

  Are you sure? yes | no

jenya wrote 03/10/2018 at 23:53 point

It Works! 

Thanks Man!  awesome patch ;) 

  Are you sure? yes | no

igor nakonechnyi wrote 02/17/2018 at 19:55 point

Thank you so much for this manual!
I've got this Chinese clone of Wemos D1 Motor Shield which was not detectable via I2C and thanks to your post I was able to make it work! Unfortunately I was not able to build my own firmware but your built worked perfectly.  

  Are you sure? yes | no

Ian Ferguson wrote 11/09/2017 at 14:18 point

Intermittent i2c with new firmware?

==============================

First of all, thanks to all of you who've contributed this stuff!

I've been been playing with this for weeks now and I'm going to admit that I'm stuck.

My motor shield seems to be intermittent in its i2c communication.  I've *think* I've managed to upload the new firmware to it (I used the  motor_shield_30.bin binary as I have some problems getting the tool chain to work on my Mac). When I ran the: 

stm32flash -v -w motor_shield_30.bin  /dev/cu.usbserial-A400hAYA

command it responded:

Using Parser : Raw BINARY
Interface serial_posix: 57600 8E1
Version      : 0x31
Option 1     : 0x00
Option 2     : 0x00
Device ID    : 0x0444 (STM32F03xx4/6)
- RAM        : 4KiB  (2048b reserved by bootloader)
- Flash      : 32KiB (size first sector: 4x1024)
- Option RAM : 16b
- System RAM : 3KiB
Write to memory
Erasing memory
Wrote and verified address 0x08000c20 (100.00%) Done.

I assume that means it worked. Can someone confirm that for me please?

After reassembling the shield and my Wemos, I ran one the i2c scanner sketches but nothing was found.

I followed Matrix User and arn_a's advice and checked the "standby" solder pads on the back of the board. This was very poorly soldered so I re-did it.

Again I reassembled and ran the scanner.  It found a device at 0x30 for several iterations of the scan and then went back to saying "No devices found."

Just for the hell of it, I ran my motor test sketch. Sometimes the motor runs when I tell, sometimes it doesn't - consistent with the i2c comms sometimes working and sometimes not.

I've checked the electrical connections - all seems ok. Looking at i2c pulses on a 'scope suggests that the pulses are 'clean'.

Any ideas on what I'm doing wrong please?

  Are you sure? yes | no

Matrix User wrote 10/08/2017 at 02:33 point

I have two of these on the same circuit. I have soldered the pads on the back side in an attempt to change the I2C address of one so I can use both at the same time. No matter what I do the pads, I can't seem to change the default address. I don't know if this firmware ignores those pads or something else it wrong. Any ideas? Does the following concept still applies to this firmware?

AD1      AD0
–          –         0x2D
–          x         0x2E
x          –         0X2F
x          x          0x30 (défaut)

  Are you sure? yes | no

Matrix User wrote 11/08/2017 at 03:59 point

  Are you sure? yes | no

Matrix User wrote 10/01/2017 at 14:54 point

Actually, I did the steps. The I2C scan sketch can read 0x30 (which it couldn't before). I have applied 12v to VM and GND pins. A1 and A2 has a 12v DC motor attached. I can read 12v using a multimeter across the VM and GND pins but I can't read any voltage on A1/A2 or B1/B2 pins and the motor never spins using the stock Arduino sketch. If I directly apply 12v to the same motor it spins. Any ideas?

  Are you sure? yes | no

Matrix User wrote 10/02/2017 at 09:49 point

Never mind. I read aarn_a comment and seems like this one also had the IO pad soldered for standby mode. I unsoldered it and soldered the I2C pads and everything works now. I didn't think to look there as all documentation said that I2C is standard/default on these boards for standby mode. 

  Are you sure? yes | no

Matrix User wrote 10/01/2017 at 04:01 point

Thank you so much guys. I also had a china shield that won't come up in i2c scan sketch. Luckily, I had a serial adapter from a few years ago that I used with Mini Pro. I hooked it up to windows, ran the exe and uploaded the bin in like 2 minutes and it started responding!!

  Are you sure? yes | no

aarn_a wrote 09/19/2017 at 19:54 point

I think your Wemos shield is in IO mode for Standby (see schematic below). Just wire between S and 3.3V to try.

Mine was in that case. I reprogrammed without soldering very easily and it's works now. 

  Are you sure? yes | no

srk999 wrote 09/17/2017 at 18:25 point

I was following this tutorial to recycle an RC car (https://diyprojects.io/recycle-remote-controlled-car-rc-car-esp8266-shield-motor-wemos-d1-mini-blynk/). Connected the Wemos D1 mini (https://wiki.wemos.cc/products:d1:d1_mini) to the motor shield (https://wiki.wemos.cc/products:d1_mini_shields:motor_shield). Tested all the connection to see if the motors work when power is supplied to the pins, and they do. But, I cannot make the board send power to the motor shield pins A1, A2, B1, B2 for some reason. VM and GND of the shield are connected to an external 5V power supply (4x1.2V AA). D1 mini is being powered by the USB data cable. 

When I connect VM/GND to A1/A2, I see a reaction in the motor, and same goes for the other motor. So, that seems to be working. Now, how do I make the sketch send power to the motors? I'm testing it with the examples from the motor shield library (https://github.com/wemos/WEMOS_Motor_Shield_Arduino_Library).

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates