Quest: Duet2Wifi + SBC without ESPectomy. Possible - yes!

TL;DR shorter wires and its fine (will try modifying only RRF and not WiFi FW later)

@bearer said in Duet 2 Ethernet and SBC:

I just wanted to see if it was possible to not remove the ESP, so far either i messed up hi-z firmware, or it has to GTFO. Thanks for taking a look!

If the firmware sets up the ESP reset pin and EN pins as outputs in the low state, then I think it should work without disconnecting the ESP. The additional capacitance of the ESP pins might reduce the maximum available SPI speed a little, but that speed isn't critical.

Pondered this for a while - didn't help.

Are you refering to the ESP reset pin and enable pin, also known as REST and CH_PD, pins 1 and 3 of the ESP12F respectively? Driving enable / CH_PD low will short it straight to 3.3 - and presumably shutdown the ESP?

Or were you thinking using GPIO on the PI to shut down and halt the ESP?

edit: current approach, (arduino) firmware to get SPI bus high impedance, sort of worked, but mostly didn't

arduino sketch for disabled wifi firmware:

void setup() {
   pinMode(14, INPUT); //SCK  / GPIO14
   pinMode(12, INPUT); //MISO / GPIO12
   pinMode(13, INPUT); //MOSI / GPIO13
   pinMode(15, INPUT); //CS   / GPIO15
   pinMode(0,  INPUT); //RDY  / GPIO0 
}

void loop() {
 ESP.deepSleep(0);
}

*) funkar, funkar inte, funkar, funkar inte.

Took anothe pass at it last night, looked good for a minute or so, but degraded to the same as before. Same wifi "firmware" with just the SPI pins as inputs (to go high impedance)

Next step; shorter cable, and perhaps try not to have a novice solder 0603 resistors inline on a #30 ribbon cable and i think it might just be able to work?

Serial said

RepRapFirmware for Duet 2 + SBC Version 3.02-beta dated 2020-06-25b1
RepRapFirmware for Duet 2 + SBC is up and running.
Connection to Linux established!

DWC said

6/27/2020, 1:35:42 AM	Connected to duet3
6/27/2020, 1:35:58 AM	Warning: Controller has been reset
6/27/2020, 1:36:17 AM	M122
=== Diagnostics ===
RepRapFirmware for Duet 2 + SBC version 3.02-beta running on Duet 2 1.02 or later + SBC (SBC mode)
Board ID: 08DGM-9T6BU-FG3SN-6J1FG-3SN6N-KVW7G
Used output buffers: 1 of 24 (10 max)
=== RTOS ===
Static ram: 36884
Dynamic ram: 82240 of which 20 recycled
Exception stack ram used: 256
Never used ram: 11672
Tasks: HEAT(blocked,1468) MAIN(running,2484) IDLE(ready,76)
Owned mutexes:
=== Platform ===
Last reset 00:01:23 ago, cause: power up
Last software reset at 2020-06-25 18:45, reason: User, spinning module GCodes, available RAM 10548 bytes (slot 0)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x04433000 BFAR 0xe000ed38 SP 0xffffffff Task MAIN
Error status: 0
MCU temperature: min 27.4, current 31.3, max 31.5
Supply voltage: min 0.1, current 0.9, max 0.9, under voltage events: 0, over voltage events: 0, power good: no
Driver 0: ok, SG min/max not available
Driver 1: ok, SG min/max not available
Driver 2: ok, SG min/max not available
Driver 3: ok, SG min/max not available
Driver 4: ok, SG min/max not available
Date/time: 2020-06-27 00:36:17
Cache data hit count 176606742
Slowest loop: 3.00ms; fastest: 0.08ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 10
SD card 0 not detected, interface speed: 30.0MBytes/sec
SD card longest read time 0.0ms, write time 0.0ms, max retries 0
=== Move ===
Hiccups: 0(0), FreeDm: 169, MinFreeDm: 169, MaxWait: 0ms
Bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0  CDDA state: -1
=== AuxDDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0  CDDA state: -1
=== Heat ===
Bed heaters = -1 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP* is ready with "M122" in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 0
USBchan is idle in state(s) 0
Aux is idle in state(s) 0
Trigger* is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
SBC is idle in state(s) 0
Daemon* is idle in state(s) 0
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== Linux interface ===
State: 0, failed transfers: 8
Last transfer: 5ms ago
RX/TX seq numbers: 834/842
SPI underruns 0, overruns 0
Number of disconnects: 0
Buffer RX/TX: 0/0-0
=== Duet Control Server ===
Duet Control Server v3.1.1
Code buffer space: 4096
Configured SPI speed: 2000000 Hz
Full transfers per second: 3.13
6/27/2020, 1:36:18 AM	Warning: Controller has been reset
6/27/2020, 1:36:21 AM	Warning: Controller has been reset
6/27/2020, 1:36:38 AM	Warning: Lost connection to Duet (Board is not available (no header))
6/27/2020, 1:36:38 AM	Connection to Duet established
6/27/2020, 1:36:50 AM	Warning: Lost connection to Duet (Board is not available (no header))
6/27/2020, 1:36:50 AM	Connection to Duet established
6/27/2020, 1:36:53 AM	Warning: Lost connection to Duet (Board is not available (no header))
6/27/2020, 1:36:53 AM	Connection to Duet established

Connections can be made to the ESP8266 itself on top of the board (2mm pitch), OR, to the header for the Ethernet under the board. (For an ethernet board, use the Ethernet header, its already 0.1" female)

If anyone wants to play (will likely need bossa to revert and files will be subject to random removal):
https://www.dropbox.com/s/06pgwqn8lqkmqxd/Duet2Firmware_2SBC_3.02-beta.bin?dl=0
https://www.dropbox.com/s/araqlt6679p5d9n/Duet2Wifi-disabled.bin?dl=0

dc42

@bearer said in Quest: Duet2Wifi + SBC without ESPectomy. Possible?:

Are you refering to the ESP reset pin and enable pin, also known as REST and CH_PD, pins 1 and 3 of the ESP12F respectively? Driving enable / CH_PD low will short it straight to 3.3 - and presumably shutdown the ESP?

Yes, I meant that if RepRapFirmware keeps the ESP RESET and CH_PD pins low then I would expect the ESP to leave its SPI pins in the high impedance state. But I suspect that the current build of RRF for Duet 2+SBC doesn't initialise those pins.

@dc42 said in Quest: Duet2Wifi + SBC without ESPectomy. Possible?:

RepRapFirmware

oh that firmware, that does make more sense, and a lot simpler. will try!
(but CH_PD/EN is still hardwired to ESP_3.3VIN, maybe reset is enough)

sdavi

@bearer said in Quest: Duet2Wifi + SBC without ESPectomy. Possible?:

oh that firmware, that does make more sense, and a lot simpler. will try!
(but CH_PD/EN is still hardwired to ESP_3.3VIN, maybe reset is enough)

Interestingly, someone posted some tests on pin states in various modes including held in reset over here: https://www.mjt.me.uk/posts/esp8266-gpio-deep-sleep-and-reset/

@sdavi said in Quest: Duet2Wifi + SBC without ESPectomy. Possible?:

Interestingly, someone posted some tests on pin states in various modes

I'll definitely take a look at replicating that with the pins in question. Thanks for the link, looks like at least the spi pins should be okay, the others differ from the D1.

Anyway shorter wires, without questionable soldering works, fine with the disabled wifi firmware. Will retry with just modified RRF when I can also do the measurements.

I had some 2.00mm male/female headers soldered to the ESP, a better solution might be solder jst ph headers and crimp the female. Or solder something like jst xh or molex kk to the 2.54mm header below the WiFi, as long as removal of the WiFi module isn't necessary it may provide an option for those who have their WiFi fail without an internal short.

Altnertive to solder resistor in-line in wire:

Connections:

Removable (but will leave the female header behind unless desoldered)

Less intrusive option for the Duet 2 Ethernet, will do something similar with pogo pins for the wifi.

Pogo for Wifi:

https://www.dropbox.com/s/g8s2ltzduo6j1fr/Duet2EthernetSBCdummy.stl?dl=0
https://www.dropbox.com/s/v3iigsq48qkz3ph/Duet2WiFiSBCpogo.stl?dl=0

more info here: https://forum.duet3d.com/topic/17203/duet-2-ethernet-and-sbc

@dc42 said in Quest: Duet2Wifi + SBC without ESPectomy. Possible - yes(ish).:

But I suspect that the current build of RRF for Duet 2+SBC doesn't initialise those pins.

It didn't, but it also didn't have to. Works with stock RRF 3.2 and stock Wifi 1.23, there is a slight glow to the Wifi LED but negblible difference in current (both draw 0.08A from USB). I'll stick with the dummy Wifi FW and try having RRF pull ESP_RST low later (and now I see some Duets have PE5 floating, some wired to CH_PD so will pull that low as well)