Decimal dot on 7 Segment and 7 segment no working except 260_SDK3_ALPHA

nemocaledonie commented 5 years ago

Checklist

[X] The title of this issue is "to the point" and descriptive.
[X] This issue describes what is happening.
[X] This issue describes what components are affected (e.g. name of plugin/controller)
[X] This issue describes how to reproduce it.
[X] This issue describes when it was introduced (when known) and what version is now showing the problem.

I have...

[X] searched the issue tracker or the forum for a similar issue. (include links when applicable)
[ ] entered a system description using "Copy info to clipboard" on the sysinfo page. (when possible)
[X] entered the full filename of the used version (e.g. ESP_Easy_mega-20181001_test_ESP8266_4096_VCC.bin )
[ ] given a list of active plugins or controllers when applicable.
[ ] filled out all applicable fields below.

Steps already tried...

[ ] Tried a clean install (empty .bin files are included in the ZIP)
[ ] Tested previous/other build (mention which one already tested)
[ ] Tested on other node to make sure hardware isn't defective.
[ ] Verified if the problem is limited to a single plugin/controller

If you self compile, please state this and PLEASE try to ONLY REPORT ISSUES WITH OFFICIAL BUILDS!

Summarize of the problem/feature request

Hello everyone. after receiving my new TM1637, I tried to run it via ESPEasy (it works on Arduino IDE). Nothing was displayed (I try to display the temperature of my aquarium). I tried different firmware and the only one that does not block the ESP is the firmware: ESP_Easy_mega-20190305_test_core_260_sdk3_alpha_ESP8266_4Mo.bin So it's partly good, but he put the colon and not the dots. I tried all the different settings allowed in the plugin, no effect. I found on the internet that there was a new setting for the new TM1637 that include both decimal dots and colon. Could we have this new feature? (I can always put in black felt to hide the second point, but hey ...)

My TM1637 is plugged D5 -> DIO, D6 ->CLK.

Expected behavior

juste working, with/without the dot/colon, with all firmware.

Actual behavior

No working, just ESP blocked

Steps to reproduce

System configuration

Hardware:

ESP Easy version:

ESP Easy settings/screenshots:

Rules or log data

papperone commented 5 years ago

as I wrote the code to handle TM1637 I can tell you there's no way colon and dot can be controlled separated; I tested literally dozens of module of different manufacturer and all behave the same: either the dot or the colon... if you have any link/resource that explains somethign different I'll be more than happy to read it!

TD-er commented 5 years ago

Apart from the dot/colon stuff, can you name a few firmware builds that do not work with this plugin? I find it quite strange to see that all other core versions apparently do not work like expected.

jelinekpetr commented 5 years ago

Hi, I'm having the same problem - 7 segment display stopped working after 20190216. I've just finished testing - only build 260_SDK3_alpha works as expected regarding the 7 segment display in the next releases. (So the 20190325 release is the first one which has the problem with the plugin.)

I've tried to compile my own binary using platformio with no effect.

In the situation when the display doesn't work, it is automatically disabled by the software on the Devices tab. Manual enabling doesn't work at all. The display is disabled again after a while and no effect on the display itself after enabling.

But I haven't noticed any issues with the dots/colon when the display works.

Hope this helps...

Petr

jelinekpetr commented 5 years ago

My apologies!!! I was completely wrong when I wrote that the last working version was 20190216. It's not truth - I realized this this morning... Sorry. I'll continue the testing and try find the last working version. For this moment I definitely know that the last working version for me was 20190110, but I know nothing about the releases between 20190110 and 20190216. I'll let you know during the day. But only by the way: the 20190216 version cannot be upgraded OTA. It simply doesn't work. I have to do it via serial programmer... Will see when this bug started. Releases after 20190216 seem to be OK regarding the OTS update.

Petr

TD-er commented 5 years ago

But you are sure the plugin is working with the 260_sdk3 and not with other versions of the latest nightly build?

jelinekpetr commented 5 years ago

