SIGNALESP: Firm- und Hardware für SIGNALduino direkt auf ESP8266 oder ESP32

Begonnen von Ralf9, 24 Januar 2018, 20:04:44

Vorheriges Thema - Nächstes Thema

Ralf9

Habe mir das "ESP32 DEVKIT V1" gekauft, irgendwas passt noch nicht.

Ich hab mit der Arduino IDE das blink LED Beispiel hochgeladen.
Wenn ich die Reset Taste drücke, bekomme ich im seriellen Monitor die folgende Ausgabe:
ets Jun  8 2016 00:22:57
rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
ets_main.c 371
ets Jun  8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0018,len:4
load:0x3fff001c,len:1044
load:0x40078000,len:10124
load:0x40080400,len:5856
entry 0x400806a8

Das blink LED und ein WLAN Beispiel funktionieren aber trotzdem.

In der Arduino IDE verwende ich unter Einstellungen:
https://dl.espressif.com/dl/package_esp32_index.json
Als Bord habe ich "DOIT ESP32 DEVKIT V1" ausgewählt.

Beim hochladen wird folgendes verwendet:

python /home/ralf/.arduino15/packages/esp32/tools/esptool_py/3.0.0/esptool.py --chip esp32 --port /dev/ttyUSB0 --baud 921600 --before default_reset --after hard_reset write_flash -z --flash_mode dio --flash_freq 80m --flash_size detect 0xe000 /home/ralf/.arduino15/packages/esp32/hardware/esp32/1.0.6/tools/partitions/boot_app0.bin 0x1000 /home/ralf/.arduino15/packages/esp32/hardware/esp32/1.0.6/tools/sdk/bin/bootloader_dio_80m.bin 0x10000 /tmp/arduino_build_214198/ESP32test.ino.bin 0x8000 /tmp/arduino_build_214198/ESP32test.ino.partitions.bin

Weiß jemand was hier nicht passt?

Gruß Ralf

FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

juergs

Zitatpython /home/ralf/.arduino15/packages/esp32/tools/esptool_py/3.0.0/esptool.py
--chip esp32
--port /dev/ttyUSB0
--baud 921600
--before default_reset
--after hard_reset write_flash -z
--flash_mode dio
--flash_freq 80m
--flash_size detect 0xe000
   /home/ralf/.arduino15/packages/esp32/hardware/esp32/1.0.6/tools/partitions/boot_app0.bin 0x1000
   /home/ralf/.arduino15/packages/esp32/hardware/esp32/1.0.6/tools/sdk/bin/bootloader_dio_80m.bin 0x10000
   /tmp/arduino_build_214198/ESP32test.ino.bin 0x8000 /tmp/arduino_build_214198/ESP32test.ino.partitions.bin

ZitatC:\Users\js\AppData\Local\Arduino15\packages\esp32\tools\esptool_py\2.6.1/esptool.exe
--chip esp32
--port COM7
--baud 921600
--before default_reset
--after hard_reset write_flash -z
--flash_mode dio --flash_freq 80m
--flash_size detect 0xe000
C:\Users\js\AppData\Local\Arduino15\packages\esp32\hardware\esp32\1.0.2/tools/partitions/boot_app0.bin 0x1000
C:\Users\js\AppData\Local\Arduino15\packages\esp32\hardware\esp32\1.0.2/tools/sdk/bin/bootloader_dio_80m.bin 0x10000
C:\Users\js\AppData\Local\Temp\arduino_build_390561/BlinkWithoutDelay.ino.bin 0x8000
C:\Users\js\AppData\Local\Temp\arduino_build_390561/BlinkWithoutDelay.ino.partitions.bin

Auf den ersten Blick kann ich da noch kein Unterschied erkennen (W10).


Software bootloader load segments
load:0x3fff0008,len:8
load:0x3fff0010,len:3680
load:0x40078000,len:8364
load:0x40080000,len:252
entry 0x40080034
These entries are printed as the ROM bootloader loads each segment in the software bootloader image. The load address and length of each segment is printed.
You can compare these values to the software bootloader image by running esptool.py --chip esp32 image_info /path/to/bootloader.bin to dump image info including a summary of each segment. Corresponding details will also be found in the bootloader ELF file headers.
If there is a problem with the SPI flash chip addressing mode, the values printed by the bootloader here may be corrupted.
The final line shows the entry point address of the software bootloader, where the ROM bootloader will call as it hands over control.

ZitatC:\Users\js>C:\Users\js\AppData\Local\Arduino15\packages\esp32\tools\esptool_py\2.6.1\esptool.exe --chip esp32 image_info C:\Users\js\AppData\Local\Arduino15\packages\esp32\hardware\esp32\1.0.2/tools/sdk/bin/bootloader_dio_80m.bin
esptool.py v2.6
Image version: 1
Entry point: 4008069c
4 segments
Segment 1: len 0x00004 load 0x3fff0018 file_offs 0x00000018
Segment 2: len 0x003a0 load 0x3fff001c file_offs 0x00000024
Segment 3: len 0x020e8 load 0x40078000 file_offs 0x000003cc
Segment 4: len 0x016ec load 0x40080400 file_offs 0x000024bc
Checksum: 6d (valid)
Validation Hash: ea0138d3080577277964d7889f3ca2dc681a80261f9b922b894059086ae2ae28 (valid)

