ESP32 Command Station

Atani Dec 10, 2017

  1. John Flanagan

    John Flanagan TrainBoard Member

    45
    6
    7
    A quick question. The processing task takes a lock and then the scheduler task blocks on that lock. The processing task unlocks and the scheduler task gets the lock. That implies that the tasks are running on different processors or one is an interrupt task. Do you know which the case would be?
     
  2. John Flanagan

    John Flanagan TrainBoard Member

    45
    6
    7
    The task priority change is looking good so far. I need to leave until much later tonight. I will leave it running.

    Thanks
     
    Atani likes this.
  3. Atani

    Atani TrainBoard Member

    1,460
    1,697
    36
    When the task is waiting for the lock it yields internally to the scheduler which will transition to the next "ready" task (based on task priority). Similarly when a task releases the lock the next task that is waiting for it will get the lock via the current task yielding. This is all internal to the FreeRTOS stack.
     
  4. John Flanagan

    John Flanagan TrainBoard Member

    45
    6
    7
    Still running. To my question before. It is not the unlock switch that I was interested in but rather how the scheduler got control. What I didn't consider is that the processing task gives up control while the lock is held. That must be the case, probably doing a SEND.
     
  5. Atani

    Atani TrainBoard Member

    1,460
    1,697
    36
    The FreeRTOS scheduler will forcibly interrupt a task (if necessary) to provide cycles to another task at the same or higher priority. However, at the point of calling various APIs with portMAX_DELAY or similar it will automatically place the calling task into a suspended/blocked state and shift to another "ready" task.
     
  6. ghruei

    ghruei TrainBoard Member

    33
    6
    2
    I have a little more time and I am back playing with this again. After going through the thread I have switched to using the development branch and I am now using TTGO-t1 as I have run out of the otheESP32 Dev boards. I have flashed up my NextionNX4042T and added the status LEDS.
    (I am again really impressed by the effort you have done on this Atani.)

    I am getting a couple of errors when running. Below is the major stopper at the moment. When I hit the "Stop" button on the Nextion display the system crashes. I have included the trace below if this helps to point to anything. The main issues is that the motor then goes to full speed and it appears that the motor board has become unresponsive? I have to recycle the power to get things working again. I can reproduce this issue. Note the 3 status leds do not give any indication of any issue. They go from green back to blue.

    [RMT] Starting RMT for OPS
    [OPS] Enabling track output
    [OPS] 0 mA / 2000 mA
    [RMT] Shutting down RMT for OPS
    [OPS] Disabling track output
    [RMT] Starting RMT for OPS
    [OPS] Enabling track output
    [TaskMon] uptime: 00:03:48 freeHeap: 173688, largest free block: 111368, tasks: 17, mainBufferPool: 464
    [OPS] 0 mA / 2000 mA
    [OPS] 0 mA / 2000 mA
    [TaskMon] uptime: 00:04:34 freeHeap: 173688, largest free block: 111368, tasks: 17, mainBufferPool: 464
    [OPS] 0 mA / 2000 mA
    [TaskMon] uptime: 00:05:20 freeHeap: 173600, largest free block: 111368, tasks: 17, mainBufferPool: 464
    [OPS] 0 mA / 2000 mA
    [OPS] 0 mA / 2000 mA
    [TaskMon] uptime: 00:06:08 freeHeap: 173600, largest free block: 111368, tasks: 17, mainBufferPool: 464
    [OPS] 0 mA / 2000 mA
    Assertion failed in file lib/OpenMRNLite/src/utils/Singleton.hxx line 78: assert(instance_ != nullptr)
    assertion "0" failed: file "lib/OpenMRNLite/src/utils/Singleton.hxx", line 78, function: static T* Singleton<T>::instance()
    [with T = dcc::SimpleUpdateLoop]
    abort() was called at PC 0x4018a8e3 on core 0
    E (5303) esp_apptrace: Application tracing via TRAX is disabled in menuconfig!

    ELF file SHA256: 0000000000000000000000000000000000000000000000000000000000000000

    Backtrace: 0x40086f1d:0x3ffc4990 0x400871ad:0x3ffc49b0 0x4018a8e3:0x3ffc49d0 0x400e45dd:0x3ffc4a00 0x400e4704:0x3ffc4a20 0x401017a1:0x3ffc4a50 0x401017c9:0x3ffc4a70 0x401a3863:0x3ffc4a90 0x401a38a5:0x3ffc4ab0 0x40121c0d:0x3ffc4ad0 0x40100232:0x3ffc4b00 0x4010736b:0x3ffc4b30 0x40106fcf:0x3ffc4b60 0x400eacec:0x3ffc4b90 0x4013e284:0x3ffc4e50 0x4008c4b1:0x3ffc4e70

    E (5350) esp_apptrace: Application tracing via TRAX is disabled in menuconfig!
    Rebooting...
    ets Jun 8 2016 00:22:57

    rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
    configsip: 0, SPIWP:0xee
    clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
    mode:DIO, clock div:2
    load:0x3fff0018,len:4
    load:0x3fff001c,len:5556
    load:0x40078000,len:10104
    load:0x40080400,len:6504
    entry 0x40080754
    I (29) boot: ESP-IDF 3.30300.190916 2nd stage bootloader
    I (29) boot: compile time 13:48:20
    I (38) boot: Enabling RNG early entropy source...
    I (38) boot: SPI Speed : 40MHz
    I (38) boot: SPI Mode : DIO
    I (38) boot: SPI Flash Size : 4MB
    I (41) boot: Partition Table:
    I (43) boot: ## Label Usage Type ST Offset Length
    I (50) boot: 0 nvs WiFi data 01 02 00009000 00005000
    I (56) boot: 1 otadata OTA data 01 00 0000e000 00002000
    I (63) boot: 2 ota_0 OTA app 00 10 00010000 00190000
    I (69) boot: 3 ota_1 OTA app 00 11 001a0000 00190000
    I (76) boot: 4 spiffs Unknown data 01 82 00330000 000d0000
    I (82) boot: End of partition table
    I (86) esp_image: segment 0: paddr=0x00010020 vaddr=0x3f400020 size=0x6061c (394780) map
    I (227) esp_image: segment 1: paddr=0x00070644 vaddr=0x3ffb0000 size=0x0348c ( 13452) load
    I (232) esp_image: segment 2: paddr=0x00073ad8 vaddr=0x40080000 size=0x00400 ( 1024) load
    I (233) esp_image: segment 3: paddr=0x00073ee0 vaddr=0x40080400 size=0x0c130 ( 49456) load
    I (259) esp_image: segment 4: paddr=0x00080018 vaddr=0x400d0018 size=0xd5138 (872760) map
    I (554) esp_image: segment 5: paddr=0x00155158 vaddr=0x4008c530 size=0x04a48 ( 19016) load
    I (572) boot: Loaded app from partition at offset 0x10000
    I (572) boot: Disabling RNG early entropy source...
    ESP32 Command Station v1.5.0 starting up (from ota_0)..
     
  7. Atani

    Atani TrainBoard Member

    1,460
    1,697
    36
    It looks like there is a bug in the nextion code on the development branch. I'll dig into it later today and see if I can fix it up.

    Sent from my ONEPLUS A5010 using Tapatalk
     
  8. ghruei

    ghruei TrainBoard Member

    33
    6
    2
    Great, thanks. It is only the "stop" which does this, the off button does not.
    I am also getting:
    [Nextion] Display of page 1 was not successful.
    [Nextion] Display of page 2 was not successful.

    Which is coming from the \src\Interfaces\nextion\NextionInterfaceBasePage.cpp but can not see why this is being generated as the page is being displayed.

    One final thing which I need to look into is I am testing with 3 8pin decoders, a hornby, laisdcc and a Digital Plus Lokdecoder. Of the three only 1 works with the system which is a bit odd. That is going be for another day.
     
  9. Atani

    Atani TrainBoard Member

    1,460
    1,697
    36
    Likely stop is wired up to the wrong code path. I'll dig into that and see what I can come up with.

    Sent from my ONEPLUS A5010 using Tapatalk
     
  10. Atani

    Atani TrainBoard Member

    1,460
    1,697
    36
    This is a bug in the NeoNextion lib in that it is not processing the serial stream correctly. I'm still working on fixing this up after shifting to a new approach for handling the Nextion interface. The interface code needs a bit of rework to fit into the StateFlow model and I haven't gotten through all of that yet as it is a huge change from the current approach.

    I've pushed an update this morning that should fix this issue. I didn't get a chance to test it fully but it should be reproducible also from the web interface as well. I'll be looking further into this soon to ensure there are no other asserts like this happening.
     
  11. John Flanagan

    John Flanagan TrainBoard Member

    45
    6
    7
    Without the fix the abort is reproducible from the web interface.

    0x40088255: invoke_abort at C:\users\john\.platformio\packages\framework-espidf\components\esp32\panic.c line 156
    0x400884e5: abort at C:\users\john\.platformio\packages\framework-espidf\components\esp32\panic.c line 171
    0x4018828f: __assert_func at ../../../.././newlib/libc/stdlib/assert.c line 63
    0x400e41a1: Singleton::instance() at lib/OpenMRNLite/src/utils/Singleton.hxx line 78
    0x400e42c8: esp32cs::EStopHandler::set_state(bool) at lib/OpenMRNLite/src/utils/Singleton.hxx line 78
    0x400f23dd: EStopCommand::process(std::vector, std::allocator >, std::allocator, std::allocator > > >) at src\Interfaces\DCCppProtocol.cpp line 231
    0x400f2d14: DCCPPProtocolHandler::process(std::__cxx11::basic_string, std::allocator > const&) at src\Interfaces\DCCppProtocol.cpp line 806
    0x400f2ec9: DCCPPProtocolConsumer::processData[abi:cxx11]() at src\Interfaces\DCCppProtocol.cpp line 872
    0x400f2f70: DCCPPProtocolConsumer::feed[abi:cxx11](unsigned char*, unsigned int) at src\Interfaces\DCCppProtocol.cpp line 853
    0x400f564c: process_websocket_event(esp32cs::http::WebSocketFlow*, esp32cs::http::WebSocketEvent, unsigned char const*, unsigned int) at src\Interfaces\WebServer.cpp line 216
    0x4019fd79: std::_Function_handler::_M_invoke(std::_Any_data const&, esp32cs::http::WebSocketFlow*&&, esp32cs::http::WebSocketEvent&&, unsigned char*&&, unsigned int&&) at c:\users\john\.platformio\packages\toolchain-xtensa32\xtensa-esp32-elf\include\c++\5.2.0/functional line 1871
    0x400fc39a: std::function::eek:perator()(esp32cs::http::WebSocketFlow*, esp32cs::http::WebSocketEvent, unsigned char*, unsigned int) const at c:\users\john\.platformio\packages\toolchain-xtensa32\xtensa-esp32-elf\include\c++\5.2.0/functional line 2271
    0x400fc4e2: esp32cs::http::WebSocketFlow::recv_frame_data() at src\Interfaces\http\HttpRequestWebSocket.cpp line 313
    0x40105d6f: StateFlowBase::run() at lib\OpenMRNLite\src\executor\StateFlow.cpp line 63
    0x401059d3: ExecutorBase::entry() at lib\OpenMRNLite\src\executor\Executor.cpp line 322
    0x4019ff79: OSThread::start(void*) at lib/OpenMRNLite/src/os/OS.hxx line 193
    0x401133b7: os_thread_start at lib\OpenMRNLite\src\os\os.c line 391
    0x4008cac5: vPortTaskWrapper at C:\users\john\.platformio\packages\framework-espidf\components\freertos\port.c line 143

    With the latest changes and probably a few just a bit back to get everything up to date:

    Incoming connection from 10.0.1.16, fd 55.
    [WS 0.0.0.0/55] Connected
    [OPS] 0 mA / 2000 mA
    [WebSocket fd:55] read-error, disconnecting
    [WS 0.0.0.0/55] Disconnected
    [WebSocket fd:55] Disconnected
    Guru Meditation Error: Core 1 panic'ed (InstrFetchProhibited). Exception was unhandled.
    Core 1 register dump:
    PC : 0x00000000 PS : 0x00060730 A0 : 0x8008cac8 A1 : 0x3ffd4620
    A2 : 0x00000000 A3 : 0x00000000 A4 : 0x00060023 A5 : 0x00000011
    A6 : 0x7fffffff A7 : 0x3ffb8040 A8 : 0x80142de5 A9 : 0x3f445250
    A10 : 0x3ffe2350 A11 : 0x3ffd4620 A12 : 0x3ffb7dd0 A13 : 0x3ffb7dd0
    A14 : 0x3ffb7dcc A15 : 0x3ffb7dcc SAR : 0x00000019 EXCCAUSE: 0x00000014
    EXCVADDR: 0x00000000 LBEG : 0x4000c2e0 LEND : 0x4000c2f6 LCOUNT : 0xffffffff

    ELF file SHA256: 0000000000000000000000000000000000000000000000000000000000000000

    Backtrace: 0x00000000:0x3ffd4620 0x4008cac5:0x3ffd4650

    Traceback:

    PC: 0x00000000
    EXCVADDR: 0x00000000

    Decoding stack results
    0x4008cac5: vPortTaskWrapper at C:\users\john\.platformio\packages\framework-espidf\components\freertos\port.c line 143
     
  12. Atani

    Atani TrainBoard Member

    1,460
    1,697
    36
    Thanks for confirming and capturing the backtrace. It looks to be an inheritance problem of sorts, the class being invoked as Singleton is dcc::SimpleUpdateLoop which does not directly extend from Singleton but dcc::UpdateLoopBase does.

    Hmm, there seems to be a bug here still. The WS should not be disconnecting unless there is a protocol level error (entirely possible) or the browser tab/window is closed. The backtrace is not very useful as the code has tried to invoke a null value as a function pointer which is the reason for the crash. I'll see if I can reproduce this and get to the bottom of it.
     
  13. NormHal

    NormHal TrainBoard Member

    138
    126
    12
    Hi guys, Norm here.... Remember me? :)))

    After a fairly extensive excursion into the world of Z21 and Nextion, I'm back, having picked up a few observations... More if you're interested:)

    To get back in the groove, I downloaded your latest Mike, compiled and flashed and all seems good. I had initially compiled under Windows, and for some reason the Serial Monitor/console yielded no messages at all. I reverted to Linux, and now the messages are flowing:)

    It's always refreshing to get a clean compile, and a first-time stable execution - I get the feeling you've been very busy Mike:)

    All-in-all, so far my limited playing has been very positive. As you might expect, I compiled with only the Nextion support enabled (apart from all the defaults), so my focus is currently on the Nextion interface. My initial findings are that "everything" works:). The one question relates to the identification of the Nextion display model. When the model is not identified, the response on the display is veeeerrry slow. IIRC, you felt it could be an issue with timing?

    All-in-all, I hope to be back in the testing seat for a while - the z21 excursion has been very successful:). Your steady and on-going efforts are admirable, Mike:)
     
  14. Atani

    Atani TrainBoard Member

    1,460
    1,697
    36
    Welcome back! I'm interested in the Z21 side of things mostly as I was exploring it as a possible integration point but couldn't find enough information on how it all works. Though now with LCC being the primary interface it likely would be better suited as integrated via a bridge node instead (similar for LocoNet).

    Glad to know that the current "dev" code works well for you. It is odd that the Serial output was not working on Windows, I do all of my dev work on Windows and it seems to work well for me typically. There are a few bugs for certain that need to be resolved still though.

    The problem with the Nextion type detection is due to how the code is written today, it does not treat the UART as a streaming device which could return a short read rather than the full block requested. So it is not always successful in reading the response from the Nextion. Complicating things a bit further is the nature of the UART flush having a few bugs in the esp32 itself.
     
  15. Atani

    Atani TrainBoard Member

    1,460
    1,697
    36
    I've just received the v1.1 PCBs and will be doing some testing on them this coming weekend. I've test fit a couple of the components that were problematic in the v1.0 PCB and so far it looks good.

    IMG_20191127_120612.jpg

    In this shot you can see the TTGO T1 ESP32, I2C and UART connections. So far everything fits where it should and there doesn't seem to be any clearance issues. As long as nothing major comes up I'll only be adjusting the silk screen for v1.2 of the PCB (which will only be produced after this batch of PCBs have been exhausted or there is a critical flaw on this one).

    Price for the kit is still TBD but it is currently in the $35-40 range which will get you up and running with only adding a power supply, an SD card would be recommended still for long term storage of CS data and ease of configuration/upgrades.
     
    bocabob likes this.
  16. crusader27529

    crusader27529 TrainBoard Member

    247
    167
    11
    Good news.......take as long as you need, no need to hurry.

    How many of the kits have been spoken for, or basically, how much interest has been generated? Obviously, if anyone is interested and wants to use multiple power districts, I can help them.
     
  17. Atani

    Atani TrainBoard Member

    1,460
    1,697
    36
    Of the original 10 kits that I had ordered parts for initially I want to say all but one or two were reserved. I have 20 of these PCBs on hand and I will be using one or two for my own testing but the remaining will be available for the kits, provided there are no major issues on the PCB (silk screen issue is minor, bottom side is missing two markers for 5V and GND). There is more interested parties out there for these PCBs than I have on hand now likely, especially since it will be basically a ready-to-run CS (after assembling kit).

    As for multiple power districts, that can be done but there will be issues with RailCom feedback which I'm working on resolving still. That will require a few modifications to the PCB to connect the current sense to the CS so it can read in parallel with the OPs track RC inputs.
     
  18. Curn

    Curn TrainBoard Member

    751
    497
    31
    Oh, I’ll take one. I didn’t realize reservations were open.
     
  19. Keith Ledbetter

    Keith Ledbetter TrainBoard Member

    279
    195
    12
    Happy Thanksgiving everyone. Atani I'll definitely take 2 when ready to go.
     
  20. Dex

    Dex TrainBoard Member

    55
    30
    5
    I would take one as well
     

Share This Page