Absolutely. I normally use the test build. Yesterday evening I checked again that neither "normal" test build (2.42) nor SDK2 (2.60 alpha) build is working. Tested on the 20190305 release. Sounds strange I know but its true.

jelinekpetr commented 5 years ago

So I finally found the "breaking" release. And the winner is... 20190215. In that release first time the display stopped working when I selected test_core_242. The test_core_260_alpha worked fine.

In the changelog I can see:

[p073_7DGT] Reduce memory usage of 7-segment display plugin [memory] P073_7DGT Use Plugin_task_data array

Something connected with that?

TD-er commented 5 years ago

It is for sure a possibility why it stopped working, but what I really don't understand is why it is working with a newer core. Since @papperone has written the original code (I changed a lot in it to remove code duplication), maybe he can verify this very strange behavior?

jelinekpetr commented 5 years ago

My programming skills are limited but as far as can understand the problem I have to say it really sounds weird. What about different compiler settings between these builds?

nemocaledonie commented 5 years ago

Thank you for your reply @papperone concerning the decimal point. Actually on the module I bought the LED has only 12 pins, so no possibility to select and even less to display a small dot. My bad, I should have been careful and inquire before, but I'm not ruined :-). Finally I put a black felt and it does .... I agree with @jelinekpetr on the impossibility of compiling a functional 260_SDK3_ALPHA on PlatformIo. It's just my 2 cents.

papperone commented 5 years ago

I reviewed the code, and despite the modification done after I comepleted it I cannot find any good reason or clue why it shoudl not work with older core; I cannot compile it myself now as I replaced my man PC and with Arduino IDE (which is my main developping tool not only for hobby) I had so manyh toruble to compile last ESPEasy and no time to investigate why....

jelinekpetr commented 5 years ago

Hi all, I'm going to perform some hardware testing this morning - will connect a logic analyzer and compare good one vs. bad one. Will post the results as soon as I finish.

TD-er commented 5 years ago

@jelinekpetr That would be great. One thing that may be different between cores is the timing. But then core 2.4.2 and core 2.6.0 should not be that different, since they're using the same SDK version.

jelinekpetr commented 5 years ago

I've been analyzing the captured signals and it'll take more time than I thought. But for now it seems that it is some kind of timing problem. I'm comparing the signals on the bus just after reset - that's the time when happens something wrong because the device communicates a bit different according the build. Will try to finish as soon as possible with some result.

TD-er commented 5 years ago

Can you also see if the pull-up resistors in the ESP are set like you expect them to be?

jelinekpetr commented 5 years ago

So I've finished my little investigation but I don't have any clue where the culprit could be...

First of all, there is probably not a timing issue. Clock signal seems to be stable, no visible hazardous states, delays seem to be enough to recognize the data states correctly. No differences between builds regarding timing.

The first sequence of data communication after reboot is absolutely the same in all cases:

START
0x40 + ACK - Will write the data to register
STOP
START
0xC0 + ACK - Address of the first register in the device memory
0x00 + ACK - 6 times, it writes zeros to all display registers
STOP
START
0x88 + ACK - Display ON
STOP

After this sequence follows a delay and here is the first difference between working and not working versions. The delay in working version is about 850ms but in not working versions are the delays at least twice as longer (2.60SDK2 is 1756ms, 2.42 is 2007ms). The further communication differs depending on the version.

The working one:

START
0xC0 + ACK - Address
0xXX + ACK - 4 times data
STOP

After that the display shows the number.

Not working version is much more interesting. This follows after the delay:

START
STOP - this means that while the CLK line is still HIGH, DIO line goes down to LOW for about 30us

And the following communication repeats 7 times (2.60SDK2) or 8 times (2.42):

START
0x40 + ACK - Will write data to the register 
STOP
START
0xC0 + ACK - Address of the first register
0x00 + ACK - 6 times, it writes zeros to all display registers
STOP
START
0x88 + ACK - Display ON
STOP

After that I assume the plugin is disabled because there is no further communication on the bus.

I'm not sure if this analysis would help or not but it is the maximum from my side...

