Flashing MicroPython to ESP8266 using rPi - Testing if ubinascii.unhexlify exists ...

[theMusicMan]

Hi All

Ok, so I am messing around having fun with the RPi and I am using it to flash my ESP8266 with MicroPython.

So far I have downloaded esptool and the MicroPython .bin, and have successfully erased the default flash file on the ESP8266, and successfully installed the MicroPython .bin file.

I have also successfully installed rshell as per the instructional video I am following.

However, I seem to now be in an infinite wait loop after I type the following commands to launch the rshell

Code: Select all

rshell --buffer-size=30 -p /dev/ttyUSB0

... the terminal is showing

Code: Select all

Testing if ubinascii.unhexlify exists ... 

And is just sat there doing absolutely nothing...!!

Any pointers from any experts out there please?
Many thanks,
John

[Idahowalker]

When I tried to use the RPi to interact with an ESP32, I found that, after a while, trying to figure out why it seemed to work but did not work, was that the ESP32 bin files were complied to use a Intel to ESP32 processor bin file. ESPRESSIF does not support the RPi Processor as, as was told by ESPRESSIF, the RPI system was not very capable. I hope that makes sense.

[scruss]

Worked for me. Maybe try to reinstall rshell?

Here's what I did with a Raspberry Pi Zero with an ESP8266 board attached on /dev/ttyUSB0:

Code: Select all

[email protected]:~ $ sudo pip3 install rshell
Collecting rshell
  Downloading https://www.piwheels.org/simple/rshell/rshell-0.0.18-py3-none-any.whl
Requirement already satisfied: pyserial in /usr/lib/python3/dist-packages (from rshell)
Collecting pyudev>=0.16 (from rshell)
  Downloading https://www.piwheels.org/simple/pyudev/pyudev-0.21.0-py3-none-any.whl (56kB)
    100% |████████████████████████████████| 61kB 219kB/s 
Requirement already satisfied: six in /usr/lib/python3.5/dist-packages (from pyudev>=0.16->rshell)
Installing collected packages: pyudev, rshell
Successfully installed pyudev-0.21.0 rshell-0.0.18
[email protected]:~ $ rshell --buffer-size=30 -p /dev/ttyUSB0
Using buffer-size of 30
Connecting to /dev/ttyUSB0 (buffer-size 30)...
Testing if ubinascii.unhexlify exists ... Y
Retrieving root directories ... /boot.py/
Setting time ... Feb 10, 2019 23:06:25
Evaluating board_name ... pyboard
Retrieving time epoch ... Jan 01, 2000
Welcome to rshell. Use Control-D (or the exit command) to exit rshell.
/home/pi> ls /pyboard/
boot.py
/home/pi> repl
Entering REPL. Use Control-X to exit.
>
MicroPython v1.9.4-8-ga9a3caad0 on 2018-05-11; ESP module with ESP8266
Type "help()" for more information.
>>> 
>>> print("Hello")
Hello
>>>  
/home/pi> exit

[theMusicMan]

When I tried to use the RPi to interact with an ESP32, I found that, after a while, trying to figure out why it seemed to work but did not work, was that the ESP32 bin files were complied to use a Intel to ESP32 processor bin file. ESPRESSIF does not support the RPi Processor as, as was told by ESPRESSIF, the RPI system was not very capable. I hope that makes sense.

I am using the ESP8266 though and not the ESP32. I have seem a YT video where a successful implementation was done using the RPi to install MicroPython on the ESP32.

[theMusicMan]

Thanks scruss

I get as far as where I truncated your code... then it just sits there and does northing,

Code: Select all

[email protected]:~ $ sudo pip3 install rshell
..... 
Connecting to /dev/ttyUSB0 (buffer-size 30)...
Testing if ubinascii.unhexlify exists ... 

I do get a list of files when I ctrl-c and I have had a dive into main.py to search for unbinascii.unhexlify. I am no coder, but I am wondering if unhexlify is missing from the import library. I have posted the same question on the MicroPython forums. I'll report back if I get an answer.

Another user had the same error yesterday too when trying to flash his SONOFF. Curios eh...

[scruss]

idahowalker's issues are unrelated to the issue at hand. This isn't about the ESP32 toolchain.

