D1 mini pro + i2c motor shield problems



  • Hi!
    I recently got the D1 mini pro with the i2c motor shield.
    I could not get the shield to work and found that there are known problems.
    There seem to be some old forum topics on this problem but they don't seem accessible at the moment.
    The problem seems to be related to the chip handling the i2c communications, as i don't even find any device on the i2c bus when scanning with an arduino sketch.
    Is there a known fix for this problem?



  • Hello @ottojo ,

    I just recognized that the old forum is gone. The upgrade removed all old entries.

    There were quite a discussion around this issue. There are basically two solutions.

    • get the firmware for the ST micro which is on the motor shield and correct the error.
    • periodically repeat the last command.

    The first solution appears to be quite difficult, as some of the ST micros are locked or at least difficult to re-program.

    The second solution is the easiest one. It's based on the fact that there seems to be a kind of time-out for the I2C communcation of 10 seconds. If you repeat the last command, which should not hurt, periodically let's say every 5 seconds, the I2C communication is kept alive and no timeout on the motor shield micro appears.

    Please note: this is not related to the D1 mini shields, nor to the ESP8266.
    best regards
    7th Dwarf



  • Hi @ottojo ,

    This is what I did...with the boards shipped to me, I found that the STM32 was not programmed (no i2c address when scanned) and could be flashed. It sounds like you have also been shipped the the un-programmed ones, which is fortunate, as you just need to ensure the pin marked 'RTS' on the board (connected to boot0 on the STM32) is kept high to flash them. I haven't fixed the code, but applied a band-aid to reset i2c comms when the code enters the "while (HAL_I2C_GetState(&hi2c1) != HAL_I2C_STATE_READY)" loop in main(void) and the while loop in Error_Handler(void) . The code added in the main(void):

      /*set the timer before going into the loop*/
    	i2cstoredTime = HAL_GetTick();
    
      while (HAL_I2C_GetState(&hi2c1) != HAL_I2C_STATE_READY)
    	{
                       /* This code addition stops the i2c Scanner from locking up the SCL line */
    		if(HAL_GetTick() - i2cstoredTime > i2c_timeout)
    		{
    			i2cstoredTime = HAL_GetTick();
    			Error_Handler(); //restart i2c bus as well
    		}
    	} 
    

    Need to define i2cstoredTime as a uint32_t variable and define i2c_timeout as some value (I chose 1000ms). For the Error_Handler:

    void Error_Handler(void)
    {
    /* USER CODE BEGIN Error_Handler*/
    /* User can add his own implementation to report the HAL error return state*/
    while(1) 
        {
    /* This restarts the i2c after the I2C_TIMEOUT_ADDR or the SCL lock up occurs*/
            if (HAL_I2C_Init(&hi2c1) == HAL_OK) 
    	{
    		break;
    	}
        }
    /* USER CODE END Error_Handler */ 
    }
    

    The I2C_TIMEOUT_ADDR is actually useful to set an all-stop protection condition on the motor controller if the main controller hangs or the i2c is locked by another device. If you're interested I'll post these code additions as well.

    Lastly, this isn't a proper fix to the problem rather a quick hack to make it work for my application.

    Good luck!



  • My project was going really well until I got to the motor sheild!

    It very rarely comes up on a i2c scan although some times resetting the power to the sheild allows it to be seen on the first scan.

    New to all this so struggling to work out how to fix the firmware.

    Seen this site but still lacks the detail I need to work out what files I need to put back on
    https://hackaday.io/project/18439-motor-shield-reprogramming

    Is anyone able to help with a little more info

    Many thanks.



  • Scanning will crash the shield, as will anything that doesn't send exactly 4 bytes to it. It will also crash on its own when not talked to for a while. When it crashes, it pulls down the SDA and SCL lines, so it becomes impossible to communicate with it or any other device on the same I2C bus.

    As far as I know there is currently no fixed version of the firmware available. I did attempt to work on that a little (as you can see on the website you linked), but my lack of experience with the platform makes this difficult. I also asked several more experienced people for help, but they are all busy with the projects of their own or their day jobs -- they did promise to look into that within a few months, though, so there is hope.



  • @g1x you just need to download the firmware from https://github.com/wemos/Motor_Shield_Firmware, re-compile with my suggested changes and upload to the STM32 using. For editing the firmware and re-compiling, I used Keil uVision5 MDK-Lite with STM32F0 MDK -http://www2.keil.com/stmicroelectronics-stm32/mdk. For connecting the STM32 to your PC I used this board http://www.ebay.com.au/itm/Pro-FT232RL-3-3V-5-5V-FTDI-USB-to-TTL-Serial-Adapter-Module-Arduino-Mini-Port-/112046074073?hash=item1a167768d9:g:u5UAAOSwvg9XeNBY, but any USB2TTL device should work fine.The STM32 flash loader demonstrator was then used to reflash the controller with the binary file generated by the Keil compiler - http://www.st.com/en/development-tools/flasher-stm32.html. Just a couple of tips - the RTS pin on the Wemos controller (boot0) on the STM32 needs to be held hi to flash, which means you can't connect directly the USB2TTL adapter. The default 'even' parity on the STM32 flasher does not work and needs to be changed to odd (I think from memory, or maybe none). It sounds like a lot of steps and stuffing around, but it is fairly quick to do.

    Good luck with it!


Log in to reply
 

Looks like your connection to WEMOS Forum was lost, please wait while we try to reconnect.