Motor Shield Reprogramming

Description

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!

Details

We have pretty good information about the motor shield:

The H-bridge is TB6612.
The microcontroller is STM32F030.
We have a schematic: https://www.wemos.cc/sites/default/files/2016-09/mini_motor.pdf
We have the Arduino library for talking to it: https://github.com/wemos/WEMOS_Motor_Shield_Arduino_Library
And, last but not least, we finally have the source code of the original firmware: https://github.com/wemos/Motor_Shield_Firmware

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

Files

motor_shield.bin

Compiled binary of the new firmware.

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

Download

Project Logs

Collapse

Multiple I²C Addresses
deʃhipu • 11/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ʃhipu • 04/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ʃhipu • 04/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ʃhipu • 11/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ʃhipu • 11/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ʃhipu • 11/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

Discussions

yigalb wrote 11/13/2020 at 08:54

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

Perhaps contact the seller for support.

Are you sure? yes | no

yigalb wrote 11/17/2020 at 14:28

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

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

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

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

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

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

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

Ok.

Thank you.

Are you sure? yes | no

Angelote wrote 12/14/2018 at 09:03

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

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

Nice trick! Thanks!

Are you sure? yes | no

trulala wrote 08/29/2018 at 13:13

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

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

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

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

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

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

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

Angelote wrote 12/27/2018 at 20:47

https://hackaday.io/project/162981-wemos-motor-shield-firmware-for-steppers

Are you sure? yes | no

janitammi wrote 03/24/2018 at 21:15

Profound thank you for this project!

Are you sure? yes | no

jenya wrote 03/10/2018 at 23:53

It Works!

Thanks Man! awesome patch ;)

Are you sure? yes | no

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

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

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

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

If you would like to use more than one in your project, cax has been nice enough to compile 4 different versions for the hardcoded line https://github.com/pbugalski/wemos_motor_shield/blob/master/src/main.c#L72

https://github.com/pbugalski/wemos_motor_shield/issues/3

https://github.com/pbugalski/wemos_motor_shield/files/1434679/motor_shield_XX_bin.zip

Are you sure? yes | no

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

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

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

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

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

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

Motor Shield Reprogramming

Description

Details

Files

motor_shield.bin

Project Logs

Collapse

Multiple I²C Addresses

Reprogramming Without Soldering

We Have a Fixed Firmware!

SWD Programming Continued

SWD Programming

Serial Programming

Discussions

Similar Projects

MiCE47

PIC10f200 Tiny TPI programmer

Getyoo Clickey NFC tag reverse engineering

PIC89PROG

Motor Shield Reprogramming

Become a Hackaday.io member

Just one more thing

Description

Details

Files

motor_shield.bin

Project Logs Collapse

Enjoy this project?

Discussions

Become a Hackaday.io Member

Similar Projects

Does this project spark your interest?

Project Logs

Collapse