theMusicMan, did you mean this post: Can not flash SonOff with MP - MicroPython Forum?

Your Raspberry Pi should already have the (not very good, but adequate) serial terminal miniterm installed. Please try this:

Code: Select all

miniterm.py /dev/ttyUSB0 115200
--- Miniterm on /dev/ttyUSB0  115200,8,N,1 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---

>>> import os
>>> os.uname()
(sysname='esp8266', nodename='esp8266', release='2.2.0-dev(9422289)', version='v1.9.4-8-ga9a3caad0 on 2018-05-11', machine='ESP module with ESP8266')
>>> import ubinascii
>>> help(ubinascii)
object <module 'ubinascii'> is of type module
  __name__ -- ubinascii
  hexlify -- <function>
  unhexlify -- <function>
  a2b_base64 -- <function>
  b2a_base64 -- <function>

(use Ctrl-] to exit miniterm, btw.)

If you don't get that, you likely don't have MicroPython on your board. If the version reported is old, then it won't have ubinascii.unhexlify.

I just reprogrammed a board (a RobotDyn WIFI NodeM ESP8266, 32M flash, CH340G) entirely using a Raspberry Pi Zero. The first line of each code section is the command: that's the only bit you type.

1. Install esptool:

Code: Select all

sudo pip3 install esptool
Collecting esptool
  Downloading https://www.piwheels.org/simple/esptool/esptool-2.6-py3-none-any.whl (132kB)
    100% |████████████████████████████████| 133kB 255kB/s 
Collecting ecdsa (from esptool)
  Downloading https://files.pythonhosted.org/packages/63/f4/73669d51825516ce8c43b816c0a6b64cd6eb71d08b99820c00792cb42222/ecdsa-0.13-py2.py3-none-any.whl (86kB)
    100% |████████████████████████████████| 92kB 498kB/s 
Requirement already satisfied: pyserial>=3.0 in /usr/lib/python3/dist-packages (from esptool)
Collecting pyaes (from esptool)
  Downloading https://www.piwheels.org/simple/pyaes/pyaes-1.6.1-py3-none-any.whl
Installing collected packages: ecdsa, pyaes, esptool
Successfully installed ecdsa-0.13 esptool-2.6 pyaes-1.6.1

2. Get the firmware from Firmware for ESP8266 boards:

Code: Select all

wget https://micropython.org/resources/firmware/esp8266-20190125-v1.10.bin
--2019-02-11 16:38:45--  https://micropython.org/resources/firmware/esp8266-20190125-v1.10.bin
Resolving micropython.org (micropython.org)... 176.58.119.26
Connecting to micropython.org (micropython.org)|176.58.119.26|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 615388 (601K) [application/octet-stream]
Saving to: ‘esp8266-20190125-v1.10.bin’

esp8266-20190125-v1 100%[===================>] 600.96K  1.19MB/s    in 0.5s    

2019-02-11 16:38:46 (1.19 MB/s) - ‘esp8266-20190125-v1.10.bin’ saved [615388/615388]

3. Erase the flash:

Code: Select all

esptool.py --port /dev/ttyUSB0 erase_flash
esptool.py v2.6
Serial port /dev/ttyUSB0
Connecting....
Detecting chip type... ESP8266
Chip is ESP8266EX
Features: WiFi
MAC: 60:01:94:0c:db:ca
Uploading stub...
Running stub...
Stub running...
Erasing flash (this may take a while)...
Chip erase completed successfully in 7.5s
Hard resetting via RTS pin...

4. Write the MicroPython firmware to flash:

Code: Select all