https://dl.espressif.com/dl/schematics/ESP32-Core-Board-V2_sch.pdf
https://dl.espressif.com/dl/schematics/ESP32-DevKitJ-v1_sch.pdf

C:\Users\js>

Ralf9

python /home/ralf/.arduino15/packages/esp32/tools/esptool_py/3.0.0/esptool.py --chip esp32 image_info /home/ralf/.arduino15/packages/esp32/hardware/esp32/1.0.6/tools/sdk/bin/bootloader_dio_80m.bin
esptool.py v3.0-dev
Image version: 1
Entry point: 400806a8
4 segments

Segment 1: len 0x00004 load 0x3fff0018 file_offs 0x00000018 [BYTE_ACCESSIBLE, DRAM, DIRAM_DRAM]
Segment 2: len 0x00414 load 0x3fff001c file_offs 0x00000024 [BYTE_ACCESSIBLE, DRAM, DIRAM_DRAM]
Segment 3: len 0x0278c load 0x40078000 file_offs 0x00000440 [CACHE_APP]
Segment 4: len 0x016e0 load 0x40080400 file_offs 0x00002bd4 [IRAM]
Checksum: 86 (valid)
Validation Hash: 020aa93dc874b37708828b91db8e724fb046b80420319ac49a35cfa2d17360d6 (valid)


Dies stimmt mit der Ausgabe vom seriellen Monitor überein
load:0x3fff0018,len:4
load:0x3fff001c,len:1044
load:0x40078000,len:10124
load:0x40080400,len:5856
entry 0x400806a8
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

juergs

https://github.com/letscontrolit/ESPEasy/issues/2202
You need to flash the bootloader. So under Windows10/cmd:

    I do erase: flasherase.cmd:
    esptool.exe --chip esp32 --port COM11 --baud 256000 --before default_reset --after hard_reset erase_flash

    I do use flash the boot loader: flashbootloader.cmd:
    esptool.exe --chip esp32 --port COM11 --baud 256000 --before default_reset --after hard_reset write_flash -z --flash_mode dio --flash_freq 80m --flash_size detect 0x8000 partitions2.bin 0xe000 boot_app0.bin 0x1000 bootloader.bin

    and flashfirmware.cmd:
    esptool.exe --chip esp32 --port COM11 --baud 256000 --before default_reset --after hard_reset write_flash -z --flash_mode dio --flash_freq 80m --flash_size detect 0x10000 firmware.bin

After the first 2 commands i could upload my sketches to the ESP32 via the Arduino IDE without any Problems and the error did not occur again for 3 days now. Before, that bs came every 15 minutes or so.

Sollte auch über esptool.py gehen.

ZitatYou can find those files in your esp32 firmware. Just download an AT Firmware for your esp32 from the official espressif website. When i made that i downloaded the version "ESP32-WROOM-32 AT Bin V1.1.2" but i gues you can choose any version as long as it is for the esp32-wroom. I do not know if i am allowed to post a link but here it is. Just download it, unpack and search for the needed files.
https://www.espressif.com/en/support/download/at?keys=&field_type_tid%5B%5D=13

Oder:
https://docs.openmqttgateway.com/upload/binaries.html#esp32

juergs

Diese Variante wäre auch interessant:
https://www.mikrocontroller.net/topic/503483

https://nodemcu-build.com/
Zitat
Select branch to build from

release
dev 1.5.4.1-final (frozen, for 512KB flash) dev-esp32 BETA

Ralf9

Diese Ausgabe auf dem seriellen Monitor hat anscheinend keine Auswirkung auf die Funktion.
ets Jun  8 2016 00:22:57
rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
ets_main.c 371
ets Jun  8 2016 00:22:57
rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)


Ich habe angefangen die MapleSduino Firmware auf den ESP32 anzupassen.
Ich habe erstmal nur einen RXB6 Empfänger angeschlossen, den Wifimanager habe ich noch nicht eingebaut.
version: V 4.2.0-dev210514 SIGNALduinoAdv ESP32 (R: B0*) - compiled at May 15 2021 16:04:24

Es werden auch sehr lange MU-Nachrichten sauber empfangen
MU;P0=-27625;P1=456;P2=-1063;P3=1415;CP=1;D=012121212121212123212121212121212121212123232123232123212321232123232323232123232123232323212323212321232323212321232121212123210121212121212121232121212121212121212121232321232321232123212321232323232321232321232323232123232123212323232123212321212121232101212121212121212321212121212121212121212323212323212321232123212323232323212323212323232321232321232123232321232123212121212321;e;

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Ralf9