TD-er commented 5 years ago

Just to be sure, since that plugin is dealing with 2 different chips, what chip is on your module?

jelinekpetr commented 5 years ago

TM1637

jelinekpetr commented 5 years ago

And I've found one more thing which is probably not connected to the issue but who knows...

Not working builds send a short sequences of pulses to GPIO16 pin just after reset. I have a LED connected to the pin and I can see about 10 short flashes every reboot. In the image below the red peaks are in reality more than one pulse and they last around 20ms. And they aren't identical.

EDIT: and sorry for using the "not working build" phrase. It's only for description.

TD-er commented 5 years ago

GPIO-16 is a special pin with regard to booting and such. It is the pin that's being used to get the ESP out of deep sleep mode. Also this pin is a bit special with regards to what can be used on it for output (no PWM/I2C) and also it cannot be used for tasks that need to rely on interrupts. See also our documentation on GPIO pins

jelinekpetr commented 5 years ago

Yes, I'm aware of the GPIO16 has some special functions. But the behavior of the pin is different according to the build: in the build where the display works fine there is only one pulse at the very beginning of the boot process. Not ten ones during the first 20 seconds...

TD-er commented 5 years ago

So maybe we should also look into proper reset functions of the chip? If it can contain mangled data because of a improper acting pin, it can also be set in some unknown state from a previous run/crash or some external cause.

jelinekpetr commented 5 years ago

Maybe. Hard to recommend anything for me. In the picture below is behavior of the GPIO16 in case of 2.60SDK3.

jelinekpetr commented 5 years ago

And it might be only my personal feeling but I think that in case of pulses on GPIO16, the ESP is accessible (or running properly) after the pulses (flashing in my case) stops. That would direct us really somewhere to reset function. How could I check what is happening during the first 20 seconds? Serial port?

TD-er commented 5 years ago

Not sure if you can see anything related to that port in the logs, unless it is being used by another plugin. But I doubt that.

As a test you could have the plugin setup but not yet enabled during boot. Then after boot enable the plugin and see what happens.

jelinekpetr commented 5 years ago

Hi again after a month... :-)

Yesterday I flashed a new version (20190406) and the situation remains still the same. I have noticed that enabling the device (7 segment display) in version different from 260_SDK3 causes the reset of the whole system. Every time...

And one another thing seems to be strange to me: as far as I understand the P073 should already be a part of "normal" build. Am I right? But in "normal" build the 7 Segment display is not listed in the device you can add...

TD-er commented 5 years ago

Documentation indeed suggests it should be considered "stable" and the plugin name also does not have "[TESTING]" in the name. But in the plugin sets it is indeed still marked as testing.

I am not sure what to change now, given these issues. Should we label it "testing" again? Did you test the plugin using pins other than GPIO16?

jelinekpetr commented 5 years ago

For the LED display driver (TM1637) I use GPIO12 and GPIO13 pins. Only LED (diode) is connected to the GPIO16 in my case.

Not sure what to do. In case the display works (260_SDK3), it works with no issues. And even before this issue started it had worked very well.

And what about regression in code to the state before 20190215. Is it possible?

TD-er commented 5 years ago

And what about regression in code to the state before 20190215. Is it possible? It is possible to revert the changes back to the state before, but then I do throw away a serious amount of hours to get the code of that plugin cleaned up. The size of the code must come down, or else we need to split builds in even more separate builds or else it will not even fit in any environment.

I can make a separate build as a test where the code of this plugin has been reverted, but built in the current code base. Just to see if the issue is in the plugin or elsewhere.

jelinekpetr commented 5 years ago

I forgot to say "temporarily". It's clear that this is not a solution and a lot of work on this plugin from your side has been done since half of February.

A separate build sounds as a good idea. I'll try it and it'll be clear whether the isue is in the code of plugin or somewhere else.

TD-er commented 5 years ago

I was looking into the code to start creating a build for you to test. But the file has not changed since Feb1. See History _P073_7DGT.ino So I really don't think it is something in this plugin that's causing these issues if it was working. Just to be sure, I fetched the code of 20181231 for this plugin and it is now building.