esptool.py --port /dev/ttyUSB0 --baud 460800 write_flash --flash_size=detect 0 esp8266-20190125-v1.10.bin 
esptool.py v2.6
Serial port /dev/ttyUSB0
Connecting....
Detecting chip type... ESP8266
Chip is ESP8266EX
Features: WiFi
MAC: 60:01:94:0c:db:ca
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 460800
Changed.
Configuring flash size...
Auto-detected Flash size: 4MB
Flash params set to 0x0040
Compressed 615388 bytes to 399928...
Wrote 615388 bytes (399928 compressed) at 0x00000000 in 11.9 seconds (effective 414.1 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...

5. Check if rshell works:

Code: Select all

rshell --buffer-size=30 -p /dev/ttyUSB0
Using buffer-size of 30
Connecting to /dev/ttyUSB0 (buffer-size 30)...
Testing if ubinascii.unhexlify exists ... Y
Retrieving root directories ... /boot.py/
Setting time ... Feb 11, 2019 16:47:42
Evaluating board_name ... pyboard
Retrieving time epoch ... Jan 01, 2000
Welcome to rshell. Use Control-D (or the exit command) to exit rshell.
/home/pi> 

There may be some variation in how you use esptool. It's explained here: Deploying the firmware

[theMusicMan]

Your Raspberry Pi should already have the (not very good, but adequate) serial terminal miniterm installed. Please try this:

Code: Select all

miniterm.py /dev/ttyUSB0 115200
--- Miniterm on /dev/ttyUSB0  115200,8,N,1 ---
>

Ok, so I tried miniterm, and had this repeating error;

Code: Select all

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
ets_main.c 371 
ets Jun  8 2016 00:22:57

I then followed your steps, except I used my newly arrived ESP32, and got this...

Code: Select all

[email protected]:~ $ sudo pip3 install esptool
Requirement already satisfied: esptool in /usr/local/lib/python3.5/dist-packages
Requirement already satisfied: ecdsa in /usr/local/lib/python3.5/dist-packages (from esptool)
Requirement already satisfied: pyserial>=3.0 in /usr/lib/python3/dist-packages (from esptool)
Requirement already satisfied: pyaes in /usr/local/lib/python3.5/dist-packages (from esptool)
[email protected]:~ $ ls Download
ls: cannot access 'Download': No such file or directory
[email protected]:~ $ ls
2019-02-11-075940_1920x1080_scrot.png  Downloads      kweb-1.7.9.8         Music         Public        Videos
Desktop                                jbsensehat.py  kweb-1.7.9.8.tar.gz  oldconffiles  python_games
Documents                              john.py        kweb_about_c.html    Pictures      Templates
[email protected]:~ $ ls Downloads
dark-abstract-wallpaper.jpg             google-chrome-stable_current_amd64 (1).deb
esp32-20190207-v1.10-54-g43a894fb4.bin  google-chrome-stable_current_amd64 (2).deb
esp8266-20170108-v1.8.7.bin             google-chrome-stable_current_amd64.deb
esp8266-20190125-v1.10.bin              HD-purple-wallpaper-image-to-use-as-background-127.jpg
fadein-linux-amd64-3.0.604              light-abstract-wallpapers-for-android-For-Free-Wallpaper.jpg
fadein-linux-amd64-demo.deb             light-abstract-wallpapers-wide-For-Free-Wallpaper.jpg
fadein-linux-amd64-demo.tar.gz          purple-abstract-background-illustration-32858408.jpg
FPX13JLIVA51FTT.pdf                     silent1920x1080.jpg
FRI6JTNIVA51BFF.xls
[email protected]:~ $ wget https://micropython.org/resources/firmware/esp32-20190207-v1.10-54-g43a894fb4.bin
--2019-02-12 20:07:42--  https://micropython.org/resources/firmware/esp32-20190207-v1.10-54-g43a894fb4.bin
Resolving micropython.org (micropython.org)... 176.58.119.26
Connecting to micropython.org (micropython.org)|176.58.119.26|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1130208 (1.1M) [application/octet-stream]
Saving to: ‘esp32-20190207-v1.10-54-g43a894fb4.bin’

esp32-20190207-v1.10-54-g43a894f 100%[==========================================================>]   1.08M  1.10MB/s    in 1.0s    

2019-02-12 20:07:44 (1.10 MB/s) - ‘esp32-20190207-v1.10-54-g43a894fb4.bin’ saved [1130208/1130208]

[email protected]:~ $ esptool.py --port /dev/ttyUSB0 erase_flash
esptool.py v2.6
Serial port /dev/ttyUSB0
Connecting........_
Detecting chip type... ESP32
Chip is ESP32D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
MAC: cc:50:e3:99:fa:64
Uploading stub...
Running stub...
Stub running...
Erasing flash (this may take a while)...
Chip erase completed successfully in 7.5s
Hard resetting via RTS pin...
[email protected]:~ $ esptool.py --port /dev/ttyUSB0 --baud 460800 write_flash --flash_size=detect 0 esp32-20190207-v1.10-54-g43a894fb4.bin
esptool.py v2.6
Serial port /dev/ttyUSB0
Connecting........_
Detecting chip type... ESP32
Chip is ESP32D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
MAC: cc:50:e3:99:fa:64
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 460800
Changed.
Configuring flash size...
Auto-detected Flash size: 4MB
Compressed 1130208 bytes to 712738...
Wrote 1130208 bytes (712738 compressed) at 0x00000000 in 17.6 seconds (effective 512.3 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...
[email protected]:~ $ rshell --buffer-size=30 -p /dev/ttyUSB0
Using buffer-size of 30
connecting to serial /dev/ttyUSB0
Connecting to /dev/ttyUSB0 (buffer-size 30)...
Testing if ubinascii.unhexlify exists ... 

Other than reinstalling Raspbian, I am at a loss. Any other suggestions?

[theMusicMan]

... and now on the newly installed version of Raspbian Stretch, when I run the esptool.py command I get...

Code: Select all

bash: esptool.py: command not found

Pulling my hair out here!

[scruss]

Please try not moving the goalposts - you're now talking about an ESP32 on an upgraded Raspberry Pi!

The upgrade is good. I assumed you'd be using Stretch because everyone should be. But please try with the ESP8266 again. Are you sure that your one has enough flash? Some of the old ones have very little and you need to use a different MicroPython build.

If you upgraded Raspbian, you'll need to reinstall esptool:

Code: Select all

sudo pip3 install esptool

Also, check that the device is on /dev/ttyUSB0. It could be anywhere:

Code: Select all

ls -la /dev/ttyUSB*

One detail I neglected to add: in miniterm.py - which gets installed with PySerial when you install esptool - you have to hit Return one or more times to get the >>> MicroPython REPL prompt. Also in miniterm, to see the MicroPython REPL results, you have to type in these four commands:

Code: Select all

import os
os.uname()
import ubinascii
help(ubinascii)

The os.uname() command is to check the version of MicroPython: if it's not recent, rshell cannot work. The help(ubinascii) command is to further verify that MicroPython has the module you need.

I'm fairly sure that the problem is that your ESP board isn't flashed with MicroPython. Quite what's going wrong I don't know, but I just tried rshell with an ESP32 flashed with some other thing entirely (instead of MicroPython), and this is what I got:

Code: Select all

rshell --buffer-size=30 -p /dev/ttyUSB3
Using buffer-size of 30
Connecting to /dev/ttyUSB3 (buffer-size 30)...
Testing if ubinascii.unhexlify exists ...

Like you, it just hangs waiting for ubinascii.unhexlify to exist, which it never will.

The syntax for flashing an ESP32 is different from an ESP8266: read about it here: Firmware for ESP32 boards
The fact you're seeing flash read err in miniterm confirms that the image isn't written correctly.

[theMusicMan]

Please try not moving the goalposts - you're now talking about an ESP32 on an upgraded Raspberry Pi!

Thanks scruss for your help, really appreciated. Yep, understand the goalpost comment, but I was simply trying to figure out if this would work on another board - which it did! I managed to flash the ESP32 with MicroPython, however, on each of my ESP8266 boards, it still doesn't.

Here's the results of your suggestions...

Code: Select all

[email protected]:~ $ sudo pip3 install esptool
Requirement already satisfied: esptool in /usr/local/lib/python3.5/dist-packages
Requirement already satisfied: pyserial>=3.0 in /usr/lib/python3/dist-packages (from esptool)
Requirement already satisfied: ecdsa in /usr/local/lib/python3.5/dist-packages (from esptool)
Requirement already satisfied: pyaes in /usr/local/lib/python3.5/dist-packages (from esptool)

[email protected]:~ $ ls -la /dev/ttyUSB*
crw-rw---- 1 root dialout 188, 0 Feb 13 18:32 /dev/ttyUSB0

[email protected]:~ $ miniterm.py /dev/ttyUSB0 115200
--- Miniterm on /dev/ttyUSB0  115200,8,N,1 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---

Despite pressing return twice, miniterm.py just sits there and I am not able to type any characters into its terminal.

[scruss]

So what ESP8266 boards are they?

Can you flash them from the Arduino IDE? (Not the ancient one with Raspbian, the one you get here: https://www.arduino.cc/en/Main/Software#download than updated with the ESP8266 toolchain: esp8266/Arduino: ESP8266 core for Arduino

[theMusicMan]

So what ESP8266 boards are they?

Can you flash them from the Arduino IDE? (Not the ancient one with Raspbian, the one you get here: https://www.arduino.cc/en/Main/Software#download than updated with the ESP8266 toolchain: esp8266/Arduino: ESP8266 core for Arduino

Hi scruss

One is a Wemos D1 and the other is a NodeMCU.

Yes, I am able to successfully flash them both using the Arduino IDE and have verified this by uploading the BLINK script which runs 100%.

Also, I tested this on them both, separately, from my Mac and my RPi3B+. Each time worked perfectly. I even enabled verbose output on the Arduino so I could see the ESPTOOL statement automatically created by the Arduino IDE underneath the code as it was uploading.

[scruss]

Very odd, then. I have both boards and not had any trouble with them.

You might want to try using a different serial port rate: I've heard some can be picky. There's a whole raft of different serial chips on ESP boards: QinHeng CH340, SiLabs cp2102 (some real, some fake), FTDI (almost all fake at the cheap end). I find the QinHengs to be pretty reliable, but others don't. Maybe your boards all have different serial chips?

(Hey, at least it's better than the super-cheap "Blue Pill" boards. They copied an old open hardware design with a typo in one of the USB pull-up resistors, and several years later, most of 'em still have a completely useless USB port)

[theMusicMan]

Very odd, then. I have both boards and not had any trouble with them.

You might want to try using a different serial port rate: I've heard some can be picky. There's a whole raft of different serial chips on ESP boards: QinHeng CH340, SiLabs cp2102 (some real, some fake), FTDI (almost all fake at the cheap end). I find the QinHengs to be pretty reliable, but others don't. Maybe your boards all have different serial chips?

(Hey, at least it's better than the super-cheap "Blue Pill" boards. They copied an old open hardware design with a typo in one of the USB pull-up resistors, and several years later, most of 'em still have a completely useless USB port)

OK, I am sat in my study now, so can have a go right away... well, after I have ordered some more stuff from Amazon

Will report results back shortly...

[theMusicMan]

Very odd, then. I have both boards and not had any trouble with them.

You might want to try using a different serial port rate: I've heard some can be picky. There's a whole raft of different serial chips on ESP boards: QinHeng CH340, SiLabs cp2102 (some real, some fake), FTDI (almost all fake at the cheap end). I find the QinHengs to be pretty reliable, but others don't. Maybe your boards all have different serial chips?

(Hey, at least it's better than the super-cheap "Blue Pill" boards. They copied an old open hardware design with a typo in one of the USB pull-up resistors, and several years later, most of 'em still have a completely useless USB port)

I've set it to baud 19200... I could get to you and back before this completes... haha!

[theMusicMan]

...

Alas... just sits there again. Doing nothing. Here's the code and output.

Code: Select all

[email protected]:~ $ esptool.py --baud 19200 --port /dev/ttyUSB0 write_flash 0x1000 Downloads/esp8266-20190125-v1.10.bin 
esptool.py v2.6
Serial port /dev/ttyUSB0
Connecting....
Detecting chip type... ESP8266
Chip is ESP8266EX
Features: WiFi
MAC: 5c:cf:7f:39:d4:60
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Auto-detected Flash size: 4MB
Compressed 615388 bytes to 399928...
Wrote 615388 bytes (399928 compressed) at 0x00001000 in 211.5 seconds (effective 23.3 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...
[email protected]:~ $ rshell --buffer-size=30 -d -p /dev/ttyUSB0
Debug = True
Port = /dev/ttyUSB0
Baud = 115200
User = micro
Password = python
Wait = 0
List = 0
nocolor = 0
ascii = 0
Timing = 0
Quiet = 0
BUFFER_SIZE = 30
Cmd = []
Using buffer-size of 30
connecting to serial /dev/ttyUSB0
Connecting to /dev/ttyUSB0 (buffer-size 30)...
Testing if ubinascii.unhexlify exists ... ----- About to send 304 bytes of code to the pyboard -----
def test_unhexlify():
    """Checks the micropython firmware to see if ubinascii.unhexlify exists."""
    import ubinascii
    try:
        _ = ubinascii.unhexlify
        return True
    except:
        return False
output = test_unhexlify()
if output is None:
    print("None")
else:
    print(output)

-----

[scruss]

did you try the -fm dio option, as recommended in the options page?
doing a flash clear first helps too.

[theMusicMan]

did you try the -fm dio option, as recommended in the options page?
doing a flash clear first helps too.

Yep, I have been using the erase_flash parameter first, here is the results of these commands...

Still the same error...

Code: Select all

[email protected]:~$ esptool.py --port /dev/cu.SLAB_USBtoUART erase_flash
esptool.py v2.6
Serial port /dev/cu.SLAB_USBtoUART
Connecting........_
Detecting chip type... ESP8266
Chip is ESP8266EX
Features: WiFi
MAC: 5c:cf:7f:d9:60:45
Uploading stub...
Running stub...
Stub running...
Erasing flash (this may take a while)...
Chip erase completed successfully in 36.6s
Hard resetting via RTS pin...
[email protected]:~$ esptool.py --port /dev/cu.SLAB_USBtoUART --baud 115200 write_flash --flash_mode dio --flash_size=detect 0 ~/Desktop/esp8266-20190125-v1.10.bin
esptool.py v2.6
Serial port /dev/cu.SLAB_USBtoUART
Connecting........_
Detecting chip type... ESP8266
Chip is ESP8266EX
Features: WiFi
MAC: 5c:cf:7f:d9:60:45
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Auto-detected Flash size: 16MB
Flash params set to 0x0290
Compressed 615388 bytes to 399928...
Wrote 615388 bytes (399928 compressed) at 0x00000000 in 35.2 seconds (effective 140.0 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...
[email protected]:~$ screen /dev/cu.SLAB_USBtoUART 57600

[theMusicMan]

did you try the -fm dio option, as recommended in the options page?
doing a flash clear first helps too.

One other thing to note here scruss, is that once I have written the flash to the ESP8266, the blue led flashes very VERY quickly. When I flash the ESP8266 with the BLINK script from the Arduino IDE, this LED flashes according to the script - so something has indeed happened on the board itself i.e. some code has been transferred.

I just can't figure out for the life of me where on earth the point of failure is in the process. Let's recap and summarise:

ESPTOOL is used by the Arduino IDE and works when I flash any file to the ESP8266 using the Arduino IDE
Both the ESP8266's work perfectly when flashed with the Arduino IDE from both the Mac and RPi
ESPTOOL works fine when I flash the ESP32
RSHELL works fine when I use it on the RPi to access Micropython REPL

This is frustrating me so much that yesterday I purchased two new ESP8266's which are arriving by Amazon Prime today. Friday night play time.

Thanks for your help scruss... determined to get to the bottom of this.

[theMusicMan]

---

Hey scruss - I have an update!

The two new ESP8266's that arrived today both worked perfectly first time. I was able to erase_flash, write_flash, then rshell without the dreaded 'Tesing if unbinascii.unhexlify exists...' error.

So, it seems that there might be an issue with flashing MicroPython to older (approx 2.5-3 yrs old) ESP8266's - that's the only thing I can think this issue could possibly be related to.

So... I can still use the boards for Arduino related stuff... ah well... coding eh! Thanks for your help in this saga, much appreciated. Oh, and I too have a HAM Radio license, only foundation, I am looking to get my Kenwood TS 570D set up again soon....

73's... MW6WHL

[scruss]

If you're still interested in putting more time into this (I'd have given up ages ago), and if the suspect boards programmed under Arduino, maybe try the Arduino ESP8266 sketch CheckFlashConfig. It will return the actual amount of storage on the modules. They're probably less than the typical configuration available today and might need the small storage version of MicroPython.

There have also been reports of some 8266 boards being limited to a few flash cycles and then failing.