[feature] Add lightWaveform setting
tajnymag opened this issue · 32 comments
I'm having similar trouble as in SolderedElectronics/Inkplate-Arduino-library#112 in the original library. Greyscale in 3bit mode isn't linear and tends to be very dark until the last shades of grey.
The Arduino library, in its prior version, had a lightWaveform as a parameter for Inkplate::begin, which was supposed to fix similar issues. Inkplate 10 seems to be manufactured with two different sets of panels each with their own greyscale palette. The parameter is still present in documentation, yet removed from the method itself (https://github.com/e-radionicacom/Inkplate-Arduino-library/blob/93394781b203303727c72e9e3d872dcb74a8a091/src/boards/Inkplate10.cpp#L31)
Would it be possible to bring the parameter back in this version of the library?
Hello tajnymag, I was not aware of this old functionality. Not sure what needs to be done beyond adding a new parameter.
Did you try to adjust the waveform with the application located here?
I have just now. My Inkplate seems to be designed for waveform3 in the example sketch. During my testing with esp-idf, the pallete seemed like waveform1.
ESP-IDF-InkPlate seems to have the waveform/lut for Inkplate 10 hardcoded, correct?
My understanding is that you can burn in EEPROM the selected waveform using button 2 of the application. I don't think that ESP-IDF-Inkplate overwrites the one selected. I'm not able to test it myself at this moment. If you can make it a try, let me know.
Well, I've just checked the ESP-IDF code and it does not use the EEPROM waveform. I will look at modifying the code to be closer to the Arduino driver that was updated 5 months ago. It retrieves the waveform from the EEPROM if available, if not it uses a default version. I may not be able to check it before a month (I don't have access to my own hardware). Would you like to try it for me?
Well, I've just checked the ESP-IDF code and it does not use the EEPROM waveform. I will look at modifying the code to be closer to the Arduino driver that was updated 5 months ago. It retrieves the waveform from the EEPROM if available, if not it uses a default version. I may not be able to check it before a month (I don't have access to my own hardware). Would you like to try it for me?
I did notice that too. As a sane check, I've tried drawing the exact same gradient with esp-idf and can confirm the newly flashed EEPROM waveform is not being used.
Definitely, I'll compile and test any new commit in the repo. That applies for the whole foreseeable future.
Thank you for the support
I have created branch 0.9.8. Nothing was done. Hope to have something ready in 2-3 hours from now. I'll let you know.
Well, the modification is ongoing (the branch is v0.9.8, not v0.9.7). The changes required are larger than I was expecting. Still working on it. I also found a bug in the Arduino Inkplate10 driver and raised an issue there...
One important aspect is the following: The Arduino ESP32 EEPROM functions are in fact using a partition in flash named NVS to implement an EEPROM-like capability. For this reason, it is important that both the Arduino-based applications and the ESD-IDF-based applications use the same partition definition for the NVS, as the waveform data saved in EEPROM would be lost. All my ESP-IDF apps are currently using a partition at offset 0x9000 of length 0x4000. I don't think this is the case for the Arduino-Inkplate library and apps. If they use the Arduino IDE default partition scheme, the offset is 0x9000 and the length 0x5000.
I will change all the ESP-IDF-based apps to use the same NVS partition location as for the Arduino. The next release of the EPUB-Inlplate apps will also be updated, but I can't do it before a month.
I uploaded a first cut of the new code to the v0.9.8 branch. My portable computer needs a development platform refresh so I can at least compile it and debug the syntax. It will be for tomorrow morning (EDT(-4) Time... in around 12 hours...).
Great. I'll try to fully port over the arduino programming example to idf this afternoon (~15:00 GMT)
I was able to compile the first example using PlatformIO. It needed some code and partition adjustments. You will need a refresh of the branch as it was modified.
Please ensure that you are using the new partition.csv content as updated everywhere in this branch.
Have fun... ;-)
I'm trying out the new v0.9.8 branch. Can confirm the app is buildable and runnable. However, it's going to take me some time to figure out a way to properly write the waveform to NVS.
I have some questions:
- Could the waveform struct be made public, so the user can create and write a waveform to the NVS?
- Probably a thread for itself, but could the NVS initialization be done outside the driver? Native IDF components also don't handle NVS initialization.
- I'm not sure if the way Arduino is using the EEPROM partition is compatible with the way how IDF is using it. It seems IDF's NVS component is a high level abstraction over the non-volatile partition and creates key-value system on it. The example application, however, seems to be accessing the EEPROM partition just like a non-volatile buffer for the waveform struct, overriding everything in its path. Could we, please, keep the partition table intact, to stay in line with PlatformIO/IDF and just add
burnWaveformToEEPROMandchangeWaveformlike the Arduino driver has? EEPROM compatibility doesn't seem like a too high priority to me IMHO.
Some answer to your questions:
- I will modify the code to have the struct be public. The format is the same as for the arduino version. As I’m writing this text, I realize that the struct may require to be packed to be binary compatible with the Arduino version... I will also add a method to the Inkplate-10 that will permit to update the waveform struct in the EEPROM.
- I’ve added the NVSMgr class that supply the methods to initialize the nvs and read/write segments to the nvs. I will remove the call to the setup function such that the application will have to call it instead of the inkplate subsystem. The code will be adjusted such that if it is not properly initialized, the NVSMgr will behave gracefully.
- From what I’ve read in the Arduino implementation of the EEPROM class for the ESP32, it uses the NVS, creating a segment named ‘eeprom’. That is the way I’m using the NVS in the code. As stated in a preceding comment, it is important that the nvs partition be at the same location and size as for the arduino inkplate library, to be able to use the arduino and esp-idf based applications interchangeably without loosing the saved waveform. If an application uses a different nvs partition location, it will be erased and initialized as empty. This compatibility is important for me, as it wouldn’t cause any issues for my own usage and other users.
In your comment, you mention the ‘EEPROM partition’ in the Arduino context. That does not exists. It is implemented as a segment inside the NVS.
I will let you know when I complete the modifications.
Thank you
In your comment, you mention the ‘EEPROM partition’ in the Arduino context. That does not exists. It is implemented as a segment inside the NVS.
The main thing I didn't know was that Arduino is using nvs internally with an eeprom segment.
Yes, it does. In fact, I expect that if you use the Arduino application to modify the waveform in the EEPROM, it will be readable by an ESP-IDF application, if and only if both are using the NVS partition at the same location and of the same size. It would be the ultimate behavior that I would like to have.
Yes, it does. In fact, I expect that if you use the Arduino application to modify the waveform in the EEPROM, it will be readable by an ESP-IDF application, if and only if both are using the NVS partition at the same location and of the same size. It would be the ultimate behavior that I would like to have.
I've tried that. Didn't work. The idf app must have overwritten the nvs partition even though I had the correct partition table.
I'll play with it again tommorow.
OK. I will try to figure out the issue then... maybe the whole partitions definition must be the same...
I've tried to re-flash the app again and can confirm esp-idf version can't read the NVS data written by the arduino version.
I've tried both idf.py flash and idf.py app-flash both with the same result of:
E (1566) NVSMgr: Unable to read NVS data: ESP_ERR_NVS_INVALID_LENGTH.
I (1566) EInk10: Wavefrom load failed! Upload new waveform in EEPROM. Using default waveform.
To confirm my partition table is correct, I've read the partition table directly from the flashed esp32's flash memory:
# ESP-IDF Partition Table
# Name, Type, SubType, Offset, Size, Flags
nvs,data,nvs,0x9000,20K,
otadata,data,ota,0xe000,8K,
ota_0,app,ota_0,0x10000,1344K,
ota_1,app,ota_1,0x160000,1344K,
phy_init,data,phy,0x2b0000,4K,
# Arduino Partition Table
# Name, Type, SubType, Offset, Size, Flags
nvs,data,nvs,0x9000,20K,
otadata,data,ota,0xe000,8K,
app0,app,ota_0,0x10000,3M,
spiffs,data,spiffs,0x310000,960K,
Interesting. That means that the 'eeprom' key created by the Arduino code inside the nvs partition is still there but the content that I try to read is of the wrong size. It was not destroyed by the change of partitions table.
The way I read the waveform is not correct: my understanding is that the ESP-IDF nvs function doesn't permit me to read only the waveform data but the 'eeprom' segment as a whole. I'm modifying the code to do that...
I've just pushed an update. The NVSMgr class is now more verbose in its messages such that we can figure out the behavior. The code now reads the whole EEPROM segment and extracts the waveform struct from it. The code to write to the EEPROM segment does the same thing, using an EEPROM of 512 bytes in length (as per the Arduino code).
I still have to check the accessibility of the public methods to read/update the EEPROM, init the NVS or not from the user app, and the access to the waveform struct (and document them...).
I think it has worked now. All I've done was pulling the latest changes and rebuilding/flashing the app. In the new build NVSMgr was able to decode preloaded waveform struct from the EEPROM segment of NVS.
I (1753) NVSMgr: Reading data size 76 from segment eeprom of size -2146591530...
I (1763) EInk10: Waveform 22 loaded from EEPROM
I've also tried setting a different waveform in Arduino app and can confirm it got successfully detected and loaded back in the IDF app.
Thank you so much
Excellent! I have to check for that negative number for the eeprom size in the information message...
I will do another update in one or two hours with other modifications and some documentation.
I have completed the modifications. Please look at the README for a summary of the changes done. To check these modifications, I've ported the Arduino application and compiled it successfully (after some modifications...). You can find it here.
Please if you can try it, I will then close this issue if it works properly.
Reading seems fine, but while writing to the eeprom segment, the firmware panics and reboots.
Executing action: flash
Serial port /dev/ttyUSB0
Connecting.....
Detecting chip type... Unsupported detection protocol, switching and trying again...
Connecting......
Detecting chip type...[1/5] cd /home/marek/Projekty/vsb-eink-panel/build/esp-idf/esptool_py && /home/marek/.espressif/python_env/idf4.4_py3.10_env/bin/python /home/marek/esp/esp-idf/components/partition_table/check_sizes.py --offset 0x8000 partition --type app /home/marek/Projekty/vsb-eink-panel/build/partition_table/partition-table.bin /home/marek/Projekty/vsb-eink-panel/build/vsb-eink-panel.bin
vsb-eink-panel.bin binary size 0x92e70 bytes. Smallest app partition is 0x150000 bytes. 0xbd190 bytes (56%) free.
[2/5] Performing build step for 'bootloader'
[1/1] cd /home/marek/Projekty/vsb-eink-panel/build/bootloader/esp-idf/esptool_py && /home/marek/.espressif/python_env/idf4.4_py3.10_env/bin/python /home/marek/esp/esp-idf/components/partition_table/check_sizes.py --offset 0x8000 bootloader 0x1000 /home/marek/Projekty/vsb-eink-panel/build/bootloader/bootloader.bin
Bootloader binary size 0x62c0 bytes. 0xd40 bytes (12%) free.
[2/3] cd /home/marek/esp/esp-idf/components/esptool_py && /usr/bin/cmake -D IDF_PATH="/home/marek/esp/esp-idf" -D SERIAL_TOOL="/home/marek/.espressif/python_env/idf4.4_py3.10_env/bin/python /home/marek/esp/esp-idf/components/esptool_py/esptool/esptool.py --chip esp32" -D SERIAL_TOOL_ARGS="--before=default_reset --after=hard_reset write_flash @flash_args" -D WORKING_DIRECTORY="/home/marek/Projekty/vsb-eink-panel/build" -P /home/marek/esp/esp-idf/components/esptool_py/run_serial_tool.cmake
esptool.py esp32 -p /dev/ttyUSB0 -b 460800 --before=default_reset --after=hard_reset write_flash --flash_mode dio --flash_freq 40m --flash_size 4MB 0x1000 bootloader/bootloader.bin 0x10000 vsb-eink-panel.bin 0x8000 partition_table/partition-table.bin 0xe000 ota_data_initial.bin
esptool.py v3.3-dev
Serial port /dev/ttyUSB0
Connecting......
Chip is ESP32-D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 9c:9c:1f:f3:25:08
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 460800
Changed.
Configuring flash size...
Flash will be erased from 0x00001000 to 0x00007fff...
Flash will be erased from 0x00010000 to 0x000a2fff...
Flash will be erased from 0x00008000 to 0x00008fff...
Flash will be erased from 0x0000e000 to 0x0000ffff...
Compressed 25280 bytes to 15806...
Writing at 0x00001000... (100 %)
Wrote 25280 bytes (15806 compressed) at 0x00001000 in 0.8 seconds (effective 245.3 kbit/s)...
Hash of data verified.
Compressed 601712 bytes to 306873...
Writing at 0x00010000... (5 %)
Writing at 0x0001c193... (10 %)
Writing at 0x0002b1a8... (15 %)
Writing at 0x00038e6a... (21 %)
Writing at 0x0003e55e... (26 %)
Writing at 0x00044021... (31 %)
Writing at 0x00049262... (36 %)
Writing at 0x0004e666... (42 %)
Writing at 0x00053e31... (47 %)
Writing at 0x00059301... (52 %)
Writing at 0x0005f96a... (57 %)
Writing at 0x00067b85... (63 %)
Writing at 0x00070216... (68 %)
Writing at 0x0007967c... (73 %)
Writing at 0x0007fd7d... (78 %)
Writing at 0x00088506... (84 %)
Writing at 0x000913b5... (89 %)
Writing at 0x0009952d... (94 %)
Writing at 0x0009ea67... (100 %)
Wrote 601712 bytes (306873 compressed) at 0x00010000 in 8.0 seconds (effective 599.7 kbit/s)...
Hash of data verified.
Compressed 3072 bytes to 129...
Writing at 0x00008000... (100 %)
Wrote 3072 bytes (129 compressed) at 0x00008000 in 0.1 seconds (effective 388.3 kbit/s)...
Hash of data verified.
Compressed 8192 bytes to 31...
Writing at 0x0000e000... (100 %)
Wrote 8192 bytes (31 compressed) at 0x0000e000 in 0.1 seconds (effective 606.3 kbit/s)...
Hash of data verified.
Leaving...
Hard resetting via RTS pin...
ESP32
Running ninja in directory /home/marek/Projekty/vsb-eink-panel/build
Executing "ninja flash"...
Executing action: monitor
Serial port /dev/ttyUSB0
Connecting.......
Detecting chip type... Unsupported detection protocol, switching and trying again...
Connecting.....
Detecting chip type...--- idf_monitor on /dev/ttyUSB0 115200 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
ets Jun 8 2016 00:22:57
rst:0x1 (POWERON_RESET),boot:0x12 (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:2
load:0x3fff0030,len:6608
load:0x40078000,len:14788
ho 0 tail 12 room 4
load:0x40080400,len:3792
0x40080400: _init at ??:?
entry 0x40080694
I (28) boot: ESP-IDF v4.4.1 2nd stage bootloader
I (29) boot: compile time 17:43:14
I (29) boot: chip revision: 1
I (31) boot_comm: chip revision: 1, min. bootloader chip revision: 0
I (38) boot.esp32: SPI Speed : 40MHz
I (43) boot.esp32: SPI Mode : DIO
I (48) boot.esp32: SPI Flash Size : 4MB
I (52) boot: Enabling RNG early entropy source...
I (58) boot: Partition Table:
I (61) boot: ## Label Usage Type ST Offset Length
I (68) boot: 0 nvs WiFi data 01 02 00009000 00005000
I (76) boot: 1 otadata OTA data 01 00 0000e000 00002000
I (83) boot: 2 ota_0 OTA app 00 10 00010000 00150000
I (91) boot: 3 ota_1 OTA app 00 11 00160000 00150000
I (98) boot: 4 phy_init RF data 01 01 002b0000 00001000
I (106) boot: End of partition table
I (110) boot: No factory image, trying OTA 0
I (115) boot_comm: chip revision: 1, min. application chip revision: 0
I (122) esp_image: segment 0: paddr=00010020 vaddr=3f400020 size=23aa0h (146080) map
I (184) esp_image: segment 1: paddr=00033ac8 vaddr=3ffb0000 size=02a20h ( 10784) load
I (188) esp_image: segment 2: paddr=000364f0 vaddr=40080000 size=09b28h ( 39720) load
I (206) esp_image: segment 3: paddr=00040020 vaddr=400d0020 size=58b6ch (363372) map
I (338) esp_image: segment 4: paddr=00098b94 vaddr=40089b28 size=0a298h ( 41624) load
I (355) esp_image: segment 5: paddr=000a2e34 vaddr=50000000 size=00010h ( 16) load
I (365) boot: Loaded app from partition at offset 0x10000
I (400) boot: Set actual ota_seq=1 in otadata[0]
I (400) boot: Disabling RNG early entropy source...
I (411) psram: This chip is ESP32-D0WD
I (412) spiram: Found 64MBit SPI RAM device
I (412) spiram: SPI RAM mode: flash 40m sram 40m
I (417) spiram: PSRAM initialized, cache is in low/high (2-core) mode.
I (424) cpu_start: Pro cpu up.
I (428) cpu_start: Starting app cpu, entry point is 0x40081708
0x40081708: call_start_cpu1 at /home/marek/esp/esp-idf/components/esp_system/port/cpu_start.c:160
I (0) cpu_start: App cpu up.
I (1297) spiram: SPI SRAM memory test OK
I (1305) cpu_start: Pro cpu start user code
I (1305) cpu_start: cpu freq: 240000000
I (1305) cpu_start: Application information:
I (1308) cpu_start: Project name: vsb-eink-panel
I (1314) cpu_start: App version: 1
I (1319) cpu_start: Compile time: Aug 19 2022 17:43:10
I (1325) cpu_start: ELF file SHA256: 058404efb945f683...
I (1331) cpu_start: ESP-IDF: v4.4.1
I (1336) heap_init: Initializing. RAM available for dynamic allocation:
I (1343) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM
I (1349) heap_init: At 3FFB6090 len 00029F70 (167 KiB): DRAM
I (1356) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM
I (1362) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (1369) heap_init: At 40093DC0 len 0000C240 (48 KiB): IRAM
I (1375) spiram: Adding pool of 4095K of external SPI memory to heap allocator
I (1384) spi_flash: detected chip: gd
I (1387) spi_flash: flash io: dio
I (1475) cpu_start: Starting scheduler on PRO CPU.
I (0) cpu_start: Starting scheduler on APP CPU.
I (1477) spiram: Reserving pool of 32K of internal memory for DMA/internal allocations
I (2307) MCP23017: MCP at address 0x20 has been detected
I (2347) MCP23017: MCP at address 0x22 has been detected
I (2377) NVSMgr: Reading data size 76 from segment eeprom...
I (2487) EInk10: Waveform 20 loaded from EEPROM
I (32157) NVSMgr: Writing segment eeprom of size 512 with data size 76...
Guru Meditation Error: Core 0 panic'ed (IllegalInstruction). Exception was unhandled.
Memory dump at 0x400d72f0: 25e503a1 f01d0215 91008136
0x400d72f0: mainTask(void*) at /home/marek/Projekty/vsb-eink-panel/main/main.cpp:93
Core 0 register dump:
PC : 0x400d72f6 PS : 0x00060830 A0 : 0x00000000 A1 : 0x3ffc66a0
0x400d72f6: mainTask(void*) at /home/marek/Projekty/vsb-eink-panel/main/main.cpp:94
A2 : 0x3ffb39a8 A3 : 0x3ffb3198 A4 : 0x0064000a A5 : 0x3ffb38e8
A6 : 0x00000001 A7 : 0x00000001 A8 : 0x800d72f6 A9 : 0x3ffc6680
A10 : 0x3ffb38e8 A11 : 0x3f404534 A12 : 0x3ffb39a8 A13 : 0x3f404534
A14 : 0x00000002 A15 : 0x00000000 SAR : 0x0000001b EXCCAUSE: 0x00000000
EXCVADDR: 0x00000000 LBEG : 0x40088cec LEND : 0x40088d08 LCOUNT : 0xffffffff
0x40088cec: memcpy at /builds/idf/crosstool-NG/.build/xtensa-esp32-elf/src/newlib/newlib/libc/machine/xtensa/memcpy.S:175
0x40088d08: memcpy at /builds/idf/crosstool-NG/.build/xtensa-esp32-elf/src/newlib/newlib/libc/machine/xtensa/memcpy.S:197
Backtrace:0x400d72f3:0x3ffc66a0
0x400d72f3: mainTask(void*) at /home/marek/Projekty/vsb-eink-panel/main/main.cpp:93
ELF file SHA256: 058404efb945f683
Rebooting...
ets Jun 8 2016 00:22:57
rst:0xc (SW_CPU_RESET),boot:0x12 (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:2
load:0x3fff0030,len:6608
load:0x40078000,len:14788
ho 0 tail 12 room 4
load:0x40080400,len:3792
0x40080400: _init at ??:?
entry 0x40080694
I (29) boot: ESP-IDF v4.4.1 2nd stage bootloader
I (29) boot: compile time 17:43:14
I (29) boot: chip revision: 1
I (32) boot_comm: chip revision: 1, min. bootloader chip revision: 0
I (39) boot.esp32: SPI Speed : 40MHz
I (43) boot.esp32: SPI Mode : DIO
I (48) boot.esp32: SPI Flash Size : 4MB
I (52) boot: Enabling RNG early entropy source...
I (58) boot: Partition Table:
I (61) boot: ## Label Usage Type ST Offset Length
I (69) boot: 0 nvs WiFi data 01 02 00009000 00005000
I (76) boot: 1 otadata OTA data 01 00 0000e000 00002000
I (84) boot: 2 ota_0 OTA app 00 10 00010000 00150000
I (91) boot: 3 ota_1 OTA app 00 11 00160000 00150000
I (99) boot: 4 phy_init RF data 01 01 002b0000 00001000
I (106) boot: End of partition table
I (110) boot_comm: chip revision: 1, min. application chip revision: 0
I (118) esp_image: segment 0: paddr=00010020 vaddr=3f400020 size=23aa0h (146080) map
I (179) esp_image: segment 1: paddr=00033ac8 vaddr=3ffb0000 size=02a20h ( 10784) load
I (183) esp_image: segment 2: paddr=000364f0 vaddr=40080000 size=09b28h ( 39720) load
I (201) esp_image: segment 3: paddr=00040020 vaddr=400d0020 size=58b6ch (363372) map
I (333) esp_image: segment 4: paddr=00098b94 vaddr=40089b28 size=0a298h ( 41624) load
I (350) esp_image: segment 5: paddr=000a2e34 vaddr=50000000 size=00010h ( 16) load
I (360) boot: Loaded app from partition at offset 0x10000
I (360) boot: Disabling RNG early entropy source...
I (373) psram: This chip is ESP32-D0WD
I (373) spiram: Found 64MBit SPI RAM device
I (373) spiram: SPI RAM mode: flash 40m sram 40m
I (378) spiram: PSRAM initialized, cache is in low/high (2-core) mode.
I (385) cpu_start: Pro cpu up.
I (389) cpu_start: Starting app cpu, entry point is 0x40081708
0x40081708: call_start_cpu1 at /home/marek/esp/esp-idf/components/esp_system/port/cpu_start.c:160
I (382) cpu_start: App cpu up.
I (1259) spiram: SPI SRAM memory test OK
I (1267) cpu_start: Pro cpu start user code
I (1267) cpu_start: cpu freq: 240000000
I (1267) cpu_start: Application information:
I (1270) cpu_start: Project name: vsb-eink-panel
I (1276) cpu_start: App version: 1
I (1280) cpu_start: Compile time: Aug 19 2022 17:43:10
I (1286) cpu_start: ELF file SHA256: 058404efb945f683...
I (1292) cpu_start: ESP-IDF: v4.4.1
I (1298) heap_init: Initializing. RAM available for dynamic allocation:
I (1305) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM
I (1311) heap_init: At 3FFB6090 len 00029F70 (167 KiB): DRAM
I (1317) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM
I (1323) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (1330) heap_init: At 40093DC0 len 0000C240 (48 KiB): IRAM
I (1336) spiram: Adding pool of 4095K of external SPI memory to heap allocator
I (1345) spi_flash: detected chip: gd
I (1349) spi_flash: flash io: dio
I (1436) cpu_start: Starting scheduler on PRO CPU.
I (0) cpu_start: Starting scheduler on APP CPU.
I (1438) spiram: Reserving pool of 32K of internal memory for DMA/internal allocations
I (2268) MCP23017: MCP at address 0x20 has been detected
I (2308) MCP23017: MCP at address 0x22 has been detected
I (2338) NVSMgr: Reading data size 76 from segment eeprom...
I (2448) EInk10: Waveform 20 loaded from EEPROM
Thanks. I will try to find out…
I found that I omitted a call to the nvs_commit() function. Maybe it’s the stack that is not big enough. I’ve doubled the stack size and added the call to nvs_commit…
If the problem is still there, can you try to comment the burnWaveformToEEPROM() method call in the main program. The cause may be related to another place in the library.
Another potential issue is the main task function that exit. Being the only task, it may not be a good idea to exit from it, so I've added a forever loop around the code, with a 5-second delay at the end of each loop.
I've just tried the latest changes, and it works!
- no errors during writing
- written waveform is used as the primary waveform after reboot
- waveform flashed by the Arduino example gets loaded by our IDF version
Thank you <3
Thanks for your help too. I will merge the branch to master only when I will be able to update the EPub-Inkplate application in about a month. I may add other changes to the branch as I will check for other changes made in the Arduino library.