ESP32 Command Station

Atani Dec 10, 2017

  1. Atani

    Atani TrainBoard Member

    1,460
    1,698
    36
    If you have the console output from before the flash erase I can look at why you needed to do the reset. It is usually a case of a corrupted data file and I'd like to correct any occurrences of that if I can before v1.5.0 is out.
     
  2. John Flanagan

    John Flanagan TrainBoard Member

    45
    6
    7
    I do not, sorry. It was in a constant reboot loop.
     
  3. Atani

    Atani TrainBoard Member

    1,460
    1,698
    36
    Ok, if it reproduces please capture a snippet of the console showing why it is rebooting and I can take a look further at it.
     
  4. Gregory Gee

    Gregory Gee TrainBoard Member

    10
    2
    5
    Yes, both ESP boards I have say ESP8266.

    Does it matter if it is WROOM-32D ? I'm looking online, and see many ESP32 Uno D1 R32. When I zoom into the image, I see ...32D on the chip. From what I can search, they should be the same.


    https://usa.banggood.com/LILYGO-TTG...lopment-Board-p-1163967.html?cur_warehouse=CN

    Greg
     
  5. Atani

    Atani TrainBoard Member

    1,460
    1,698
    36
    That will be fine, the WROOM-32D is an updated version of the WROOM-32 SoC.
     
  6. John Holdsworth

    John Holdsworth TrainBoard Member

    21
    4
    6

    there always seems a lot of confusion with what pins are actually being used for SDA and SCL in ESP32 since they are configure-able. My handy tip is to use Serial.print(SDA) and Serial.print(SCL) which will send the actual configured values to the serial port. Maybe insert these two print statements into void setup() after running the esp32 command station and see what you've got?

    eg
    void setup(){
    .
    .
    .
    .
    Serial.print("sda pin: ");
    Serial.print(SDA);
    Serial.print("scl pin: ");
    Serial.print(Scl);
    .
    .
    .
    }
     
  7. Atani

    Atani TrainBoard Member

    1,460
    1,698
    36
    was that via the web interface? I found a bug yesterday related to a reset dialog not showing up on the web interface and fixed that last night, however, I just spotted an issue with the current factory reset code when invoked from the web (it would clear LCC and WiFi config only). I'll be pushing a fix in a short bit to correct the factory reset code to clear all config and not just LCC/WiFi config.
     
  8. John Flanagan

    John Flanagan TrainBoard Member

    45
    6
    7
    I did it from the WEB interface and saw nothing happen. I expected a reset and didn't see it. And once I reset the board it came back up with the WiFi values still in place. I have moved this board through lots of your updates. I don't expect that your code to have to handle that sort of operation. It makes sense to have to erase the board every now and then.

    John
     
  9. Atani

    Atani TrainBoard Member

    1,460
    1,698
    36
    Hmm, it should have popped up a dialog showing a pending reset. Sounds like it crashed before it could pop that up or something else...

    Hopefully things will be stable for a while with IDF v4.0. I've been testing with IDF v4.2 (master) and there are a few areas that will break and after about an hour of poking around I gave up on moving up to that for now but I will need to revisit it further very soon as arduino-esp32 is moving up to 4.2 for ESP32-S2 support and I will need to get OpenMRN working on top of that (some works now).
     
  10. FlightRisk

    FlightRisk TrainBoard Member

    548
    237
    14
    @Atani, BTW, did you buy the dso138 kit or find one fully assembled?
     
  11. Atani

    Atani TrainBoard Member

    1,460
    1,698
    36
    I bought it assembled, I wouldn't recommend the older model one like I have. @Shdwdrgn picked up a dso138mini recently and it has a number of fixes over the one I have. The biggest problem with all of the dso138 line of products is the noise that will show up in the graph, I don't know of a good way to really eliminate it but you can reduce it some with the adjustment screws.
     
  12. John Flanagan

    John Flanagan TrainBoard Member

    45
    6
    7
    I tried to compile you code with the current master just to see what would happen. I knew from your previous post that it would fail. What I didn't know what how much has changed at level 4.1. What is the usual/normal way folks handle changes like the Ethernet stack or event loops. Two ways that I have done that are with #ifdef >4.1 new else current in the code itself. Or to create an abstraction layer to hide the #ifdef code and migrate that way when < 4.1 stops being an issue.

    What is the open source usual way? Both are messy and both make the code less readable. The abstraction layer tends to start adding arguments that are unneeded and messy.

    A third way is two separate files and either have #ifdef's around the whole file for use build tools to select the file.
     
  13. Atani

    Atani TrainBoard Member

    1,460
    1,698
    36
    IDF v4.1 (and master which is 4.2) has changed considerably in the wifi stack, specifically tcpadapter has been replaced with esp_netif... I'm working through the diffs now so OpenMRN (and OpenMRNLite) will work on 3.3, 4.0, 4.1 and 4.2... I should have it all sorted over the weekend. I need to get this done as I now have an ESP32-S2 in hand for testing of the new arduino-esp32 which will be very soon packaging ESP-IDF master (as arduino-esp32 v2.0). There will be a few "missing" features in the first version of OpenMRN for the ESP32-S2 (mainly TWAI [aka CAN]).

    IDF v4 supports the new esp_event library and that is the direction I'm taking currently but maintaining backward compatibility in the one area that needs it (Esp32WiFiManager). All other areas of the CS have been shifted over to esp_event consumption directly (pending commit and push still).

    yes, with the bulk of the events being processed only in Esp32WiFiManager I'm opting to have all abstractions in there instead of sprinkling it all over since the CS currently depends on IDF v4.0 anyway.
     
  14. Atani

    Atani TrainBoard Member

    1,460
    1,698
    36
    FYI, I've posted v1.5.0-alpha1 on GitHub. This is a major update from the v1.2.x (or the unreleased v1.3.0). As this is a major update existing configuration will not be preserved. Please follow the build instructions linked from the release page here.

    There are bound to be some lingering issues in this release thus the need for an alpha before official release.

    I've also made a couple updates to the ESP32 CS PCB which I'm working through testing using the above release tag. I'm hoping to be ready to offer PCB kits sometime during June (limited supply initially but more will be available soon!)
     
  15. zubozrout

    zubozrout TrainBoard Member

    24
    1
    2
    Hi,
    I am not sure if this is expected, but with the latest version on master (and I was able to reproduce the same a few days ago when I tried this too) the whole station crashes for me whenever I try to switch a turnout:

    Code:
    [Turnout 1] Registered as type LEFT and initial state of Closed
    [WS 192.168.1.29/51] Connected
    [WebSocket fd:51] read-error, disconnecting
    [WS 192.168.1.29/51] Disconnected
    Incoming connection from 192.168.1.29, fd 51.
    [OPS]      0 mA / 2000 mA
    Incoming connection from 192.168.1.29, fd 51.
    Incoming connection from 192.168.1.29, fd 52.
    [WS 192.168.1.29/51] Connected
    abort() was called at PC 0x400d6bcb on core 0
    
    This happens no matter the address of the turnout is or the track power state (on/off).

    The turnouts also never really save. Except for the above case with turnout ID 0 that is now persistently listed in the turnouts list of the Web UI, but trying to delete it results in "[Turnout 0] not found". I suspect that it trying to create turnout 1 and delete turnout 0 is related to the issue I had with switching one way requiring a different address than the other way.

    I am also not sure how I got "read-error, disconnecting" there - that could be some random unexpected state as it only happened to me once. Maybe that's the reason why the first turnout saved for me as the first time I tried it didn't save.

    Also it seems that when I save a turnout and turn the esp off and then on again the turnout is still not saved (at least not listed in the web ui) so this seems unrelated to the crash that occurs when trying to switch the turnout.
     
  16. Atani

    Atani TrainBoard Member

    1,460
    1,698
    36
    Definitely not expected. If you can run this again using the "idf.py montior" option to have it decode the backtrace automatically it will help some. But it looks at a high level like a failed lookup for the turnout, I'll see if I can reproduce this on my local setup as well.

    I'll see what I can do to reproduce this as well, the turnouts should get persisted every ~30sec if there have been any changes. I suspect there is a missing check somewhere.

    This is likely related to the turnout persistence issue above. There is a background task that fires every ~30sec that should persist any changes.

    I just saw this as well and I haven't narrowed down what the cause for it is yet. The websocket is only used by the web throttle and it should re-establish the connection on-demand.
     
  17. John Flanagan

    John Flanagan TrainBoard Member

    45
    6
    7
    Zubozrout, I was just wondering the last time you erased the flash on the esp32? I have had issues with something being persisted there that caused aborts. Erasing the flash solved my issues.

    John
     
  18. Atani

    Atani TrainBoard Member

    1,460
    1,698
    36
    I've done some digging into this and it appears that for one reason or another the LwIP stack thinks the socket has been disconnected while reading/writing data. It is not limited to just websocket connections and it is not 100% clear why the LwIP stack ends up in this state. I've logged issue #32 to track this.
     
  19. Atani

    Atani TrainBoard Member

    1,460
    1,698
    36
    @zubozrout I've pushed a few updates this morning to master which will fix the turnout persistence issue you reported.
     
    zubozrout likes this.
  20. John Flanagan

    John Flanagan TrainBoard Member

    45
    6
    7
    Impressive code drops this week. WOW.
     
    Atani likes this.

Share This Page