How to flash t-beam

[Phil Plane]

Hi,

I have been failing to get my t-beam flashed with SoftRF MB versions.

I have SoftRF 1.8 installed but have not been able to reflash with MB203.

OTA update fails with the ESP32 going into a boot loop.

Writing the SoftRF MB bin using the esp32_flash_download_tool with the same settings used to write the SoftRF 1.8 binary (offset 0x10000) fails with the esp32 going into a boot loop.

I tried ESPConnect flashing to offset 0x10000, same as above.

I tried ESPConnect flashing to offset 0x0, same as above.

Each time I was able to recover by using the esp32_flash_download_tool to write the SoftRF 1.8 binary set  (boot_app0.bin, bootloader_dio_80m.bin, SoftRF.ino.partitions.bin, SoftRF.ino.bin) to the t-beam.

I have this same issue with all three t-beams I have tried.

What is the correct flash procedure?

--

Phil Plane

[Bumpff Slam]

I flashed my T-Beam from 1.6 to MB203 last week.  I used the settings above.  I noted that Linar uses 10000, not 0x10000.

[Phil Plane]

Hi,

That's what I've been doing.

And this is what I see afterwards:

[Chris Kaminski]

Am I correct in thinking that this flash download tool is Windows only?

[Jacques De Jonghe]

You an achieve exctly the same with this web based tool: https://esptool.spacehuhn.com/

Jacques.

[Chris Kaminski]

Thank you Jacques

In the meantime I have managed to do it very simply using these instructions:

https://github.com/lyusupov/SoftRF/blob/master/software/firmware/binaries/README.md#esp32-s3

without any flash tools etc simply by dragging .uf2 file

I quote

"...Drag the downloaded .uf2 firmware file by your pointing device (mouse, trackball,...) , then drop it into TBEAMBOOT / TWRBOOT / HTBOOT disk. Wait until the file transfer is complete...."

[Moshe Braner]

Is your T-Beam a "Supreme"?  That has the ESP32-S3, and is not supported by my version, which is only for the plain ESP32 (T-Beam v0.7 - v1.2).

The plain old T-Beam does not open up a "BOOT disk" that you can drag a UF2 file to.  But, I have not tried Linar's v1.8, maybe it includes that feature?  Then again, Linar's instructions say: "The T-Beam Supreme board typically comes with factory pre-installed TinyUF2 bootloader."  Not the plain T-Beam.

[Moshe Braner]

PS: note that you need to select the ESP32 type in the flashing tool.  That's in the screen preceding the ones shown in the screenshots in this thread, IIRC.

[Chris Kaminski]

yes, sorry

I should have been more precise

Mine is indeed "Prime Edition MkIII"

[Phil Plane]

Yes, my T-Beams are the older versions. One is the early version with the physical on/off switch, the other two are newer with the soft on/off. I do set the flashing tool to ESP32.

[Moshe Braner]

Hmmm.  I am not familiar with that RTCWDT_RTC_RESET crash.  Looks from your screen capture that it happens early in the boot, before any output from SoftRF.  The RTC watchdog is supposed to turn itself off before passing control to the user program, I read.  If you haven't done the full flash erase (using the flashing tool) before re-flashing, try that.  If you did to that, try not doing that.  I know that sounds silly, but a quick online search came up with somebody getting that behavior only if flash erase was done.  Also the crashing did not happen again if power was disconnected and then reconnected, you can try that before giving up and re-flashing v1.8.  You can also try flashing my MB180 version, in case MB203 has a problem.

I have not tried using that flashing tool for MB203, perhaps I should.  But I flash it from the Arduino IDE each time, and that uses the ESP tool internally AFAIK.  And, MB203 then runs without crashing, as it did for bumpf in this thread after flashing with that tool.  And I heard from some people that successfully flashed it via OTA (when the pre-existing SoftRF version was MB17x.).  So I wonder what's different in your case.  Do you have peripherals attached to the T-Beam, e.g., baro sensor, SD card adapter, etc?  Try disconnecting those from one board as a test. 

[Bumpff Slam]

Phil.  

As I said earlier, I successfully flashed my old T-Beam Edition 2 with MB203 last week using tool V3.9.10.  In my screen shot, all 4 files and their target addresses are coloured green and the ticks are blue.   This is how it looked before I pressed Erase and then Start.   

I note in your screen shot, the files are not coloured.  If your screen shot was just before Start, then perhaps that's the issue.  My download failed until I realised this!  Unticking and ticking each file line should make them go green.

[Phil Plane]

Success!