TD-er commented 5 years ago

Can you test this test build ? It should be just like the last nightly build, but with the source of P073 replaced with the code from 20181231

jelinekpetr commented 5 years ago

Yes, no problem. But I'll be able to do it not before 20:00. And as soon as I'm done I'll let you know.

jelinekpetr commented 5 years ago

Sorry for delay, but I've managed to try your test build. Results: ESP_Easy_mega-20190409_test_core_242_ESP8266_4M.bin - works ESP_Easy_mega-20190409_test_core_260_sdk2_alpha_ESP8266_4M.bin - works ESP_Easy_mega-20190409_test_core_260_sdk3_alpha_ESP8266_4M.bin - works ESP_Easy_mega-20190409_test_core_260_sdk222_alpha_ESP8266_4M.bin - works ESP_Easy_mega-20190409_normal_ESP8266_4M.bin - does not work because this plugin is not built in

So the root of the problem must be in some code change been made whenever since last of December last year.

TD-er commented 5 years ago

OK, thanks for testing

jelinekpetr commented 5 years ago

You are welcome. Have a good night.

TD-er commented 5 years ago

This can be related to this issue: https://github.com/esp8266/Arduino/issues/6305

See also this form topic

TD-er commented 5 years ago

I was reading through the thread again and I think I know why it is showing so many flashes on the GPIO-16 pin. If the plugin does lead to crashes, it will be disabled after a while. The logic is quite simple; After 10 unsuccessful boots, it starts to disable a plugin at a time (after a new reboot). If that doesn't help, it will disable the controllers, etc. So if you're seeing for example 12 flashes, then the node has rebooted 10+2 times, meaning the 2nd plugin is probably the culprit and was disabled.

uzi18 commented 5 years ago

@TD-er have got info from friend about: 2019.02.12 works ok 2019.02.15 not work changelog:

      [p073_7DGT] Reduce memory usage of 7-segment display plugin
      [memory] P073_7DGT Use Plugin_task_data array

TD-er commented 5 years ago

Can you also test this build I made: https://www.dropbox.com/s/jwl75yx14c9jpan/testbuild_normal_core252_4M_7dgt%20%282%29.bin?dl=0

jelinekpetr commented 5 years ago

Hi, of course. But I'm in work now, I'll give it try in the evening. Will report about 9PM.

jelinekpetr commented 5 years ago

Hi, I'm here.

Bad news, mate. I successfully flashed the image but it can't boot at all. Pulses on GPIO16 every 7 or 8 seconds. The GUI is not accessible as well. Serial output repeats almost the same every mentioned 7 or 8 secs:

INIT : Booting version:  (ESP82xx Core 2_5_2, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.1.2 PUYA support)
67 : INIT : Free RAM:33600
68 : INIT : Cold Boot - Restart Reason: External System
71 : FS   : Mounting...
95 : FS   : Mount successful, used 78061 bytes of 957314
113 : 
 ets Jan  8 2013,rst cause:4, boot mode:(3,7)

wdt reset
load 0x4010f000, len 1384, room 16 
tail 8
chksum 0x2d
csum 0x2d
v8b899c12
~ld
�U75 : 

INIT : Booting version:  (ESP82xx Core 2_5_2, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.1.2 PUYA support)
76 : INIT : Free RAM:33600
77 : INIT : Warm boot #1 Last Task: Background Task - Restart Reason: Hardware Watchdog
79 : FS   : Mounting...
104 : FS   : Mount successful, used 78061 bytes of 957314
121 : 
 ets Jan  8 2013,rst cause:4, boot mode:(3,7)

wdt reset
load 0x4010f000, len 1384, room 16 
tail 8
chksum 0x2d
csum 0x2d
v8b899c12
~ld
�U75 : 

