Display works, nothing else

[menime8]

Hi there,
i have a Dreamstream SPA, which has exact the same electronics like Lay Z Spa. Both selled from Bestway.
My Pump looks like the newer 2021 model.

I started with PCB V2, NodeMCUV3 and the TXS0108E. First try, nothing happend.
Second try with 10K resistor, it Starts, DSP starts flashing.
Third try: 560 ohm resistors between DSP and ESP. Display works fine, melody and IP shown.

But i can't get any connection to the CIO. Wires and connections are all checked with my meter.

I hope anyone can give me a hint 🤔

Thanks

[visualapproach]

Maybe try resistors btwn LLC and cio also?
Or switch to the MOSFET version of LLC. Or try without LLC which is probably fine in practice but may blow the esp in theory according to some people. For the price I'd take the chance...

[menime8]

Maybe try resistors btwn LLC and cio also? Or switch to the MOSFET version of LLC. Or try without LLC which is probably fine in practice but may blow the esp in theory according to some people. For the price I'd take the chance...

Tried both versions. Resistors everywhere, then only ESP direct to CIO and DSP.

[menime8]

I have 6 wires, +5v, 0V, RX, TX and one for Sound. What does the last wire?

[SigmaPic]

I have 6 wires, +5v, 0V, RX, TX and one for Sound. What does the last wire?

It's a 3 wire SPI line. Isn't it ?
So, data, clk and chip select instead of RX and TX.

If you still have access to the pump PCB.
May you tell me if you can read the reference of that chip

[menime8]

I thought it was RX TX....
I will have a look tomorrow for chipnumbers.

[visualapproach]

Maybe try resistors btwn LLC and cio also? Or switch to the MOSFET version of LLC. Or try without LLC which is probably fine in practice but may blow the esp in theory according to some people. For the price I'd take the chance...

Tried both versions. Resistors everywhere, then only ESP direct to CIO and DSP.

Oh I see now that you connected 5V to the 3V3 input. Remove that blue wire and check that the ESP is not toasted

[visualapproach]

It's a 3 wire SPI line. Isn't it ?
So, data, clk and chip select instead of RX and TX.

That's right for 6 wire models except the 54149E, although it is a bit unusual mode which esp cannot do in hardware unfortunately. Hence the bitbanging

If you still have access to the pump PCB.
May you tell me if you can read the reference of that chip

Great if this get some clarification. Thx

[menime8]

Maybe try resistors btwn LLC and cio also? Or switch to the MOSFET version of LLC. Or try without LLC which is probably fine in practice but may blow the esp in theory according to some people. For the price I'd take the chance...

Tried both versions. Resistors everywhere, then only ESP direct to CIO and DSP.

Oh I see now that you connected 5V to the 3V3 input. Remove that blue wire and check that the ESP is not toasted

It isn´t.

I used the plan from here #312

I know it could be toasted, this was my last try on sunday.

[menime8]

I have 6 wires, +5v, 0V, RX, TX and one for Sound. What does the last wire?

It's a 3 wire SPI line. Isn't it ? So, data, clk and chip select instead of RX and TX.

If you still have access to the pump PCB. May you tell me if you can read the reference of that chip

I read Nuvoton MS51FB9AE

https://www.nuvoton.com/products/microcontrollers/8bit-8051-mcus/industrial-8051-series/ms51fb9ae/

[menime8]

Today i tried many different options, with and without resistors, with 560 and 680. It wouldn't work. Checked again all connections.
The other mosfet LLC arrives, too.
I see my ESP has resistors between D3 and 3v and D4 and 3v. I ordered a other ESP. More Info i have on the next few days.

[visualapproach]

Did you get rid of the blue wire?

[menime8]

Yes

[visualapproach]

Good, I would also try some caps on CIO side and use the B port to get a better LPF. And/or overclock the ESP if there is something speed related.

[menime8]

I measured on all 3 lines from CIO 4,9xx Volt with jumping around 20 mV. What would i see with my oscilloscope?

Which capacitance? 22myF?

[visualapproach]

Ok so both ends has 1K resistors and unknown caps. So we can calculate a range of cap values with the RC formula. Cut off freq should be higher than the SPI freq. The SPI on my pump is 22 kHz IIRC. I reckon 200-1000 pF would do it.
I need to think a bit on this but what you can check with the scope is the clock frequency on the clock line. And measuring the highs and lows voltages.
I'm not an EE so don't expect miracles here but let's try to find this out

[menime8]

The picture is from the CIO. I don't have any from the DSP. I order a few 200pf, so i can do 200/400/600 pf and so on in parallel.

I'm pretty sure, it works with that older Nodemcu.

[SigmaPic]

I read Nuvoton MS51FB9AE

https://www.nuvoton.com/products/microcontrollers/8bit-8051-mcus/industrial-8051-series/ms51fb9ae/

Thanks. It's a microcontroller. I will check the pin config capabilities (push pull, open drain, pull up...)

Looking at the signals with a scope may allow you to detect the root cause of the issue. You can look at signal on CIO side but also on esp side and see if something goes wrong.

I'm pretty sure, it works with that older Nodemcu.

Which one do you talk about ?

@visualapproach Did you implement a sort of test mode ? We can imagine plugging both connectors from the BWC together. Then you generate some signal in one side and you check that you can read them on other side.
Only the 5V should be added. By doing this, it would allow to check the BWC board.

[visualapproach]

That's a great idea @SigmaPic
I'm on it

[SigmaPic]

That's a great idea @SigmaPic
I'm on it

I'm very busy this time. Otherwise I would have propose a PR.

Maybe you can try to generate 101010 at the rate of the SPI and check if you read the correct bits. Then you change the polarity of the inputs and outputs.

[SigmaPic]

I'm pretty sure, it works with that older Nodemcu.

Ok. I see the resistors: 12k pull up on CS and CLK on DSP side.
On CS, it should not be an issue because this pin is set at high level at startup because it's an active low => the pull up is a good think
For the CLK, it may not be an issue because if CS is high, CLK should no be taken into account.

[menime8]

I'm pretty sure, it works with that older Nodemcu.

Which one do you talk about ?

I have the version 3.2. i ordered the 3.0 version with the CH340

[SigmaPic]

Yes

On this photo you don't have the resistors on CIO side. Do you confirm that you tried with them ?

[menime8]

On this photo you don't have the resistors on CIO side. Do you confirm that you tried with them ?

Yes, tried 560 and 680 ohms

[visualapproach]

@SigmaPic I wonder if we can/should set the gpio:s to open drain or with pull up resistors. Don't remember what it is now and what can be done, but could be worth a look. When I have time

[menime8]

One question, isn't it possible to use the Miso/Mosi/CLK from the ESP?

[visualapproach]

Espressif states mode 3 is not supported.

[SigmaPic]

I'm pretty sure, it works with that older Nodemcu.

I think it won't change anything because there are some pull up on your mosfet LLC. See my shematic below.
So the pull up on esp side won't change anything.
But, you can try to be sure. Maybe I'm wrong.

@SigmaPic I wonder if we can/should set the gpio:s to open drain or with pull up resistors. Don't remember what it is now and what can be done, but could be worth a look. When I have time

I take a look at the full schematic and I found something strange that may explain some troubles.
The issue concerns the mosfet LLC when data are sent from DSP/CIO to ESP.
The other way is ok (from ESP to DSP/CIO).

As you can see on my simulation, the voltage on ESP input stay at 1.5V when DSP/CIO drive the line to 0.
This comes from the serial 1k resistor.
On this simulation, I put one 1k which is the one in the DSP/CIO and one 1k which is the one we put on our PCB.
If I remove one 1k, it's better but not perfect.
To get perfect results, I need to remove both 1k resistors which is not possible because we have at least one.

Why it happens ?
Because these two 1k resistors act as a voltage divider with 10k pull up on the LLC (5V side).
This means that the input of the LLC is at 0.83V instead of 0V due to this voltage divider.
Because of that, the mosfet is not driven and the output of the LLC is 0.83V + mosfet diode forward volatge which is about 0.8V.
So we get about 1.5/1.6V in output of the LLC which is greater that the input low voltage of the ESP which is 0.25x3.3 = 0.8V.

To confirm that issue, we could developp a dumy test SW that just put all pins in input and print the state in the console.
Then we can manually put 5V on each pin and check if it's correctly detected.

As a workaround, we can eventually modify the resistors mounted on the LLC.
Put for example 50k instead of 10k.
An removed all pull up resistors on ESP side, the ones we talked previously that are externally mounted on some ESP.
By doing this, we are theoretically in the spec of the chip.
But it requires some soldering and the PCB of the LLC is very cheap => difficult to replace the resistor without breaking the PCB.

To "perfectly" solve that issue the easiest way is to use two pin of the ESP to handle the data line.
For all other lines (CS, CLK, audio), we can continue to the use the mosfet LLC or replace it by simple mosfet as shown on this schematic. But these other lines work in a single direction, so only one mosfet and one pin is needed.

@visualapproach What do you think about that ?

But now you may wonder why it work for some people ?
It may work for some people because, we reach 1.5/1.6V on the input of the ESP.
According to ESP datasheet, everything under 0.8V is seen as 0 and everything over 2.5V is seen a 1.
It means that everything between 0.8V and 2.5V is undertermined. Depending on some factors, it may work or not.

And why not using the recommended TXS0108E ?
Finally, it may be better to use TXS0108E instead of mosfet LLC. What I don't like is that Texas recommend to shorten the output wires and not use capacitive load. In out case, we have long wires and filter with capacitors. So, I'm not sure that the chip works correctly.

My old school design with discrete mosfets takes two more pins (one for the CIO and one for the DSP) but looks more robust.

[menime8]

thanks for your detailed version
But why the direct connections won't work?

And what is with his issue?
He put the USB cable to ESP and then it works.
Some problems with low voltage and spreading tolerances from that esp8622?
#325 (comment)

[SigmaPic]

thanks for your detailed version But why the direct connections won't work?
And what is with his issue? He put the USB cable to ESP and then it works. Some problems with low voltage and spreading tolerances from that esp8622? #325 (comment)

I'm sorry, I d'ont know.
I can explain why I could not work with a mosfet LLC but I cannot explain why it doesn't work with a direct connection.
According to internet, ESP is 5V tolerant and according to the datasheet of you microcontroller, 3.3V is enough to be seen as a logical 1. So, I would say that we can connect it directly.

Really I don't know what issue can the powerbank solve.

May be a soldering issue ? Or a broken ESP ? It's my only explanation.

This photo is quite strange, you have a short circuit between 3V and 5V and you don't have the resistor.
Do you confirm that you try:

• without the short circuit between 3V and 5V
• with serial resistors
• without LLC (direct connection)

Third try: 560 ohm resistors between DSP and ESP. Display works fine, melody and IP shown.

Where is shown the IP ?

[visualapproach]

10

[menime8]

Yes. No page, No reset.

[visualapproach]

@SigmaPic if you want to try something you can comment out all ESP.wdtDisable() and ESP.wdtFeed() in BWC_common.cpp. If you still get HARDWARE watchdog reboots we ruled out my part of the code and its very likely to be websockets or http related.

[SigmaPic]

@SigmaPic if you want to try something you can comment out all ESP.wdtDisable() and ESP.wdtFeed() in BWC_common.cpp. If you still get HARDWARE watchdog reboots we ruled out my part of the code and its very likely to be websockets or http related.

wdtEnable as well ?

[visualapproach]

May as well

[visualapproach]

I'm away now but there is a debug mode in websockets. See if you can figure out how to turn it on. Maybe define DEBUG or similar in main.cpp

[SigmaPic]

I'm away now but there is a debug mode in websockets. See if you can figure out how to turn it on. Maybe define DEBUG or similar in main.cpp

You're right, I saw the debug mode.

I have compiled without the wdt. Let's see that first. Then I will try the debug mode.

[SigmaPic]

@visualapproach cannot reproduced for the moment by removing all ESP.wdtXXX

[visualapproach]

That's good in a weird way. Do you get sw reboot if you save stuff like price/kwh?

[SigmaPic]

Still no reboot during the night. I removed the heartbeat. So the wdtXXX seems to help.

I tried to save several time the config with that SW, no reboot.

[SigmaPic]

The wdt is feed only on get/setJSONxxx.
In some other function, I'm the wdt is disabled.

It means that these functions would not called during a few time ?
I think they are used by the webserver, no ?

[SigmaPic]

@visualapproach why do you use the software watchdog ?

I have read that its timeout is not well defined, around 1.5 and 3 seconds.

Why the hardware watchdog is not enough ?

[visualapproach]

Technically I try to Not use the watchdog but I see what you mean. Espressif made it this way and the idea is good; if your program hangs while the device is doing something important and is hard to get to, it resets and can hopefully recover. That would be the HWWDT I guess. Then I think they wanted a second WDT to ensure Wi-Fi and the OS gets enough CPU time. Anyway, during development I had problems with the SWWDT triggering so I fed it or killed it and it worked. It's possible that something changed with the new OS and arduino core updates so it's not necessary to disable the sw wdt. Or that there was something else triggering.

[visualapproach]

I don't get why enabling the sw wdt would keep the hw wdt from triggering. Or to be more correct, the sw wdt is enabled all the time, we just disabled it at time consuming functions. But if these functions would stall and trigger the hw wdt we would get the sw wdt instead now. Unless some other code relies on the sw wdt. Well if it continue to work I'll update the code.

[RatAttack83]

Mine is working now, too! ☺️ I will post it here, if there is a wd problem... But I think its everything ok! ☺️ So tomorrow i will print a case and than project finish!
Thank you everybody for the troubleshooting! ☺️

[SigmaPic]

Technically I try to Not use the watchdog but I see what you mean. Espressif made it this way and the idea is good; if your program hangs while the device is doing something important and is hard to get to, it resets and can hopefully recover. That would be the HWWDT I guess. Then I think they wanted a second WDT to ensure Wi-Fi and the OS gets enough CPU time. Anyway, during development I had problems with the SWWDT triggering so I fed it or killed it and it worked. It's possible that something changed with the new OS and arduino core updates so it's not necessary to disable the sw wdt. Or that there was something else triggering.

I'm not sure to understand what you mean and what has been imagined by expressif.

If I'm right, hwdt timeout cannot be changed but swdt can (for the moment it seems not possible for the swdt too).

When you feed the swdt, it feed the hwdt as well.

My understanding is that swdt is just the way to adjust the timeout of the watchdog but currently it's not possible.

What is strange is that they are linked. When you feed the swdt, it feed the hwdt. This is unlogical.

It could be interesting if you could setup several swdt and in that case hwdt would only be fed if all swdt are fed.

For this project, if hwdt timeout is ok (6s if I'm right) then we can only work with hwdt. If swdt timeout is needed (less than 6s), you could eventually enable it for some parts of the code but I don't see the reason why a reduced timeout would be needed for us.

So, I think we can disable the swdt for all the project but we can still feed the hwdt in BWC_common.cpp if needed.

The best would be to implement two swdt so that you can manage two timeouts, one for the webserver part for example, one for the MQTT... But one hwdt is enough I think. That's already a good practice to have one hwdt.

[SigmaPic]

I don't get why enabling the sw wdt would keep the hw wdt from triggering. Or to be more correct, the sw wdt is enabled all the time, we just disabled it at time consuming functions. But if these functions would stall and trigger the hw wdt we would get the sw wdt instead now. Unless some other code relies on the sw wdt. Well if it continue to work I'll update the code.

I explain before, enabling the sw wdt don't keep the hw wdt from triggering. It's feeding the swdt that feed the hw wdt as well. So hw wdt won't be fired it swdt is feed correctly because swdt timeout is shorter.

I still don't have any watchdog reboot since I removed all the wdt calls in BWC_common.cpp.

If I'm right, in some functions m, you disable the swdt when you enter the function and you enable it when you exit. This means that swdt is enabled for the rest of the execution of the software, thus for the websockets for example.

Why I trying to say is that you have the swdt timeout for the websockets and maybe it's not enough, especially when you have several clients.

Maybe I'm speculating 😂

[visualapproach]

@SigmaPic

I'm not sure to understand what you mean and what has been imagined by expressif.

Something got lost in translation I think. Don't know how to answer that. Moving on.

But it's clear that the documentation on the K9's are unclear...

So, I think we can disable the swdt for all the project but we can still feed the hwdt in BWC_common.cpp if needed.

Possibly, but it's there to guard against full receive buffers and stuff, so then we would get crazy errors instead of a sw reset. I'm also speculating here. But If it works for you guys I think I'll remove the wdt-stuff.

[SigmaPic]

@menime8 can you confirm it works for you as well.

To check, just remove all lines that start with "ESP.wdt" in BWC_common.cpp, rebuild and check.

[menime8]

@menime8 can you confirm it works for you as well.

To check, just remove all lines that start with "ESP.wdt" in BWC_common.cpp, rebuild and check.

Never Touch a running system 😁

Last reboot was at July, 24th. The problem is too much tabs in my explorer. So i can handle it now. If i have time next week, i try it.

[visualapproach]

@SigmaPic I experimented a bit with the dogs. When I removed the statements that disabled and fed the dog I too had hardware watchdog resets when I had one page open on computer and one on iPhone. When I locked the screen on iPhone I got hw wdt every time. Now I have ESP.wdtFeed() in all those functions, and it seems okay again. Like you said :-)

[SigmaPic]

If all the functions are called within the main main loop, you can feed the dog within them.

Don't feed it in interrupts because you will loose all the benefits of the watchdog.

[SigmaPic]

On my side I got all the components. I solder everything and it was plug and play. It works great.

What is the best to perform an OTA ?
Power off the pump ?

[visualapproach]

Yes I fed the dog in the functions called by main loop indirectly. Interrupts should be as short as possible and everything must be in iram so I didn't plan to do that 😃

I don't fully understand your question about OTA. You can do it anytime the module is online. I do it when it's hidden in the pump as well as on the bench. Maybe avoid rainy days in case it doesn't work so you don't have to go outside.

[SigmaPic]

Ok for the 🐶 😀

I wonder what happens if the ESP stops working during the OTA whereas the pump continue to send SPI frames.

All the pins are in input during OTA ?

[SigmaPic]

And also, is there a power button on the web page ? The same button you have on the pump ?

[visualapproach]

I wonder what happens if the ESP stops working during the OTA whereas the pump continue to send SPI frames.

All the pins are in input during OTA ?

Not sure about the pin mode during the OTA, but I have done it many times on PCB V1 and 2 without any problems. The 4 wire systems are less tolerant than 6 wire. They get E13 com failure after a few seconds, but the 6 wire has no problem with that.

[visualapproach]

And also, is there a power button on the web page ? The same button you have on the pump ?

Nope, I deliberately removed that functionality. As far as I know the only thing it did was dimming the display. Which you can do in the web ui anyway. Perhaps it put the cpu in sleep mode to save half a watt or so, but I doubt it.

Technically it's not difficult to expose it but why add an extra useless button press?

[SigmaPic]

I see two reasons:

• when you want to power off the pump, you can do it through one command
• when you look at the pump you don't have the green led ON.

[RobReus]

Commenting here since I did not see it being mentioned anywhere else regarding the blue LLC.

I built the controller for my 2021 Maldives (6-wire S100104 square pump) using the PCB_V2B wiring. Instead of using the red LLC, I used the blue LLC (TXS0108E) and it worked like a charm. I did have to add resistors to the display output (D3, D4 and D6 iirc) to stop the flashing, but other than that, it worked flawlessly.

I forgot to take pictures, but the wiring looked identical to what has been posted in this issue already, except for the fact that those 3 wires for the display are not connected to the A pins but to the B pins with a 560Ohm resistor.

Great job to everyone involved on troubleshooting, debugging, and finding a working solution for these new models!