ATWINC1500-MR210PB1952 Firmware update via UART

Continuing the discussion from WINC1500 problem:

RESOLVED

PLEASE NOTE:
THIS PROCEDURE HAS BEEN USED TO BRING TO THE LATEST VERSION SOME ATWINC1500-MR210PB1952 MODULES
which could not work with the TinyClr because at least version 19.5.4 is required and all this was done so as not to throw them away since the SPI was not usable and there was no kind of response from the module.
So if you are updating a working WINC1500 with firmware greater than or equal to 19.5.4 and you want to do it using the UART you are doing it at your own risk.

Then the thing is a little more complicated …
Prerequisites:

Firmware update project named “WINC1500_FIRMWARE_UPDATE_PROJECT.7z” from https://microchipsupport.force.com/s/article/How-to-update-WINC1500-module-to-19-7-6-release-using-ASF3-51

Python for Windows installed like “python-3.10.5-amd64.exe”

Unzip “WINC1500_FIRMWARE_UPDATE_PROJECT.7z” and go to “WINC1500_FIRMWARE_UPDATE_PROJECT\src\firmware” folder.

First you need to edit the download_all.bat bat to add a pause at line 73

:: winc_programmer_uart.exe -d wincXX00 -e -i m2m_image_XX00.bin -if prog -w -r -p \\.\COM73 -pfw ..\programmer_firmware\releaseXX00\programmer_firmware.bin
echo Call %ptool% -d winc%CHPFAM% -i m2m_image_%VARIANT%.bin -if prog -e -w -r -pfw ..\programmer_firmware\release%VARIANT%\%PFW%
pause 
%ptool% -d winc%CHPFAM% -i m2m_image_%VARIANT%.bin -if prog -e -w -r -pfw ..\programmer_firmware\release%VARIANT%\%PFW%
if %ERRORLEVEL% NEQ 0 GOTO FAILED  
goto SUCCESS

This thing has been explained in the Microchip blog where it is indicated that an initialization must be performed again between the call to the bat update_pll_table.bat and the firmware update.
What I could understand is that the module initially initiates a communication at 115200 baud and then switches to a higher communication speed while writing and verifying the firmware. Unfortunately, after the first batch, the query to the module does not take into account the last status of the same and does not receive a response from it due to the incorrect setting of the same.
Therefore, starting from this assumption and from the fact that I have 10 boards with the WINC1500 with version 19.5.2 mounted, I wrote a SC20100 application like this:

            var en = GpioController.GetDefault().OpenPin(SC20100.GpioPin.PC7);
            var rst = GpioController.GetDefault().OpenPin(SC20100.GpioPin.PD6);
            en.SetDriveMode(GpioPinDriveMode.Output);
            rst.SetDriveMode(GpioPinDriveMode.Output);
            en.Write(GHIElectronics.TinyCLR.Devices.Gpio.GpioPinValue.Low);
            rst.Write(GHIElectronics.TinyCLR.Devices.Gpio.GpioPinValue.Low);
            System.Threading.Thread.Sleep(1);
            en.Write(GHIElectronics.TinyCLR.Devices.Gpio.GpioPinValue.High);
            System.Threading.Thread.Sleep(10);
            rst.Write(GHIElectronics.TinyCLR.Devices.Gpio.GpioPinValue.High);
            Debug.WriteLine("WINC1500 UART IS READY");
            System.Threading.Thread.Sleep(-1);

Connect the USB-TTL adapter with TXD and RXD pins only to the module and do not power or take power from the adapter, only the ground.
After compilation and distribution remove the power supply (or USB cable) of circuit that mounts the SC20100 and the WINC1500.
The SPI is clearly not used by the MPU and is not configured. Only the GPIO lines related to CHIP_EN and RST are used.

  1. Insert the USB socket of the SC20100 and allow a first spin to the application in order to initialize the UART of the WIN1500 correctly.
  2. At this point, execute the bat download_all.bat with UART 1500 0 n parameters where n is the COM number where TTL adapter is inserted.
    The batch file first downloads the latest firmware version to local folder WINC1500_FIRMWARE_UPDATE_PROJECT\src\firmware\firmware and execute update_pll_table.bat, after a while the change made pauses the batch … it will require you to press a key to continue.
  3. Remove power from the SC20100 circuit by disconnecting the USB.
  4. Wait a few seconds to be sure
  5. Reconnect the USB plug again
  6. Wait at least one second for the initialization procedure to be completed.
    At this point is time to …
  7. Press any key to proceed with the batch

… magically the update procedure starts and passes the UART response check and the firmware update ends
Now as version I have 19.7.6.19389… :sweat_smile: and WIFI examples from GHI tutorial now work great on these modules as well.

1 Like

Thanks for sharing… We may document it for updating by UART.

As I wanted to specify,
USE IT ONLY WITH MODULES THAT DO NOT RESPOND TO THE SPI INTERFACE
therefore versions previous to the minimum request as you specified 19.5.4
… in order not to throw away modules that in any case would not work.
I saw that from 19.5.4 you can easily update them via wifi and everything goes smoothly

For other guys who don’t like SITCore boards, they still come to our docs to read how :)).

… just two words for a clarification.
Some versions of pre-assembled modules mount a pull-up resistor on the reset line and If you connect an MPU, the reset line is high on power up before it intervenes.
The initialization sequence of the serial requires that the reset is at a low level upon power-up so remove it to update the firmware and if you want to put it back in its place at the end of the update.

1 Like