[feature] Add lightWaveform setting

tajnymag commented 2 years ago

I'm having similar trouble as in https://github.com/e-radionicacom/Inkplate-Arduino-library/issues/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?

turgu1 commented 2 years ago

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?

tajnymag commented 2 years ago

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?

PXL_20220818_155822012 MP PXL_20220818_155828854 MP PXL_20220818_155835051 MP

turgu1 commented 2 years ago

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.

turgu1 commented 2 years ago

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?

tajnymag commented 2 years ago

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

turgu1 commented 2 years ago

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.

turgu1 commented 2 years ago

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.

turgu1 commented 2 years ago

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...).

tajnymag commented 2 years ago

Great. I'll try to fully port over the arduino programming example to idf this afternoon (~15:00 GMT)

turgu1 commented 2 years ago

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... ;-)

tajnymag commented 2 years ago

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 burnWaveformToEEPROM and changeWaveform like the Arduino driver has? EEPROM compatibility doesn't seem like a too high priority to me IMHO.

turgu1 commented 2 years ago

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.

turgu1 commented 2 years ago

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.

turgu1 commented 2 years ago

I will let you know when I complete the modifications.

tajnymag commented 2 years ago

Thank you

tajnymag commented 2 years ago

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.

turgu1 commented 2 years ago

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.

tajnymag commented 2 years ago

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.

turgu1 commented 2 years ago

OK. I will try to figure out the issue then... maybe the whole partitions definition must be the same...

tajnymag commented 2 years ago

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,

turgu1 commented 2 years ago

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...

turgu1 commented 2 years ago

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...).

tajnymag commented 2 years ago

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

turgu1 commented 2 years ago

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.

turgu1 commented 2 years ago

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.

tajnymag commented 2 years ago

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

turgu1 commented 2 years ago

Thanks. I will try to find out…

turgu1 commented 2 years ago

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…

turgu1 commented 2 years ago

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.

turgu1 commented 2 years ago

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.

tajnymag commented 2 years ago

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

turgu1 commented 2 years ago

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.

turgu1 / ESP-IDF-InkPlate

[feature] Add lightWaveform setting #12