Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OTA succeeds with a different flash mode, then kills the module #4876

Closed
5 tasks done
teejaydub opened this issue Jul 2, 2018 · 0 comments
Closed
5 tasks done

OTA succeeds with a different flash mode, then kills the module #4876

teejaydub opened this issue Jul 2, 2018 · 0 comments

Comments

@teejaydub
Copy link
Contributor

Basic Infos

  • This issue complies with the issue POLICY doc.
  • I have read the documentation at readthedocs and the issue is not addressed there.
  • I have tested that the issue is present in current master branch (aka latest git).
  • I have searched the issue tracker for a similar issue.
  • [n/a] If there is a stack dump, I have decoded it.
  • I have filled out all fields below.

Platform

  • Hardware: [ESP-12F]
  • Core Version: [1eb0645]
  • Development Env: [Arduino IDE]
  • Operating System: [Windows]

Settings in IDE

  • Module: [custom]
  • Flash Mode: [qio vs. dio]
  • Flash Size: [4MB]
  • Flash Frequency: [40Mhz]
  • CPU Frequency: [80Mhz]
  • Upload Using: [OTA vs. SERIAL]

Problem Description

The symptom is that OTA update works normally, using ESPhttpUpdate:

      [begin] roundedSize:       0x00061000 (397312)
      [begin] updateEndAddress:  0x00300000 (3145728)
      [begin] currentSketchSize: 0x00062000 (401408)
      [begin] _startAddress:     0x0029F000 (2748416)
      [begin] _currentAddress:   0x0029F000 (2748416)
      [begin] _size:             0x00060780 (395136)
      MD5 Success: f3a150dffd2ddd1136011efe3c483f4e
      Staged: address:0x0029F000, size:0x00060780
      Firmware update: OK.
      state: 5 -> 0 (0)
      rm 0
      pm close 7
      del if0
      uslc_ÇrSöf

and then after reboot I see:

       ets Jan  8 2013,rst cause:2, boot mode:(3,6)

      load 0x4010f000, len 1384, room 16 
      tail 8
      chksum 0xef
      csum 0xef
      csum err
      ets_main.c 

And the module stops.

The conditions under which this occur are:

  • Recently switched to a new batch of modules for a new manufacturing run
  • Had discovered that the new modules only support flash mode DIO, while the old ones supported QIO (the default).
  • Was now using --flash-mode dio on the esptool.py command line to program modules initially, with binaries built as before.
  • Binaries were then posted to a web server for OTA updates.

Cause

I tracked this down to the change in the flash mode. esptool.py was rewriting the flash mode in the .bin file as it programmed the module initially, so it was QIO in the .bin file, but DIO on the module.

Then, .bin files posted on the server for OTA were installed, and the bootloader's flash mode check failed on startup. This resulted in a dead module (from the customer's perspective; serial reprogramming still works fine).

Workaround

Modifying the build process to set the flash mode to DIO in the binary instead of while programming via esptool.py fixes the OTA problem. But, it's now not compatible with other modules that are already in the field, so a separate branch of .bin files must now be tracked on the OTA server - one for DIO and one for QIO.

Suggested solution

Either the flash mode (and maybe speed) should be verified before OTA succeeds, or it should be silently changed to match the mode that's already being used on the module, analogous to the way esptool.py does.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants