4 wire v4 DSP E13 with CIO

[cobaltfish]

Hardware:

• Pump model 54144
• 4 wire
• PCB V1
• Level shifter TXS0108E

Software:

• Firmware: 2023-03-21-1724
• development_v4

I'm having problems getting the display to work reliably with my 4 wire Palm Springs Hydrojet Sometimes it works perfectly, and soon after the display power on beep, it changes temp from the default 25 to the temp detected by the pump unit. Other times it continually fails. When it does work, it seems, eventually after a period of time it stops working, and even rebooting, disconnecting display once all booted up does not fix it

I've tired doing a bit of debug, and in lib/BWC_unified/CIO_BASE.cpp and lib/BWC_unified/DSP_BASE.cpp enabled lines 7 - 9 to get it to print out via serial the raw payload I also added an output in the std::vector DSP::getRawPayload() and std::vector CIO::getRawPayload() sections so I could inspect what was going through there too, which resulted in lots of lines like this (taken from when I plugged display in):

DSP:raw_payload_to_dsp 170 2 14 0 0 16 0
DSP:raw_payload_from_dsp 0 0 0 0 0 0 0
CIO:raw_payload_to_cio 0 0 0 0 0 0 0
CIO:raw_payload_from_cio 170 2 14 0 0 16 0
DSP:raw_payload_to_dsp 170 2 14 0 0 16 0
DSP:raw_payload_from_dsp 0 0 0 0 0 0 0
CIO:raw_payload_to_cio 0 0 0 0 0 0 0
CIO:raw_payload_from_cio 170 2 14 0 0 16 0
DSP:raw_payload_to_dsp 170 2 14 0 0 16 0
DSP:raw_payload_from_dsp 85 1 0 48 0 49 0
CIO:raw_payload_to_cio 85 1 0 48 0 49 0
CIO:raw_payload_from_cio 170 2 14 0 0 16 0

When the display was plugged in the raw_payload_from_dsp and raw_payload_to_cio then started showing data Maybe I'm looking in the wrong place, but I noticed when I unplugged the display again (to stop the beeping!) that the raw_payload_from_dsp continued to show data

Button presses, when taking control still work, even with display unplugged

Is there something better for me to look at for debugging why the display and pump unit are not communicating, as it appears that packets are getting through

[visualapproach]

Thanks for the report. You can check the bootlog.txt file. It logs the reason for every reboot, so what does it say? Its normal that the DSP appears to continue to report data after beeing disconnected. The program just reports the last message sent. But it's good that you report the details. The reboot may be caused by out of memory issues, and I'll work on that.

[cobaltfish]

I don't think it was rebooting, as I'd also expect to see End of setup() in the serial log. It just seems that the display isn't getting comms it expects I've got it running again now, and will try and note how long it is before it throws an error.
Its strange, as sometimes it goes straight into E13 as soon as I plug display in, other times it will work for a while, but once it fails, I can't figure out how to get it to work again.

[cobaltfish]

So it ran for about 1 hour before E13, and bootlog only shows the boot at 9am: {"BOOTINFO":"External System 2023-03-24 09:01:35"}

I put the output of the serial into a text file ran it through sort and uniq -c it to get this:

   1 --- Available filters and text transformations: colorize, debug, default, direct, esp8266_exception_decoder, hexlify, log2file, nocontrol, printable, send_on_enter, time
   1 --- More details at https://bit.ly/pio-monitor-filters
   1 --- Quit: Ctrl+C | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H
   1 --- Terminal on /dev/cu.usbserial-14130 | 115200 8-N-1
   1 16 0
   1 CIO:raw_payload_from_cio 170 2 16 0 0 18
   1 D0 16 0
   1 DSP:raw_payload_tSHDSP:raw_payload_from_dsp 85 1 0 48 0 49 170
   1 load_to_ciyload_from_cio 170 2 14 0 0 16 0
  18 load_to_cio 85 1 0 48 0 49 170
  33 CIO:raw_payload_to_cio 85 1 0 48 0 49 0
  33 DSP:raw_payload_from_dsp 85 1 0 48 0 49 0
7706 CIO:raw_payload_from_cio 170 2 16 0 0 18 170
7706 DSP:raw_payload_to_dsp 170 2 16 0 0 18 170
11175 CIO:raw_payload_from_cio 170 2 15 0 0 17 170
11175 DSP:raw_payload_to_dsp 170 2 15 0 0 17 170
12095 CIO:raw_payload_from_cio 170 2 14 0 0 16 170
12095 DSP:raw_payload_to_dsp 170 2 14 0 0 16 170
52807 CIO:raw_payload_from_cio 170 2 16 0 0 18 0
52807 DSP:raw_payload_to_dsp 170 2 16 0 0 18 0
80851 CIO:raw_payload_from_cio 170 2 15 0 0 17 0
80851 DSP:raw_payload_to_dsp 170 2 15 0 0 17 0
87658 CIO:raw_payload_from_cio 170 2 14 0 0 16 0
87659 DSP:raw_payload_to_dsp 170 2 14 0 0 16 0
252260 DSP:raw_payload_from_dsp 85 1 0 48 0 49 170
252261 CIO:raw_payload_to_cio 85 1 0 48 0 49 170

CIO:raw_payload_from_cio 170 2 16 0 0 18 was the final line as I stopped the serial, so can also be ignored The first 5 lines can be ignored, as they were as the serial console started up

DSP:raw_payload_tSHDSP:raw_payload_from_dsp 85 1 0 48 0 49 170 is the 6th line in the log file and can also be ignored

Early on (line 402 / 1009199) there was a little section where the serial output looks malformed:

    401 DSP:raw_payload_to_dsp 170 2 14 0 0 16 170
    402 D0 16 0
    403 DSP:raw_payload_from_dsp 85 1 0 48 0 49 170
    404 CIO:raw_payload_to_cio 85 1 0 48 0 49 170
    405 load_to_cio 85 1 0 48 0 49 170
    406 load_to_cio 85 1 0 48 0 49 170
    407 load_to_cio 85 1 0 48 0 49 170
    408 load_to_cio 85 1 0 48 0 49 170
    409 load_to_cio 85 1 0 48 0 49 170
    410 load_to_cio 85 1 0 48 0 49 170
    411 load_to_cio 85 1 0 48 0 49 170
    412 load_to_cio 85 1 0 48 0 49 170
    413 load_to_cio 85 1 0 48 0 49 170
    414 load_to_cio 85 1 0 48 0 49 170
    415 load_to_cio 85 1 0 48 0 49 170
    416 load_to_cio 85 1 0 48 0 49 170
    417 load_to_cio 85 1 0 48 0 49 170
    418 load_to_cio 85 1 0 48 0 49 170
    419 load_to_cio 85 1 0 48 0 49 170
    420 load_to_cio 85 1 0 48 0 49 170
    421 load_to_cio 85 1 0 48 0 49 170
    422 load_to_cio 85 1 0 48 0 49 170
    423 load_to_ciyload_from_cio 170 2 14 0 0 16 0
    424 DSP:raw_payload_to_dsp 170 2 14 0 0 16 0

but from 424 onwards, it settles back down

The only other thing I can spot is that there is 1 less DSP:raw_payload_from_dsp compared to the CIO:raw_payload_to_cio with data 85 1 0 48 0 49 170 and 1 less CIO:raw_payload_from_cio than DSP:raw_payload_to_dsp with data 170 2 14 0 0 16 0

The full file is 42MB

[visualapproach]

hmm.. "External system" is reported after you reset the ESP by pressing the hardware reset button. So that is strange and could use some investigation from you. In your logs, it seems things are truncated. "load_to_cio" should be "payload_to_cio" and so on. Is it your making or is data missing? In any case, I suggest you try the latest beta version 2023-03-25. May not solve this particular problem, but it has more free memory available which is always good.

[cobaltfish]

Yep, the "External System" reset is fine, I had just flashed the firmware with the extra serial output logging / debugging I'll try and get that new beta put on today and let you know what I find

[cobaltfish]

No joy building I'm afraid:

In file included from src/main.cpp:1:
src/main.h:29:10: fatal error: WiFiManager.h: No such file or directory

*********************************************************************
* Looking for WiFiManager.h dependency? Check our library registry!
*
* CLI  > platformio lib search "header:WiFiManager.h"
* Web  > https://registry.platformio.org/search?q=header:WiFiManager.h
*
*********************************************************************

   29 | #include <WiFiManager.h>
      |          ^~~~~~~~~~~~~~~
compilation terminated.
*** [.pio/build/nodemcuv2/src/main.cpp.o] Error 1
======================================================================================= [FAILED] Took 11.17 seconds =======================================================================================

I couldn't see WiFiManager.h in commit 3829cdc

[visualapproach]

It's a 3:rd party library that should be downloaded automatically since it's listed as tzapu/wifimanager in platformio.ini. Maybe clean build will fix it. But you can wait a few days til I upload next version.

[cobaltfish]

That is missing in my platformio.ini. I've added it in, and it is building now. Thanks :-)

[visualapproach]

Probably my mistake, oops

[cobaltfish]

I think I've got to the bottom of it. It was a hardware fault. "Someone", who wishes to remain nameless might have failed to double check the continuity of the soldered joints on their test board. With a dry joint on the D7 pin on the DSP plug, sometimes data would get through, sometimes it wouldn't. But the connections for D2 and D3 on CIO plug and D6 on the DSP plug were good, making it look like everything should be working.

With the latest in the dev branch I'm now seeing wifi errors with the new manager. I can stick it in another ticket, but it may be something already in the next version.

It doesn't seem to connect to my wifi any more, even after entering config. This is the serial log that I see:

Start
WiFi > Using WiFiManager Config Portal
*WM: 
*WM: AutoConnect
*WM: Connecting as wifi client...
*WM: Status:
*WM: 0
*WM: Using last saved values, should be faster
*WM: Connection result: 
*WM: 4
*WM: 
*WM: Configuring access point... 
*WM: Lay-Z-Spa Module
*WM: layzspam0dule
*WM: AP IP address: 
*WM: 192.168.4.1
*WM: HTTP server started
*WM: Scan done
*WM: DUP AP: <my-ssid>
*WM: <my-ssid>
*WM: -48
*WM: Sent config page
*WM: Scan done
*WM: <my-ssid>
*WM: -47
*WM: Sent config page
*WM: WiFi save
*WM: Sent wifi save page
*WM: Connecting to new AP
*WM: Connecting as wifi client...
*WM: Status:
*WM: 0
*WM: [ERROR] WiFi.begin res:
*WM: 7
*WM: Connection result: 
*WM: 255
*WM: Failed to connect.

[visualapproach]

Try removing "PROGMEM" from enums.h line 57-ish I know it's a source of trouble and will be removed next update

[visualapproach]

beta/dev branch updated. Should be more stable.

[cobaltfish]

Thanks, I've got that deployed and looks to be running ok