ESP32 Command Station

Atani Dec 10, 2017

  1. zubozrout

    zubozrout TrainBoard Member

    24
    1
    2
    Hm, that could actually be the cause. I've kept the original wiring I had with Arduino (at least I think) and that was not correct [I had A0 to A4 and A1 to A5]. Thank you and sorry about that.

    Now, for the switch that goes one way on Address 1 and back on Address 2 I get the following:

    Code:
    [PROG] CV 1 value is 0
    [PROG] CV 9 value is 0
    [PROG] CV 34 value is 0
    It says these values are verified. But why would it be 0 all the time? My engine also says 0 to everything and all verified.

    I am using this board: "WeMos D1 R32 UNO ESP32" to make it easier to connect my L298 Arduino motor shield to it. Maybe connecting A0 to A2 and A1 to A4 is still not correct but at least it now reads something for the the "Utilization (mA)" part for the main track which was 0 to me up until now.

    And finally ...

    The behaviour is certainly different with the code change. I can control some decoders with a single button but wonder if this is correct. It still seems weird as even when I try to change their addresses again more thoroughly (to 1, 2, 3, 4 and 5), the first turnout is still not operable unless jumper is connected. It only goes one way so it could expect address number 0 (?). And most decoders work in pairs so e.g. on "Accy 3 activate" decoder 2 and 3 goes one way and on "Accy 2 activate" the other. Both are going the same way at the same time.

    But I suppose I could have just been not lucky to set the addressed correctly.

    Anyway, with the change you propose it indeed makes the turnouts work with only a single button click, though then this also means more tweaks could be required as each button have two addresses and the neighboring buttons are intersecting with them.

    And then I also wonder if you had this implemented in the old base station code. These decoders worked previously just fine. So if not it is possibly not that.
     
  2. Atani

    Atani TrainBoard Member

    1,460
    1,698
    36
    You may need to adjust the jumpers to match the actual pin usage since you are using the L298, it is likely either A0->A2 or A0->A4 and A1->A3 or A1->A5. You can confirm this via the console output text during startup as it will tell you which ADC it is using. For the "WeMos D1 R32 UNO" the A0-A5 pins are:
    • A0 - 2 - ADC 2 (unusable)
    • A1 - 4 - ADC 2 (unusuable)
    • A2 - 35 - ADC 1 - 7
    • A3 - 34 - ADC 1 - 6
    • A4 - 36 - ADC 1 - 0
    • A5 - 39 - ADC 1 - 3
    That is likely correct behavior, looking back at the old code it seems the CS would generate closed packets as even addresses and thrown as odd addresses. It is possible to have the decoder use a single address and toggle between the two states though, but that may require an extra flag to adjust how the packet is generated.

    From a quick review it seems the packet format was changed in v1.5.0 in an incompatible manner to what was there previously. With the proposed code change it should restore the original behavior. Very likely you will want to reprogram the decoders with the jumper in place to have them pick up the correct addresses.
     
  3. garry2577

    garry2577 TrainBoard Member

    17
    1
    3
    hi atani
    built dava bodnor /dcc ++ controller and your esp8266 base station .now on your esp32 command station how do i set up jmri still with dcc++ or something else .sorry if i come ove a bit daft but i feel like i am reading a bible of conflicts and errors but i am learning .i am using platformio and arduino
    thanks garry
     
  4. Atani

    Atani TrainBoard Member

    1,460
    1,698
    36
    If you are using the v1.2.3 (last public release) you should be able to configure JMRI to use a DCC++ over IP (Ethernet?) connection to the CS using it's IP address and port 2560. If you are using the development branch (or v1.5.0 as it is also known), I would suggest enabling the LCC Hub option via the CS web interface and use the LCC connection type from JMRI using either the service name "_openlcb-can._tcp" or using the IP address of the CS and port 12021.
     
  5. garry2577

    garry2577 TrainBoard Member

    17
    1
    3
    cheers mike i am useing last issue on github i will have a look .please be safe
    garry thicko from manchester uk
     
    Atani likes this.
  6. zubozrout

    zubozrout TrainBoard Member

    24
    1
    2
    Thank you :),
    then I suppose that this:
    Code:
    [OPS] Configuring H-Bridge (L298 2000 mA max) using ADC 1:0
    [PROG] Configuring H-Bridge (L298 2000 mA max) using ADC 1:3
    is this:
    "A4 - 36 - ADC 1 - 0" and "A5 - 39 - ADC 1 - 3" = "A0->A4 and A1->A5"

    However, although the track "Utilization (mA)" seems now to work just fine, for reading CVs I am back to getting this:
    Code:
    [PROG 3/3] Attempting to read CV 1
    [PROG 3/3] CV 1, could not be verified
    [PROG] CV 1 value is -1
    It could be that A1 is still connected incorrectly. With A1 → A3, A1 → A2 and A1 disconnected the results are the same.
     

    Attached Files:

  7. Atani

    Atani TrainBoard Member

    1,460
    1,698
    36
    Since utilization works I'd expect ACKs to work as well. I'll need to do some testing on this to see what I can find as this area has gone through a major rework and it is entirely possible something is broken now. I'll do some digging...
     
  8. Gregory Gee

    Gregory Gee TrainBoard Member

    10
    2
    5
    Hello, new to the group. I was looking at previous posts and also into the git repo. I wasn't sure if I had an ESP32. I assume the 32 means R32? I looked in my drawer and found a WEMOS D1R2. I assume this is too old? Sorry for the newbie questions. This project looks quite interesting.

    Thanks,
    Greg
     
  9. Atani

    Atani TrainBoard Member

    1,460
    1,698
    36
    Close, the ESP32 is a series of SoC modules from Espressif. They commonly have printed names on them such as WROOM-32, WROVER-B, PICO-D4, etc. They should not be confused with any of the ESP8266 SoC which are very similar in shape, packaging, etc.

    Unfortunately this is very likely an ESP8266 based on the naming. There are only a couple boards that I currently recommend for this project:
    • ESP32 Uno D1 R32
    • TTGO T1
    • ESP32 DevKit-C
    Note that I will be offering a PCB kit in the very near future (pending restock of a few components right now, current ETA is mid June for delivery). The kit will require some assembly but if there is demand I may offer a pre-assembled / tested package for a slightly higher price.
     
  10. Atani

    Atani TrainBoard Member

    1,460
    1,698
    36
    I believe I have found the reason why this is not working currently and I'm working on a solution for it.
     
    zubozrout likes this.
  11. John Flanagan

    John Flanagan TrainBoard Member

    45
    6
    7
    I don't know if you care, and if not just let me know but I tried your latest build and had two issues:
    First the locomotives page doesn't load on Firefox (all I tried). And then there was a panic:
    assertion "localNodes_.find(id) == localNodes_.end()" failed: file "../components/OpenMRNLite/src/openlcb/If.hxx", line 319, function: void openlcb::If::add_local_node(openlcb::Node*)
    abort() was called at PC 0x40186c8f on core 0

    Decoding stack results
    0x40092e38: invoke_abort at C:/Users/johnf/esp-idf/components/esp32/panic.c line 157
    0x40093221: abort at C:/Users/johnf/esp-idf/components/esp32/panic.c line 172
    0x40186c8f: __assert_func at /builds/idf/crosstool-NG/.build/HOST-i686-w64-mingw32/xtensa-esp32-elf/src/newlib/newlib/libc/stdlib/assert.c line 62
    0x40092e38: invoke_abort at C:/Users/johnf/esp-idf/components/esp32/panic.c line 157
    0x40093221: abort at C:/Users/johnf/esp-idf/components/esp32/panic.c line 172
    0x40186c8f: __assert_func at /builds/idf/crosstool-NG/.build/HOST-i686-w64-mingw32/xtensa-esp32-elf/src/newlib/newlib/libc/stdlib/assert.c line 62
    0x401258b6: openlcb::If::add_local_node(openlcb::Node*) at c:\users\johnf\.espressif\tools\xtensa-esp32-elf\esp-2019r2-8.2.0\xtensa-esp32-elf\xtensa-esp32-elf\include\c++\8.2.0\bits/stl_tree.h line 984
    0x401259b2: openlcb::TrainService::register_train(openlcb::TrainNode*) at ../components/OpenMRNLite/src/openlcb/TractionTrain.cpp line 622
    0x40125a49: openlcb::TrainNodeForProxy::TrainNodeForProxy(openlcb::TrainService*, openlcb::TrainImpl*) at ../components/OpenMRNLite/src/openlcb/TractionTrain.cpp line 62
    0x40125a49: openlcb::TrainNodeForProxy::TrainNodeForProxy(openlcb::TrainService*, openlcb::TrainImpl*) at ../components/OpenMRNLite/src/openlcb/TractionTrain.cpp line 62
    0x40102665: commandstation::AllTrainNodes::create_impl(int, commandstation::DccMode, int) at ../components/LCCTrainSearchProtocol/AllTrainNodes.cpp line 671
    0x40102665: commandstation::AllTrainNodes::create_impl(int, commandstation::DccMode, int) at ../components/LCCTrainSearchProtocol/AllTrainNodes.cpp line 671
    0x40102b6d: commandstation::AllTrainNodes::get_train_node_id(int) at c:\users\johnf\.espressif\tools\xtensa-esp32-elf\esp-2019r2-8.2.0\xtensa-esp32-elf\xtensa-esp32-elf\include\c++\8.2.0\bits/shared_ptr_base.h line 996
    0x40102b6d: commandstation::AllTrainNodes::get_train_node_id(int) at c:\users\johnf\.espressif\tools\xtensa-esp32-elf\esp-2019r2-8.2.0\xtensa-esp32-elf\xtensa-esp32-elf\include\c++\8.2.0\bits/shared_ptr_base.h line 996
    0x400eea01: process_loco(http::HttpRequest*) at ../main/WebServer.cpp line 975
    0x400eea01: process_loco(http::HttpRequest*) at ../main/WebServer.cpp line 975
    0x4019885f: std::_Function_handler::_M_invoke(std::_Any_data const&, http::HttpRequest*&&) at c:\users\johnf\.espressif\tools\xtensa-esp32-elf\esp-2019r2-8.2.0\xtensa-esp32-elf\xtensa-esp32-elf\include\c++\8.2.0\bits/std_function.h line 88
    0x4019885f: std::_Function_handler::_M_invoke(std::_Any_data const&, http::HttpRequest*&&) at c:\users\johnf\.espressif\tools\xtensa-esp32-elf\esp-2019r2-8. line 62
    0x40102665: commandstation::AllTrainNodes::create_impl(int, commandstation::DccMode, int) at ../components/LCCTrainSearchProtocol/AllTrainNodes.cpp line 671
    0x40102665: commandstation::AllTrainNodes::create_impl(int, commandstation::DccMode, int) at ../components/LCCTrainSearchProtocol/AllTrainNodes.cpp line 671
    0x40102b6d: commandstation::AllTrainNodes::get_train_node_id(int) at c:\users\johnf\.espressif\tools\xtensa-esp32-elf\esp-2019r2-8.2.0\xtensa-esp32-elf\xtensa-esp32-elf\include\c++\8.2.0\bits/shared_ptr_base.h line 996
    0x40102b6d: commandstation::AllTrainNodes::get_train_node_id(int) at c:\users\johnf\.espressif\tools\xtensa-esp32-elf\esp-2019r2-8.2.0\xtensa-esp32-elf\xtensa-esp32-elf\include\c++\8.2.0\bits/shared_ptr_base.h line 996
    0x400eea01: process_loco(http::HttpRequest*) at ../main/WebServer.cpp line 975
    0x400eea01: process_loco(http::HttpRequest*) at ../main/WebServer.cpp line 975
    0x4019885f: std::_Function_handler::_M_invoke(std::_Any_data const&, http::HttpRequest*&&) at c:\users\johnf\.espressif\tools\xtensa-esp32-elf\esp-2019r2-8.2.0\xtensa-esp32-elf\xtensa-esp32-elf\include\c++\8.2.0\bits/std_function.h line 88
    0x4019885f: std::_Function_handler::_M_invoke(std::_Any_data const&, http::HttpRequest*&&) at c:\users\johnf\.espressif\tools\xtensa-esp32-elf\esp-2019r2-8.2.0\xtensa-esp32-elf\xtensa-esp32-elf\include\c++\8.2.0\bits/std_function.h line 88
    0x4011739f: http::HttpRequestFlow::process_request_handler() at c:\users\johnf\.espressif\tools\xtensa-esp32-elf\esp-2019r2-8.2.0\xtensa-esp32-elf\xtensa-esp32-elf\include\c++\8.2.0\bits/std_function.h line 370
    0x4011739f: http::HttpRequestFlow::process_request_handler() at c:\users\johnf\.espressif\tools\xtensa-esp32-elf\esp-2019r2-8.2.0\xtensa-esp32-elf\xtensa-esp32-elf\include\c++\8.2.0\bits/std_function.h line 370
    0x4011ba81: StateFlowBase::run() at ../components/OpenMRNLite/src/executor/StateFlow.cpp line 63
    0x4011ba81: StateFlowBase::run() at ../components/OpenMRNLite/src/executor/StateFlow.cpp line 63
    0x4011b88d: ExecutorBase::entry() at ../components/OpenMRNLite/src/executor/Executor.cpp line 323
    0x4011b88d: ExecutorBase::entry() at ../components/OpenMRNLite/src/executor/Executor.cpp line 323
    0x40199335: OSThread::start(void*) at ../components/OpenMRNLite/src/os/OS.hxx line 193
    0x40199335: OSThread::start(void*) at ../components/OpenMRNLite/src/os/OS.hxx line 193
    0x40125dc3: os_thread_start at ../components/OpenMRNLite/src/os/os.c line 391
    0x40125dc3: os_thread_start at ../components/OpenMRNLite/src/os/os.c line 391

    2.0\xtensa-esp32-elf\xtensa-esp32-elf\include\c++\8.2.0\bits/std_function.h line 88
    0x4011739f: http::HttpRequestFlow::process_request_handler() at c:\users\johnf\.espressif\tools\xtensa-esp32-elf\esp-2019r2-8.2.0\xtensa-esp32-elf\xtensa-esp32-elf\include\c++\8.2.0\bits/std_function.h line 370
    0x4011739f: http::HttpRequestFlow::process_request_handler() at c:\users\johnf\.espressif\tools\xtensa-esp32-elf\esp-2019r2-8.2.0\xtensa-esp32-elf\xtensa-esp32-elf\include\c++\8.2.0\bits/std_function.h line 370
    0x4011ba81: StateFlowBase::run() at ../components/OpenMRNLite/src/executor/StateFlow.cpp line 63
    0x4011ba81: StateFlowBase::run() at ../components/OpenMRNLite/src/executor/StateFlow.cpp line 63
    0x4011b88d: ExecutorBase::entry() at ../components/OpenMRNLite/src/executor/Executor.cpp line 323
    0x4011b88d: ExecutorBase::entry() at ../components/OpenMRNLite/src/executor/Executor.cpp line 323
    0x40199335: OSThread::start(void*) at ../components/OpenMRNLite/src/os/OS.hxx line 193
    0x40199335: OSThread::start(void*) at ../components/OpenMRNLite/src/os/OS.hxx line 193
    0x40125dc3: os_thread_start at ../components/OpenMRNLite/src/os/os.c line 391
    0x40125dc3: os_thread_start at ../components/OpenMRNLite/src/os/os.c line 391
     
  12. Atani

    Atani TrainBoard Member

    1,460
    1,698
    36
    I'll see if I can reproduce this, likely the CS restarted due to what appears to be a bug in the LwIP side:
    Code:
    Guru Meditation Error: Core  1 panic'ed (LoadProhibited). Exception was unhandled.
    Backtrace: 0x400934a3:0x3ffd5cb0 0x40092405:0x3ffd5cd0 0x401a9bb7:0x3ffd5cf0 0x40091c81:0x3ffd5d10
    0x400934a3: sys_mutex_unlock at esp-idf/components/lwip/port/esp32/freertos/sys_arch.c:93
    0x40092405: sys_sem_signal at ??:?
    0x401a9bb7: lwip_netconn_do_recv at esp-idf/components/lwip/lwip/src/api/api_msg.c:1675
    0x40091c81: tcpip_thread_handle_msg at /esp-idf/components/lwip/lwip/src/api/tcpip.c:208
     (inlined by) tcpip_thread at esp-idf/components/lwip/lwip/src/api/tcpip.c:154
    
    And a second one that I haven't traced fully yet but appears to be a stateflow gone awry from the http side:
    Code:
    Backtrace: 0x40093570:0x3ffcdfc0 0x40093965:0x3ffcdfe0 0x4018f2c3:0x3ffce000 0x4018f30a:0x3ffce020 0x4018faaf:0x3ffce040 0x4011c531:0x3ffce060 0x401a34f9:0x3ffce090 0x40126e0f:0x3ffce0b0
    0x40093570: invoke_abort at /home/mdunston/esp-idf/components/esp32/panic.c:157
    0x40093965: abort at /home/mdunston/esp-idf/components/esp32/panic.c:172
    0x4018f2c3: __cxxabiv1::__terminate(void (*)()) at /builds/idf/crosstool-NG/.build/xtensa-esp32-elf/src/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:47
    0x4018f30a: std::terminate() at /builds/idf/crosstool-NG/.build/xtensa-esp32-elf/src/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:57
    0x4018faaf: __cxa_pure_virtual at /builds/idf/crosstool-NG/.build/xtensa-esp32-elf/src/gcc/libstdc++-v3/libsupc++/pure.cc:50
    0x4011c531: ExecutorBase::entry() at ESP32CommandStation/build/../components/OpenMRNLite/src/executor/Executor.cpp:323
    0x401a34f9: OSThread::start(void*) at ESP32CommandStation/build/../components/OpenMRNLite/src/os/OS.hxx:193
    0x40126e0f: os_thread_start at ESP32CommandStation/build/../components/OpenMRNLite/src/os/os.c:391
    
    This looks like it tried to add a duplicate train node. I'll see if I can reproduce this via the web interface
     
  13. John Flanagan

    John Flanagan TrainBoard Member

    45
    6
    7
    This was FYI only. I am just playing with this and thought you might want to see it as you are making changes in that area. Do not prioritize this. And if you don't want to see more of these just let me know.

    Thanks

    John
     
  14. John Flanagan

    John Flanagan TrainBoard Member

    45
    6
    7
    I will re-download all of the code in case git has had an issue over the weeks I have just been doing updates. Not likely as any issue should show up in the diffs, but not unheard of.
     
  15. Atani

    Atani TrainBoard Member

    1,460
    1,698
    36
    Keep it up, I'm definitely interested in areas which need to have some extra attention as I may miss something during my testing or simply not encounter it as part of it.

    You can run "git reset --hard ; git pull" and it should revert to the latest available on GitHub. I've also just pushed three fixes that I encountered during my recent testing a few mins ago. The latest being for Esp32WiFiManager shutdown.
     
  16. John Flanagan

    John Flanagan TrainBoard Member

    45
    6
    7
    I rebuilt everything and still have the errors. But they may come from "Failed to load url:/locomotive" and "Failed to load url:/power" I don't know how that works, but I tried both IP addresses and mDNS. And the only "locomotive" is can find in the repository is for consist.
     
  17. John Flanagan

    John Flanagan TrainBoard Member

    45
    6
    7
    I deleted the repository and asked gitgui to re-pull it down. And got the shutdown fixes.
     
  18. John Flanagan

    John Flanagan TrainBoard Member

    45
    6
    7
    Sorry for all of the short msgs, but I forgot to say I get the same results on FireFox and Chrome.
     
  19. Atani

    Atani TrainBoard Member

    1,460
    1,698
    36
    make sure to force a refresh of the webpage, I've seen the browser cache it even through headers are set to force a revalidate on reload.

    This may mean the CS crashed while trying to process a request. Can you check the CS console output? I'm not 100% certain of the fix just yet but I have an idea of where it might be.
     
  20. John Flanagan

    John Flanagan TrainBoard Member

    45
    6
    7
    You are exactly right, the CS crashed. I tried a factory reset and that started down a long rat hole. A Flash Erase cleared that up and things look good now.
     

Share This Page