ESP8266: Probleme mit esptool

[Pete K. (pete77)]

Hallo,
ich habe ein Problem mit einem ESP01 Modul.

Das Modul hat 1MB Flash und ich kann auch die nodemcu Firmware 
aufspielen.
Die Firmware kommt von https://nodemcu-build.com/

$ esptool -cp /dev/ttyS0 -cf nodemcu-master-10-modules-2016-11-08-14-57-45-float.bin -bz 1M  -v
esptool v0.4.6 - (c) 2014 Ch. Klippel <[e-mail]>
opening port /dev/ttyS0 at 115200
opening bootloader
resetting board
trying to connect
trying to connect
Uploading 471555 bytes from nodemcu-master-10-modules-2016-11-08-14-57-45-float.bin to flash at 0x00000000
...........................................................................
...........................................................................
...........................................................................
...........................................................................
...........................................................................
...........................................................................
...........
setting flash size from 512K to 1M
starting app without reboot
closing bootloader

Allerdings fängt das Modul sofort nach Reset an, die serielle 
Schnittstelle zu fluten. Das ist nicht normal.

Könnte mit jemand mal prüfen, ob mein Aufruf von esptool korrekt ist?

Besten Dank!

[Joachim S. (oyo)]

> Könnte mit jemand mal prüfen, ob mein Aufruf von esptool korrekt ist?

Zu dem esptool-Aufruf kann ich leider nichts gross sagen - unter dem 
Begriff "esptool" kannte ich bisher immer nur dieses Tool:
https://github.com/espressif/esptool
...aber offensichtlich gibt es noch ein anderes "esptool", das Du 
verwendest, nämlich dieses hier:
https://github.com/igrr/esptool-ck

> Allerdings fängt das Modul sofort nach Reset an, die serielle
> Schnittstelle zu fluten. Das ist nicht normal.

Meiner persönlichen Erfahrung nach ist das Gegenteil der Fall: dieses 
Verhalten ist tatsächlich völlig normal bei der nodemcu-firmware, auch 
bei der von nodemcu-build.
Nach dem Reset wird da bei mir jedenfalls immer erst einmal mit 76(?) 
kBit eine Debug-Meldung gesendet, die u.A. Informationen über den 
Reset-Grund enthält.
Und sobald die nodemcu-firmware geladen ist, sendet diese von sich aus 
mit der regulären Baudrate (die mittlerweile glaube ich standardmässig 
bei 115200 liegt) zusätzlich eine kurze Statuszeile, die u.A. die 
nodemcu-firmware-Version benennt. Danach sendet sie noch das 
Shell-Prompt-Symbol ">" und wartet dann auf Eingaben für die LUA-Shell.

[Daniel (Gast)]

Wichtig ist, dass du auch die Init-Data überträgst.
Ich hatte am Anfang das gleiche Problem. Nach dem übertragen der 
Init-Daten klappte alles Problemlos.
Schau mal auf: https://nodemcu.readthedocs.io/en/dev/en/flash/ ganz 
unten bei "SDK_Init_Data".

Gruß,
Daniel

[Timmo H. (masterfx)]

Bei mir waren auch die init_data schuld. Ich hatte einen größeren SDK 
Versions sprung gemacht und die Init_data waren wohl inkompatibel.
Die liegen im bin Verzeichnis vom SDK (esp_init_data_default.bin)

[Pete K. (pete77)]

Leider hat ein erase_flash nicht zum Erfolg geführt.

Nutze jetzt das esptool.py von obiger Seite.

Interessant ist auch, dass ein verify_flash Fehler meldet, ich mache 
allerdings auch ein reset nach dem Flashen, vielleicht wird dadurch 
schon der Speicher geändert(?). GPIO0 bleibt dabei auf GND.

Erase_Flash hat dabei ca. 3,2s gedauert.

[Max M. (maxmicr)]

Benutzt hier jemand das espflash tool von espressif um seinen eigenen 
C-Code mit dem SDK 2.0 zu flashen? Falls ja: Welche Dateien flasht ihr 
und ab welcher Adresse? Funktioniert das bei euch?

[STMler (Gast)]

Max M. schrieb:
> Benutzt hier jemand das espflash tool von espressif um seinen
> eigenen
> C-Code mit dem SDK 2.0 zu flashen? Falls ja: Welche Dateien flasht ihr
> und ab welcher Adresse? Funktioniert das bei euch?


Lesen ist nicht so Deine Stärke?
Dann erstmal lernen...

Was Du suchst, steht in Kapitel 4:
http://www.espressif.com/sites/default/files/2a-esp8266-sdk_getting_started_guide_en_0.pdf

[Max M. (maxmicr)]

Danke für den Hinweis, ich hab das nun so gemacht wie das in diesem 
Dokument steht (siehe Anhang).

Beim Booten des ESP8266 gibt dieser aber nur das auf der Konsole aus:

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

load 0x40100000, len 27904, room 16 
tail 0
chksum 0x69
load 0x3ffe8000, len 884, room 8 
tail 12
chksum 0xa6
4
load 0x3ffe8380, len 344, room 12 
tail 12
chksum 0x71
csum 0x71

Es müsste eigentlich alle 0.5s ein "Hello" geprinted werden. Weiß jemand 
etwas mit dieser Ausgabe anzufangen?

[STMler (Gast)]

Oft sind das Stromversorgungsprobleme.
Welche Hardware benutzt Du denn?
Und zeig mal Dein Programm.

[Max M. (maxmicr)]

Mein Programm:

#include "user_interface.h"
#include <osapi.h>
#include <ets_sys.h>
#include <gpio.h>
#include <os_type.h>
#include "eagle_soc.h"
#include "ip_addr.h"
#include "espconn.h"
#include <stdio.h>
#include "user_config.h"

os_timer_t callTimer;

void printHello(){
  os_printf("Hello\n");
}

void user_init(void){
  os_timer_setfn(&callTimer,(os_timer_func_t*)printHello,NULL);
  os_timer_arm(&callTimer,500,1);
}

uint32 user_rf_cal_sector_set(void)
{
  enum flash_size_map size_map = system_get_flash_size_map();
  uint32 rf_cal_sec = 0;

  switch (size_map) {
  case FLASH_SIZE_4M_MAP_256_256:
  rf_cal_sec = 128 - 5;
  break;

  case FLASH_SIZE_8M_MAP_512_512:
  rf_cal_sec = 256 - 5;
  break;

  case FLASH_SIZE_16M_MAP_512_512:
  case FLASH_SIZE_16M_MAP_1024_1024:
  rf_cal_sec = 512 - 5;
  break;

  case FLASH_SIZE_32M_MAP_512_512:
  case FLASH_SIZE_32M_MAP_1024_1024:
  rf_cal_sec = 1024 - 5;
  break;

  default:
  rf_cal_sec = 0;
  break;
  }

  return rf_cal_sec;
}

STMler schrieb:
> Welche Hardware benutzt Du denn?

Ich hab meinen Schaltplan angehängt. Es handelt sich um ein ESP-12F 
Modul, 22uF wurden durch 100uF ersetzt. Zum Flashen und zur 
Stromversorgung benutze ich einen Standard USB/UART Konverter.

[Joachim S. (oyo)]

@maxmicr:
Die Debug-Ausgabe in Deinem vorletzten Posting sieht auf den ersten 
Blick für mich absolut normal aus.

Was Dein Programm betrifft:
Probiere doch mal testweise das Code-Sample im Abschnitt "Looping" auf 
dieser Seite aus:
https://blog.attachix.com/programming-for-esp8266-part-2/

Das soll im Grunde genau das machen, was Dein Programm auch machen soll.

[Max M. (maxmicr)]

Jetzt kommt diese Ausgabe:

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

load 0x40100000, len 27400, room 16 
tail 8
chksum 0x28
load 0x3ffe8000, len 884, room 0 
tail 4
chksum 0xee
load 0x3ffe8380, len 336, room 4 
tail 12
chksum 0xd3
csum 0xd3
E:M 36
E:M 16
E:M 16
E:M 16
E:M 16
E:M 16
E:M 16
E:M 32
E:M 1172
E:M 32
E:M 28
E:M 21
E:M 21
E:M 21
E:M 21
E:M 21
E:M 21
E:M 21
E:M 21
E:M 21
E:M 21
E:M 21
E:M 21
E:M 21
E:M 21
E:M 21
E:M

[Joachim S. (oyo)]

Nur um sicher zu gehen, dass ich Dich richtig verstehe: Diese Ausgabe 
kommt, wenn Du das verlinkte Programm aus dem "Looping"-Abschnitt 1:1 
benutzt?

Falls ja, zwei weitere Fragen:
1. Kommt die zitierte Ausgabe denn komplett auf einmal, oder kommt 
zumindest halbwegs wie erwartet ca. jede Sekunde etwas hinzu?
2. Du hast Dein Terminal-Programm schon auf 115200 Bau eingestellt, bzw. 
kannst ausschliessen, dass das Problem an einer falschen Baudrate liegt?

[Max M. (maxmicr)]

Joachim S. schrieb:
> Diese Ausgabe
> kommt, wenn Du das verlinkte Programm aus dem "Looping"-Abschnitt 1:1
> benutzt?

Ab SDK 2.0 benötigt man die Funktion "uint32 
user_rf_cal_sector_set(void)", aber ansonsten 1:1 kopiert.

Joachim S. schrieb:
> Kommt die zitierte Ausgabe denn komplett auf einmal, oder kommt
> zumindest halbwegs wie erwartet ca. jede Sekunde etwas hinzu?

Die Ausgabe kommt auf einmal. Danach passiert nichts mehr.

Joachim S. schrieb:
> 2. Du hast Dein Terminal-Programm schon auf 115200 Bau eingestellt, bzw.
> kannst ausschliessen, dass das Problem an einer falschen Baudrate liegt?

Nein, ich bin auf 74880. Bei 115200 Baud kommen nur komische Zeichen.

Mit welcher Toolchain arbeitest du und mit welchem SDK?

[Joachim S. (oyo)]

Max M. schrieb:

> Ab SDK 2.0 benötigt man die Funktion "uint32
> user_rf_cal_sector_set(void)", aber ansonsten *1:1 kopiert*.
> [...]
> Nein, ich bin auf 74880. Bei 115200 Baud kommen nur komische Zeichen.

Sofern Du das verlinkte Programm tatsächlich 1:1 kopiert, und nur um 
diese user_rf_cal_sector_set-Funktion erweitert hast, stellst Du aber 
doch 115200 als Baudrate ein; 74880 wären dann doch falsch und würde 
zwangsläufig falsche Zeichen erzeugen?

Max M. schrieb:
> Mit welcher Toolchain arbeitest du und mit welchem SDK?

Ich habe beim ESP8266 bisher ausschliesslich die NodeMCU-Firmware (also 
Programmierung in LUA) verwendet. Die sind m.W.n. immer noch bei SDK 
1.5.4.1.

[Max M. (maxmicr)]

Joachim S. schrieb:
> 74880 wären dann doch falsch und würde
> zwangsläufig falsche Zeichen erzeugen?

Ja, das wundert mich eben auch. Kann es sein, dass man sich das Modul 
zerschießt, wenn man mit fehlerhaften Adressen im espflash tool 
arbeitet?

[Joachim S. (oyo)]

Max M. schrieb:
> Ja, das wundert mich eben auch. Kann es sein, dass man sich das Modul
> zerschießt, wenn man mit fehlerhaften Adressen im espflash tool
> arbeitet?

Meinem bisherigen Verständnis nach würde ich behaupten, dass das 
eigentlich nicht sein kann; man so ein Modul eigentlich gar nicht 
bricken kann. Aber ich könnte mich natürlich auch irren.

Nur mal um sicher zu gehen, dass wir gerade nicht bloss aneinander 
vorbei reden: Ist Dir bewusst, dass die am Anfang angezeigte 
Debug-Nachricht (also die Ausgabe

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

load 0x40100000, len 27400, room 16 
tail 8
chksum 0x28
load 0x3ffe8000, len 884, room 0 
tail 4
chksum 0xee
load 0x3ffe8380, len 336, room 4 
tail 12
chksum 0xd3
csum 0xd3

) immer mit 74880 Baud gesendet wird - alles, was danach kommt, 
hingegen mit einer anderen Baudrate, die man im eigenen Programmcode 
einstellt? Es daher normal ist, dass man im Terminalprogramm entweder 
die obige Debug-Nachricht lesen kann, oder das, was der eigene 
Programmcode halt über die serielle Schnittstelle ausgibt?

[Max M. (maxmicr)]

Danke Joachim für deine Antwort,

Joachim S. schrieb:
> immer mit 74880 Baud gesendet wird - alles, was danach kommt,
> hingegen mit einer anderen Baudrate, die man im eigenen Programmcode
> einstellt? Es daher normal ist, dass man im Terminalprogramm entweder
> die obige Debug-Nachricht lesen kann, oder das, was der eigene
> Programmcode halt über die serielle Schnittstelle ausgibt?

Ja, das ist mir bewusst. Aber anscheinend kommt mein Programm gar nicht 
im Controller an zumindest nicht in der richtigen Stelle.