 |
| From Chris’ Miscellanea |
The bootloader seems to initialize the modules' serial port to the pretty insane value of 76923 bps, so that in "programming" mode, the stupid windows-utility (or, for that matter, any program expecting standard-baudrates) will fail to communicate with the module.
 |
| From Chris’ Miscellanea |
If you have a suitable serial cable (a FTDIchip FT2232 is what I used), you can calculate "custom dividers" for most uncommon baudrates, and use those instead of 38,4kBps (the "magic" baudrate indicating that the custom one should be used).
Base-frequency for the ft2232 is 60 Mhz, so we'll use a custom divisor of 780 (60Mhz/76923).
$ setserial /dev/ttyUSB0 spd_cust divisor 780
$ cu -l ttyUSB0 -s 38400
Connected.
ets Jan 8 2013,rst cause:1, boot mode:(7,7)
waiting for host
ets Jan 8 2013,rst cause:1, boot mode:(7,7)
waiting for host
ets Jan 8 2013,rst cause:1, boot mode:(3,7)
load 0x40100000, len 24444, room 16
tail 12
chksum 0xe0
ho 0 tail 12 room 4
load 0x3ffe8000, len 3168, room 12
tail 4
chksum 0x93
load 0x3ffe8c60, len 4956, room 4
tail 8
chksum 0xbd
csum 0xbd
Interestingly, that seems to be only the bootloader of the module, after this, the device switches to the more common 115200kbps and responds to AT-commands, given that GPIO15=GND, GPIO2=Vcc, GPIO0=Vcc and CH_PD=Vcc. (pullups to Vcc via ~5kΩ resistor)
So, to get the windows-only updater to run successfully, we...
- connect GPIOs and CH_PD as listed above (AT-Mode)
- power up module
- module will start bootloader with 77kbps, then change into AT-command mode, at 115200 bps
- connect GPIO0 to GND (firmware download mode)
- pulse CH_PD to LOW to restart module
- firmware will restart, but bootloader does NOT go back to 77kbps
- run firmware-upgrade in windows
 |
| From Chris’ Miscellanea |
Now I'm upgraded to version 170901 (whatever that means).
AT+GMR
00170901