INIT : Booting version:  (ESP82xx Core 2_5_2, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.1.2 PUYA support)
76 : INIT : Free RAM:33600
77 : INIT : Warm boot #2 Last Task: Background Task - Restart Reason: Hardware Watchdog
79 : FS   : Mounting...
104 : FS   : Mount successful, used 78061 bytes of 957314
121 : 
 ets Jan  8 2013,rst cause:4, boot mode:(3,7)

wdt reset
load 0x4010f000, len 1384, room 16 
tail 8
chksum 0x2d
csum 0x2d
v8b899c12
~ld
�U75 : 

INIT : Booting version:  (ESP82xx Core 2_5_2, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.1.2 PUYA support)
76 : INIT : Free RAM:33600
77 : INIT : Warm boot #3 Last Task: Background Task - Restart Reason: Hardware Watchdog
79 : FS   : Mounting...
104 : FS   : Mount successful, used 78061 bytes of 957314
121 : 
 ets Jan  8 2013,rst cause:4, boot mode:(3,7)

wdt reset
load 0x4010f000, len 1384, room 16 
tail 8
chksum 0x2d
csum 0x2d
v8b899c12
~ld
�U75 : 

INIT : Booting version:  (ESP82xx Core 2_5_2, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.1.2 PUYA support)
76 : INIT : Free RAM:33600
77 : INIT : Warm boot #4 Last Task: Background Task - Restart Reason: Hardware Watchdog
79 : FS   : Mounting...
104 : FS   : Mount successful, used 78061 bytes of 957314
121 : 
 ets Jan  8 2013,rst cause:4, boot mode:(3,7)

wdt reset
load 0x4010f000, len 1384, room 16 
tail 8
chksum 0x2d
csum 0x2d
v8b899c12
~ld
�U75 : 

INIT : Booting version:  (ESP82xx Core 2_5_2, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.1.2 PUYA support)
76 : INIT : Free RAM:33600
77 : INIT : Warm boot #5 Last Task: Background Task - Restart Reason: Hardware Watchdog
79 : FS   : Mounting...
104 : FS   : Mount successful, used 78061 bytes of 957314
121 : 
 ets Jan  8 2013,rst cause:4, boot mode:(3,7)

wdt reset
load 0x4010f000, len 1384, room 16 
tail 8
chksum 0x2d
csum 0x2d
v8b899c12
~ld
�U75 : 

INIT : Booting version:  (ESP82xx Core 2_5_2, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.1.2 PUYA support)
76 : INIT : Free RAM:33600
77 : INIT : Warm boot #6 Last Task: Background Task - Restart Reason: Hardware Watchdog
79 : FS   : Mounting...
104 : FS   : Mount successful, used 78061 bytes of 957314
121 : �B

and so on...

TD-er commented 5 years ago

OK, thanks for the report.

TD-er commented 5 years ago

Can you test this test build ?

jelinekpetr commented 5 years ago

No problem, but again - around 8pm earliest... I'll report as soon as I finish the test.

LanWolf commented 5 years ago

I tested ESP_Easy_mega-20190716-15-PR_2514_test_core_252_ESP8266_4M It does display a clock then i choose 4 digit DOT or COLON and use the 24 or 12 H clock or date

in manual it does display a clock with the rule: On Clock#Time=All,: Do 7dn,%syshour%.%sysmin_0% EndOn

(in the old 2018-11-21 version i used timers in the rules to switch between display of temperature and time)

jelinekpetr commented 5 years ago

So I'm here again. Sorry for being a bit late.

I have tested 4M versions with this results:

ESP_Easy_mega-20190716-15-PR_2514_test_core_242_ESP8266_4M.bin - not working, after boot the temperature is shown on the display (correctly), but my buttons doesn't work (they changing values on the display according the rules) and each 10s reset occurs
ESP_Easy_mega-20190716-15-PR_2514_normal_ESP8266_4M.bin - not working, flash on GPIO16 every 1 or 2s
ESP_Easy_mega-20190716-15-PR_2514_normal_core_241_ESP8266_4M.bin - working OK
ESP_Easy_mega-20190716-15-PR_2514_normal_core_252_ESP8266_4M.bin - not working, flash on GPIO16 every 1 or 2s
ESP_Easy_mega-20190716-15-PR_2514_normal_core_260_sdk2_alpha_ESP8266_4M.bin - working OK
ESP_Easy_mega-20190716-15-PR_2514_normal_core_260_sdk222_alpha_ESP8266_4M.bin - working OK