Wish I knew why :(

Using the flash tool I tried reselecting all the files and reflashing. Nope.

Then I removed the BMP280 and retried. Nope.

Then I used ESPconnect to erase the whole flash. I reflashed the bootloader and partition and SoftRF1.8 one file at a time. Success. But I have done that with the flash tool.

Next I overwrite SoftRF1.8 with SoftRFmb177. This works.

And now I do an OTA update to 203. This works.

So I'm not sure what made it work. Maybe the bootloader? ESPconnect indicates 0x0 as the default start address for the bootloader, so I used that before I checked and saw that it is 0xe000.

So maybe I had the bootloader loaded at 0x0 and 0xe000 and this made it work?

Anyway, it is now working. Time to pull the other two out of their gliders and update them. I'll try to find out what works consistently.

--

Phil Plane

[Moshe Braner]

Another difference noticed in the two screenshots: bumpf selected "do not change bin", whatever that means.

Also noticed that both screenshots in this thread chose SPI speed 40 MHz, while Linar's instructions here:

     https://github.com/lyusupov/SoftRF/blob/master/software/firmware/binaries/README.md#esp32

have 80 MHz selected.

[Moshe Braner]

Also make sure to select the right COM port.  And a workable baud rate.  Linar's image shows 921600.  That has worked for me on the T-Beams I have tried.  It failed on some other board (SkyView?), so I switched to 115200 as shown in this thread, and that worked.  But when the baud rate was too high, I got an error message from the flashing tool, not a post-flash crash.

All these observations do not explain why Phil always had success with flashing v1.8 and the failures were only with vMB203?  And also why OTA flashing failed in the same way?  While Bumpf had success flashing MB203 on top of v1.6.  These hints seem to point out to something left in the flash by v1.8, so try full flash erase (via the tool) before flashing MB203.

[Phil Plane]

Just updated my two other t-beams.

First one I used esp-connect and just wrote the mb203 to 0x10000. Worked first time.

Second one I used flash download tool. I changed the SPI speed to 80MHz. Used the bootloader and partition files from 1.8, just changed the app0 to use mb203. Reselected all the files so they are all highlighted green. Worked first time.

I have no idea why this wasn't working, but now it does.

One interesting thing though. This is the partition map from esp-connect:

Notice the bootloader starts at 0x0 and the OTA data is at 0xE000. This doesn't match what the instructions for 1.8 say.

The 1.8 partition layout is:

boot_app0.bin (8KB) starting at 0xE000

bootloader_dio_80m.bin (17KB) starting at 0x1000

SoftRF.ino.partitions.bin (3KB) starting at 0x8000

SoftRF.ino.bin (1691KB) starting at 0x10000

So this doesn't make sense to me.

I'm still confused, but all my t-beams are working now.

--
You received this message because you are subscribed to the Google Groups "SoftRF_community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to softrf_communi...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/softrf_community/879817d6-54c1-4890-9efc-aa4356d7d781n%40googlegroups.com.

[Bumpff Slam]

Phil's reported he's solved his problem, but for completeness and responding to a couple of points Moshe raised about the ESP flashing tool:

I Erased and reflashed my T-Beam Edition2 again just now with MB203.  This screenshot is the final screen ESP Tool V3.9.10 screen and the command line.

From version v3.9.10, the settings are automatically derived from the firmware’s build metadata (they are all greyed out), except 'BAUD'.   

You have to type 'COM5' not just '5" (or the port you are using).  Expressif Systems recommend 115200 baud and it works fine.

FYI: AI says "DoNotChgBin tells the ESP Flash Download Tool not to modify your .bin file before flashing. It forces the tool to write the binary exactly as-is, with no header patching, no flash‑mode changes, no checksum fixes, no metadata injection".  It's not selectable in V3.9.10.

The 'combineBin' button throws up python errors on the Command line and does nothing.  You have to type 'COM5' not just '5" (or the port you are using).  Expressif Systems recommend 115200 baud and it works fine.

So with this version of the flash tool there's not a lot that you can do wrong except wrong addresses and not have all lines green with ticked/blue. 

And to Phil - since you have several T-Beam's, do try the SkyView WAGA version, it has numerous enhancements.  YouTube demo here:  https://youtu.be/_5mlzl7RmtM 

   

[Bumpff Slam]

I may have found the apparent issue. I tested this scenario:

• You start the flashing with the T-Beam switched on and running the last version of the firmware you were using.
• You then flash the new firmware.  When the flashing is Finished, the T-Beam is still running the last version of software, and you have to Reset to boot start the new firmware.
• You leave the PC connected by cable to the T-Beam after flashing and press Reset, the T-Beam screen goes black and appears not to boot. 
• You press Reset again or ON, still it appears not to have booted .  None of the buttons do anything.
• You conclude its 'bricked'.   

But I found, if (after the above sequence) you disconnect the cable to the PC and simply press On, it will start immediately.   Also if you discontent the cable immediately after flashing and Reset, it starts ok.

I then tried using RealTerm (a serial terminal program like Putty) connected by cable to the T-Beam to monitor the boot sequence and experienced a similar apparent boot freeze.  The RealTerm showed:   "E (907) system_api: Base MAC address from BLK3 of EFUSE version" and then a limited amount of unreadable characters (I think the firmware initiated a change of Baud rate from download 115200  to the  T-Beam USB's normal 38400).  AI told me: 

"If the boot log stops exactly at this system_api: Base MAC address string and RealTerm shows no further data, your T-Beam is likely experiencing a hardware brownout loop or a serial handshake lockup."

I'm not sure the program fully stopped booting as it started with the On button.  I suspect something to do with 'serial handshake lockup' but I didn't bother to investigate any further.  I think the solution is simply to disconnect the cable from the PC before rebooting to start new version of firmware.