Zitat von: Ralf9 am 24 Mai 2021, 23:34:36
Ich bin gerade dabei meine MapleSduino Firmware 4.x für den ESP32 anzupassen
V 4.2.0-dev210524 SIGNALduinoAdv ESP32 cc1101 (R: A1 B0*) - compiled at May 24 2021 18:22:51
Ich habs schon mit zwei cc1101 Modulen getestet, ich habe aber noch das Problem, daß der ESP32 ab und zu rebootet, wenn beim Schreiben ins EEPROM der slowRf Empfang aktiv ist
Guru Meditation Error: Core  1 panic'ed (Cache disabled but cached memory region accessed)
....
Core 1 was running in ISR context:
....
Rebooting...


Mich würde interessieren wie stabil die SIGNALESP32 Firmware von Sidey läuft, kommt es da auch ab und zu vor, daß der ESP32 beim schreiben ins EEPROM rebootet?

Gruß Ralf

Zitat von: juergs am 25 Mai 2021, 10:26:14
Wie kann ich SlowRF zum Testen erzeugen?

SlowRF ist 433MHz ASK/OOK, jede Pulsflanke erzeugt einen Interrupt.
Da der ESP32 kein EEPROM hat wird dies im Flash simuliert.
Wenn mit EEPROM.commit() die EEPROM Daten ins Flash geschrieben werden, werden die Lesezugriffe auf das Flash gesperrt.
Wenn während dem Schreiben ins Flash, in einer Interruptroutine code ausgeführt wird, der nicht im IRAM steht, dann kommt es zu diesem error der einen reboot auslöst.

Gruß Ralf
 
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Ralf9

ZitatWenn während dem Schreiben ins Flash, in einer Interruptroutine code ausgeführt wird, der nicht im IRAM steht, dann kommt es zu diesem error der einen reboot auslöst.
Ich konnte inzwischen die SimpleFIFO.h library als Ursache eingrenzen.
Da ich die selbe SimpleFIFO.h wie auch beim SIGNALESP verwende, müssten eigentlich diese Reboots auch beim SIGNALESP vorkommen, evtl seltener.

Damit wird die FiFo.enqueue Routine im IRAM ausgeführt
bool IRAM_ATTR SimpleFIFO<T,rawSize>::enqueue( T element ) {
vermutlich gibts noch codeteile die im flash sind.


Ich hab zum Testen die SimpleFIFO.h durch diese Routinen ersetzt, damit habe ich dann keine Reboots mehr:
bool IRAM_ATTR FifoB_enqueue(int16_t element) {
if ( numberOfElementsB >=  FIFO_LENGTH) { return false; }
numberOfElementsB++;
nextInB %= FIFO_LENGTH;
rawFifoB[nextInB] = element;
nextInB++;
return true;
}

int16_t FifoB_dequeue() {
numberOfElementsB--;
nextOutB %= FIFO_LENGTH;
return rawFifoB[nextOutB++];
}

void FifoB_flush() {
nextInB = nextOutB = numberOfElementsB = 0;
}


Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

romakrau

Hallo Ralf,
ich kann deine Änderung nicht nachvollziehen. Könntest Du vielleicht deine Version der SimpleFIFO.h hier einstellen.
Ich würde sie gerne einmal ausprobieren.
Gruß und Danke
Roman

juergs


romakrau

Leider nicht. Ich warte dann mal auf die fertige ESP32 Adaption von Ralf.
Gruß
Roman

romakrau

Es scheint wohl ein Unterschied im Handling der Nutzung des RAM's zu geben.
Im Arduino Forum habe ich dazu folgendes gefunden:

https://www.arduinoforum.de/arduino-Thread-Interrupt-Routinren-bei-ESP

Im Code wird dieses an drei Stellen verwendet:

\SIGNALDuino_master_2021-05-24\src\functions.h und signalesp.h

\SIGNALDuino_master_2021-05-24\src\_micro-api\libraries\SimpleFIFO\src\SimpleFIFO.h

Werde ich bei Gelegenheit mal testen.
Gruß
Roman

Ralf9

Zitatvoid IRAM_ATTR intRoutine()
dies ist zuwenig, in den Routinen die im Interrupt ausgeführt werden dürfen auch keine "const" im flash sein.

Mein Problem ist, daß ich nicht den kompletten Code der SimpleFIFO.h verstehe.

Im Hauptsketch steht:
#define FIFO_LENGTH            170
SimpleFIFO<int16_t,FIFO_LENGTH> FiFoB;


Mir ist nicht klar wie in der SimpleFIFO.h die übergebende FIFO_LENGTH in size und rawSize übergeben wird?
Ist size evtl im flash da es eine "const" ist?

const SIMPLEFIFO_SIZE_TYPE size;
...
template<typename T, int16_t rawSize>
SimpleFIFO<T,rawSize>::SimpleFIFO() : size(rawSize) {
flush();
}


FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

juergs

Hallo Ralf,

setze doch Deinen aktuellen Code in Github als pre-release (Beta).

Dann kann man Dich gerne unterstützen.

Grüße,
Jürgen