If you want I can collect the serial port output.

jelinekpetr commented 5 years ago

I tested ESP_Easy_mega-20190716-15-PR_2514_test_core_252_ESP8266_4M It does display a clock then i choose 4 digit DOT or COLON and use the 24 or 12 H clock or date

in manual it does display a clock with the rule: On Clock#Time=All,: Do 7dn,%syshour%.%sysmin_0% EndOn

(in the old 2018-11-21 version i used timers in the rules to switch between display of temperature and time)

Interesting, the ESP_Easy_mega-20190716-15-PR_2514_test_core_252_ESP8266_4M doesn't work for me. Reset each 2 seconds:

INIT : Booting version:  (ESP82xx Core 2_5_2, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.1.2 PUYA support)
77 : INIT : Free RAM:30248
78 : INIT : Warm boot #61 Last Task: Background Task - Restart Reason: Software Watchdog
81 : FS   : Mounting...
106 : FS   : Mount successful, used 78061 bytes of 957314
570 : CRC  : program checksum       ...OK
Panic /home/gijs/.platformio/packages/framework-arduinoespressif8266/cores/esp8266/core_esp8266_main.cpp:134 loop_task

>>>stack>>>

ctx: sys
sp: 3ffffdc0 end: 3fffffb0 offset: 01b0
3fffff70:  00000000 3fffdad0 3fff2f28 4028b0b9  
3fffff80:  40000f49 3fffdab0 3fffdab0 40000f49  
3fffff90:  40000e19 40001878 00000002 3fffffb0  
3fffffa0:  3fffff10 aa55aa55 000000ed 401056ac  
<<<stack<<<

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

load 0x4010f000, len 1384, room 16 
tail 8
chksum 0x2d
csum 0x2d
v8b899c12
~ld
�U76 : 

INIT : Booting version:  (ESP82xx Core 2_5_2, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.1.2 PUYA support)
77 : INIT : Free RAM:30248
78 : INIT : Warm boot #62 Last Task: Background Task - Restart Reason: Software Watchdog
80 : FS   : Mounting...
105 : FS   : Mount successful, used 78061 bytes of 957314
570 : CRC  : program checksum       ...OK
Panic /home/gijs/.platformio/packages/framework-arduinoespressif8266/cores/esp8266/core_esp8266_main.cpp:134 loop_task

>>>stack>>>

ctx: sys
sp: 3ffffdc0 end: 3fffffb0 offset: 01b0
3fffff70:  00000000 3fffdad0 3fff2f28 4028b0b9  
3fffff80:  40000f49 3fffdab0 3fffdab0 40000f49  
3fffff90:  40000e19 40001878 00000002 3fffffb0  
3fffffa0:  3fffff10 aa55aa55 000000ed 401056ac  
<<<stack<<<

And so on.

TD-er commented 5 years ago

That's an interesting one:

Panic /home/gijs/.platformio/packages/framework-arduinoespressif8266/cores/esp8266/core_esp8266_main.cpp:134 loop_task

https://github.com/esp8266/Arduino/blob/8b899c12fb5044a6a51b92501bfcdf86a3d98dd8/cores/esp8266/core_esp8266_main.cpp#L129-L136

It looks like a stack overflow in our own code, or maybe the system stack was overwriting our stack? Do you have the option to test on a new node and create settings for only this plugin?

jelinekpetr commented 5 years ago

Hi, do you mean to perform erase_flash, then flash a .bin file and make a clean setup of the node? That's possible. It's only a bit discomfortable - will have to setup the node again, but the node is not a critical one. OK, will do it around 8pm. I'll report as soon as I finish.

letscontrolit / ESPEasy