Hi I guess this question is basically for Mark, In Norway the telecom providers have decided to turn off almost all of the 3G network soon and focus on 4G only. Any plan for 4G modem? Kind regards, Stein Arne Sordal
I heard that Telenor is planning to shutdown 3G in 2020, but will keep their 2G network up for another five years? Our current SIM5360 based modules support both 2G and 3G. We really don’t need the bandwidth. Anyway, regarding 4G, how about this: Very easy to make. Our current modem circuit board layout actually supports both the SIM5360 (3G) and SIM7100 (4G) SIMCOM modules; we can simply drop in the appropriate module during production, and build with either 3G or 4G. If there is demand, we can satisfy within weeks. However, the SIM7100 modules are almost twice the price of the SIM5360 (which were already six times the price of the old SIM900). I am also concerned because 4G LTE NB-IoT is coming soon, and that seems a much better match for what we require (SIM7000 module). Overall, we decided to stay with 3G (+2G quad band support) for the moment, and see what happens with NB-IoT later this year. We will then either release SIM7000 or SIM7100 modem option. Regards, Mark.
On 13 Jun 2018, at 3:18 AM, Stein Arne Sordal <ovms@topphemmelig.no> wrote:
Hi
I guess this question is basically for Mark,
In Norway the telecom providers have decided to turn off almost all of the 3G network soon and focus on 4G only. Any plan for 4G modem?
Kind regards, Stein Arne Sordal
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
I agree, LTE NB-IoT is very interesting. Some students at the university where I work is currently testing fleet-managment over LTE NB-IoT. I will se how the coverage/quality evolves. Regards, Stein Arne
On 13 Jun 2018, at 02:26, Mark Webb-Johnson <mark@openvehicles.com> wrote:
I heard that Telenor is planning to shutdown 3G in 2020, but will keep their 2G network up for another five years? Our current SIM5360 based modules support both 2G and 3G. We really don’t need the bandwidth.
Anyway, regarding 4G, how about this:
<PastedGraphic-2.tiff> <PastedGraphic-4.tiff>
Very easy to make. Our current modem circuit board layout actually supports both the SIM5360 (3G) and SIM7100 (4G) SIMCOM modules; we can simply drop in the appropriate module during production, and build with either 3G or 4G. If there is demand, we can satisfy within weeks.
However, the SIM7100 modules are almost twice the price of the SIM5360 (which were already six times the price of the old SIM900). I am also concerned because 4G LTE NB-IoT is coming soon, and that seems a much better match for what we require (SIM7000 module).
Overall, we decided to stay with 3G (+2G quad band support) for the moment, and see what happens with NB-IoT later this year. We will then either release SIM7000 or SIM7100 modem option.
Regards, Mark.
On 13 Jun 2018, at 3:18 AM, Stein Arne Sordal <ovms@topphemmelig.no <mailto:ovms@topphemmelig.no>> wrote:
Hi
I guess this question is basically for Mark,
In Norway the telecom providers have decided to turn off almost all of the 3G network soon and focus on 4G only. Any plan for 4G modem?
Kind regards, Stein Arne Sordal
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
What I wonder is how is it able to cope with high-speed moving assets. The narrow-band and very low data rate might make it prone to frequency deviation due to Doppler effect. (It’s something that happens on the Sigfox network with anything faster than a bike ;-) ) What I am even more worried about is how will it be adopted by cell operators: They might be few to do so, and reserve it to pure M2M applications for businesses (and at a price, Orange(FR) does it for a MOQ of 100s of SIMs, 5€/month/sim + 5€/MB) Anyways, and again, the modular OVMSv3 will offer plenty of options to choose from (LoRA !!!!, though this moves it away from TCP based services) JB./. On 13 Jun 2018 at 08:58 +0200, Stein Arne Sordal <ovms@topphemmelig.no>, wrote:
I agree,
LTE NB-IoT is very interesting. Some students at the university where I work is currently testing fleet-managment over LTE NB-IoT. I will se how the coverage/quality evolves.
Regards, Stein Arne
FYI: The Hologram SIMs we use are supposedly NB-IoT enabled. They should work so long as the base network supports it. Just too early to know for sure at the moment. Time will tell. Regards, Mark.
On 13 Jun 2018, at 3:13 PM, Julien “JaXX” Banchet <jaxx@jaxx.org> wrote:
What I wonder is how is it able to cope with high-speed moving assets. The narrow-band and very low data rate might make it prone to frequency deviation due to Doppler effect. (It’s something that happens on the Sigfox network with anything faster than a bike ;-) )
What I am even more worried about is how will it be adopted by cell operators: They might be few to do so, and reserve it to pure M2M applications for businesses (and at a price, Orange(FR) does it for a MOQ of 100s of SIMs, 5€/month/sim + 5€/MB)
Anyways, and again, the modular OVMSv3 will offer plenty of options to choose from (LoRA !!!!, though this moves it away from TCP based services)
JB./.
On 13 Jun 2018 at 08:58 +0200, Stein Arne Sordal <ovms@topphemmelig.no>, wrote:
I agree,
LTE NB-IoT is very interesting. Some students at the university where I work is currently testing fleet-managment over LTE NB-IoT. I will se how the coverage/quality evolves.
Regards, Stein Arne
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
On 2018-06-12 15:26, Mark Webb-Johnson wrote:
Very easy to make. Our current modem circuit board layout actually supports both the SIM5360 (3G) and SIM7100 (4G) SIMCOM modules; we can simply drop in the appropriate module during production, and build with either 3G or 4G. If there is demand, we can satisfy within weeks What is my easiest path to getting a small quantity of ovms modem cards with SIM7100A modems? I probably only need 3, should I just buy some SIM5360A ovms boards and swap the simcom modules? And I guess move or add an antenna connector? I've attached a png version of a image from the message I'm replying to. It shows the SIM5360A using ANT1 and ANT3 while the SIM7100E uses ANT1 and ANT2 (and I see now the silkscreen documents this difference).
Craig
Craig, Our modem design was loosely based on some suggestions from SIMCOM. Like: https://simcom.ee/documents/SIM7100E/SIM7100_SIM5360_SIM800C%20Compatible%20... <https://simcom.ee/documents/SIM7100E/SIM7100_SIM5360_SIM800C%20Compatible%20Design_V1.01.pdf> I did get a SIM7100 module a year or two ago, and did some basic testing with it, but cost was just too high at that time. I will ask again to see where we are today. A quick check on aliexpress shows the SIM7100E at US$50 per module, and SIM5360E at US$20, in quantities of 1. My main concern is software support. On paper, the SIM7100 looks compatible, and the AT commands very close. But the same was true of the SIM7000 I tried, and that was a mess - it seems the first firmware didn’t even support the MUX mode we rely on. Given all the passive components required, it is probably easiest to just use a SIM5360 board, unsolder the modem module and replace it, then add / move that one antenna. To get my china contacts to make 3 one off boards is probably about the same price. In general, it is easy to get 1 or 1,000, but quantities in between are the issue. Regards, Mark.
On 21 Jun 2019, at 12:49 AM, Craig Leres <leres@xse.com> wrote:
On 2018-06-12 15:26, Mark Webb-Johnson wrote:
Very easy to make. Our current modem circuit board layout actually supports both the SIM5360 (3G) and SIM7100 (4G) SIMCOM modules; we can simply drop in the appropriate module during production, and build with either 3G or 4G. If there is demand, we can satisfy within weeks What is my easiest path to getting a small quantity of ovms modem cards with SIM7100A modems? I probably only need 3, should I just buy some SIM5360A ovms boards and swap the simcom modules? And I guess move or add an antenna connector? I've attached a png version of a image from the message I'm replying to. It shows the SIM5360A using ANT1 and ANT3 while the SIM7100E uses ANT1 and ANT2 (and I see now the silkscreen documents this difference).
Craig <PastedGraphic-2.png>
FYI: SIMCOM is now recommending SIM7600. That is closer in price to SIM5360 and is supposedly pin-for-pin compatible with SIM7100 and SIM5360. I will get one sample made and try it. Regards, Mark.
On 21 Jun 2019, at 7:23 PM, Mark Webb-Johnson <mark@openvehicles.com> wrote:
Craig,
Our modem design was loosely based on some suggestions from SIMCOM. Like:
https://simcom.ee/documents/SIM7100E/SIM7100_SIM5360_SIM800C%20Compatible%20... <https://simcom.ee/documents/SIM7100E/SIM7100_SIM5360_SIM800C%20Compatible%20Design_V1.01.pdf>
I did get a SIM7100 module a year or two ago, and did some basic testing with it, but cost was just too high at that time. I will ask again to see where we are today. A quick check on aliexpress shows the SIM7100E at US$50 per module, and SIM5360E at US$20, in quantities of 1.
My main concern is software support. On paper, the SIM7100 looks compatible, and the AT commands very close. But the same was true of the SIM7000 I tried, and that was a mess - it seems the first firmware didn’t even support the MUX mode we rely on.
Given all the passive components required, it is probably easiest to just use a SIM5360 board, unsolder the modem module and replace it, then add / move that one antenna. To get my china contacts to make 3 one off boards is probably about the same price. In general, it is easy to get 1 or 1,000, but quantities in between are the issue.
Regards, Mark.
On 21 Jun 2019, at 12:49 AM, Craig Leres <leres@xse.com <mailto:leres@xse.com>> wrote:
On 2018-06-12 15:26, Mark Webb-Johnson wrote:
Very easy to make. Our current modem circuit board layout actually supports both the SIM5360 (3G) and SIM7100 (4G) SIMCOM modules; we can simply drop in the appropriate module during production, and build with either 3G or 4G. If there is demand, we can satisfy within weeks What is my easiest path to getting a small quantity of ovms modem cards with SIM7100A modems? I probably only need 3, should I just buy some SIM5360A ovms boards and swap the simcom modules? And I guess move or add an antenna connector? I've attached a png version of a image from the message I'm replying to. It shows the SIM5360A using ANT1 and ANT3 while the SIM7100E uses ANT1 and ANT2 (and I see now the silkscreen documents this difference).
Craig <PastedGraphic-2.png>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
I got a sample. Physically and electrically, it is pretty much a drop in replacement for the SIM5360. But, the firmware (and AT commands) are different. V (69794) simcom: rx: 0a 4f 4b 0d 0a | .OK.. D (69794) simcom: rx line ch=0 len=2 : OK V (71754) simcom: tx: 41 54 2b 43 47 4d 52 3b 2b 49 43 43 49 44 0d 0a | AT+CGMR;+ICCID.. D (71754) simcom: tx scmd ch=0 len=16 : AT+CGMR;+ICCID V (71764) simcom: rx: 0d 0a 2b 43 47 4d 52 3a 20 4c 45 31 31 42 30 32 | ..+CGMR: LE11B02 V (71764) simcom: rx: 53 49 4d 37 36 30 30 4d 32 31 2d 41 0d 0a 0d 0a | SIM7600M21-A.... D (71774) simcom: rx line ch=0 len=26 : +CGMR: LE11B02SIM7600M21-A (redacted) V (71774) simcom: rx: 4b 0d 0a | K.. D (71774) simcom: rx line ch=0 len=2 : OK V (74754) simcom: tx: 41 54 2b 43 4f 50 53 3f | AT+COPS? D (74754) simcom: tx scmd ch=0 len=8 : AT+COPS? OVMS# metrics list mdm m.net.mdm.iccid (redacted) m.net.mdm.model LE11B02SIM7600M21-A V (75754) simcom: tx: 41 54 2b 43 4d 55 58 53 52 56 50 4f 52 54 3d 33 | AT+CMUXSRVPORT=3 V (75754) simcom: tx: 2c 31 0d 0a | ,1.. D (75754) simcom: tx scmd ch=0 len=20 : AT+CMUXSRVPORT=3,1 V (75764) simcom: rx: 0d 0a 45 52 52 4f 52 0d 0a | ..ERROR.. D (75764) simcom: rx line ch=0 len=5 : ERROR V (76754) simcom: tx: 41 54 2b 43 4d 55 58 53 52 56 50 4f 52 54 3d 32 | AT+CMUXSRVPORT=2 V (76754) simcom: tx: 2c 31 0d 0a | ,1.. D (76754) simcom: tx scmd ch=0 len=20 : AT+CMUXSRVPORT=2,1 V (76764) simcom: rx: 0d 0a 45 52 52 4f 52 0d 0a | ..ERROR.. D (76764) simcom: rx line ch=0 len=5 : ERROR V (77754) simcom: tx: 41 54 2b 43 4d 55 58 53 52 56 50 4f 52 54 3d 31 | AT+CMUXSRVPORT=1 V (77754) simcom: tx: 2c 31 0d 0a | ,1.. D (77754) simcom: tx scmd ch=0 len=20 : AT+CMUXSRVPORT=1,1 V (77764) simcom: rx: 0d 0a 45 52 52 4f 52 0d 0a | ..ERROR.. D (77764) simcom: rx line ch=0 len=5 : ERROR V (78754) simcom: tx: 41 54 2b 43 4d 55 58 53 52 56 50 4f 52 54 3d 30 | AT+CMUXSRVPORT=0 V (78754) simcom: tx: 2c 35 0d 0a | ,5.. D (78754) simcom: tx scmd ch=0 len=20 : AT+CMUXSRVPORT=0,5 V (78764) simcom: rx: 0d 0a 45 52 52 4f 52 0d 0a | ..ERROR.. D (78764) simcom: rx line ch=0 len=5 : ERROR V (79754) simcom: tx: 41 54 2b 43 4d 55 58 3d 30 0d 0a | AT+CMUX=0.. D (79754) simcom: tx scmd ch=0 len=11 : AT+CMUX=0 Then it resets, as our firmware interprets that as a CMUX failure. I did manage to type manual commands and get a 4G LTE connection established. It seems that the AT+CMUXSRVPORT commands are no longer support (necessary?). Also forcing a ’simcom setstate MuxStart’ at the appropriate time (just after " AT+CMUXSRVPORT=0”) gives us: D (713784) simcom: rx line ch=2 len=14 : CONNECT 115200 I (713784) simcom: PPP Connection is ready to start I (714754) simcom: State: Enter NetMode state I (714754) gsm-ppp: Initialising… I (714944) gsm-ppp: StatusCallBack: None I (714944) gsm-ppp: status_cb: Connected I (714944) gsm-ppp: our_ipaddr = 10.170.204.16 I (714944) gsm-ppp: his_ipaddr = 10.64.64.64 I (714944) gsm-ppp: netmask = 255.255.255.255 I (714944) gsm-ppp: our6_ipaddr = :: D (714944) events: Signal(network.interface.up) D (714964) events: Signal(system.modem.gotip) D (714964) netmanager: Saved DNS#0 212.9.0.135 D (714964) netmanager: Saved DNS#1 212.9.0.136 D (714984) events: Signal(network.modem.up) D (715004) events: Signal(network.interface.change) OVMS# simcom muxtx 3 AT+CPSI? V (1159254) simcom: mux tx: 41 54 2b 43 50 53 49 3f 0d 0a | AT+CPSI?.. D (1159254) simcom: tx mcmd ch=3 len=10 : AT+CPSI? V (1159254) simcom: tx: f9 0d ff 15 41 54 2b 43 50 53 49 3f 0d 0a 1d f9 | ....AT+CPSI?.... V (1159384) simcom: rx: f9 0d ff b1 0d 0a 2b 43 50 53 49 3a 20 4c 54 45 | ......+CPSI: LTE V (1159384) simcom: rx: 2c 4f 6e 6c 69 6e 65 2c 34 35 34 2d 30 30 2c 30 | ,Online,454-00,0 V (1159394) simcom: rx: 78 30 34 35 38 2c 32 37 32 39 37 36 36 39 2c 34 | x0458,27297669,4 V (1159394) simcom: rx: 34 36 2c 45 55 54 52 41 4e 2d 42 41 4e 44 37 2c | 46,EUTRAN-BAND7, V (1159394) simcom: rx: 33 31 35 30 2c 35 2c 35 2c 2d 31 32 35 2c 2d 39 | 3150,5,5,-125,-9 V (1159394) simcom: rx: 35 33 2c 2d 36 32 39 2c 31 31 0d 0a c2 f9 f9 0d | 53,-629,11…… OVMS# simcom muxtx 3 AT+CNSMOD? V (1221734) simcom: mux tx: 41 54 2b 43 4e 53 4d 4f 44 3f 0d 0a | AT+CNSMOD?.. D (1221734) simcom: tx mcmd ch=3 len=12 : AT+CNSMOD? V (1221734) simcom: tx: f9 0d ff 19 41 54 2b 43 4e 53 4d 4f 44 3f 0d 0a | ....AT+CNSMOD?.. V (1221734) simcom: tx: 14 f9 | .. V (1221744) simcom: rx: f9 0d ff 2d 0d 0a 2b 43 4e 53 4d 4f 44 3a 20 30 | ...-..+CNSMOD: 0 V (1221744) simcom: rx: 2c 38 0d 0a 0d 0a 4f 4b 0d 0a 37 f9 | ,8....OK..7. It is going to take some work to get this compatible (but doesn’t look too hard). Pricing is still higher than SIM5360, global LTE bands painful to support, and certification would be more hassle, but it seems at least worth trying to get it supported as an option. Regards, Mark.
On 22 Jun 2019, at 1:41 PM, Mark Webb-Johnson <mark@openvehicles.com> wrote:
FYI: SIMCOM is now recommending SIM7600. That is closer in price to SIM5360 and is supposedly pin-for-pin compatible with SIM7100 and SIM5360. I will get one sample made and try it.
Regards, Mark.
On 21 Jun 2019, at 7:23 PM, Mark Webb-Johnson <mark@openvehicles.com <mailto:mark@openvehicles.com>> wrote:
Craig,
Our modem design was loosely based on some suggestions from SIMCOM. Like:
https://simcom.ee/documents/SIM7100E/SIM7100_SIM5360_SIM800C%20Compatible%20... <https://simcom.ee/documents/SIM7100E/SIM7100_SIM5360_SIM800C%20Compatible%20Design_V1.01.pdf>
I did get a SIM7100 module a year or two ago, and did some basic testing with it, but cost was just too high at that time. I will ask again to see where we are today. A quick check on aliexpress shows the SIM7100E at US$50 per module, and SIM5360E at US$20, in quantities of 1.
My main concern is software support. On paper, the SIM7100 looks compatible, and the AT commands very close. But the same was true of the SIM7000 I tried, and that was a mess - it seems the first firmware didn’t even support the MUX mode we rely on.
Given all the passive components required, it is probably easiest to just use a SIM5360 board, unsolder the modem module and replace it, then add / move that one antenna. To get my china contacts to make 3 one off boards is probably about the same price. In general, it is easy to get 1 or 1,000, but quantities in between are the issue.
Regards, Mark.
On 21 Jun 2019, at 12:49 AM, Craig Leres <leres@xse.com <mailto:leres@xse.com>> wrote:
On 2018-06-12 15:26, Mark Webb-Johnson wrote:
Very easy to make. Our current modem circuit board layout actually supports both the SIM5360 (3G) and SIM7100 (4G) SIMCOM modules; we can simply drop in the appropriate module during production, and build with either 3G or 4G. If there is demand, we can satisfy within weeks What is my easiest path to getting a small quantity of ovms modem cards with SIM7100A modems? I probably only need 3, should I just buy some SIM5360A ovms boards and swap the simcom modules? And I guess move or add an antenna connector? I've attached a png version of a image from the message I'm replying to. It shows the SIM5360A using ANT1 and ANT3 while the SIM7100E uses ANT1 and ANT2 (and I see now the silkscreen documents this difference).
Craig <PastedGraphic-2.png>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
I've been running a v3.1 module in my Cadillac for a few weeks now and recently realized that it crashes frequently. I see this on the status page: Last boot was 12879 second(s) ago Time at boot: 2019-06-26 11:31:51 PDT This is reset #10 since last power cycle Detected boot reason: Crash (8/14) Crash counters: 8 total, 0 early Last crash: abort() was called on core 0 Backtrace: 0x40096068 0x40096263 0x40115aa7 0x40232e95 0x4023312d 0x4023315d 0x40229d52 0x4022a780 0x40226576 0x402276d6 0x40227ad1 Version: 3.2.002-89-g0207c45e-dirty/ota_0/main (build idf v3.1-dev-2835-g151269458 Jun 22 2019 14:12:19) Firmware: 3.2.002-89-g0207c45e-dirty/ota_0/main (build idf v3.1-dev-2835-g151269458 Jun 22 2019 14:12:19) Running partition: ota_0 Boot partition: ota_0 Factory image: 3.2.002 OTA_O image: 3.2.002-89-g0207c45e-dirty OTA_1 image: 3.2.002-89-g0207c45e-dirty Which translates to: + xtensa-esp32-elf-addr2line -e build/ovms3.elf 0x40096068 0x40096263 0x40115aa7 0x40232e95 0x4023312d 0x4023315d 0x40229d52 0x4022a780 0x40226576 0x402276d6 0x40227ad1 /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/esp32/panic.c:670 /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/esp32/panic.c:670 /home/jeroen/esp8266/esp32/newlib_xtensa-2.2.0-bin/newlib_xtensa-2.2.0/xtensa-esp32-elf/newlib/libc/stdlib/../../../.././newlib/libc/stdlib/assert.c:63 (discriminator 8) /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/lwip/core/ipv4/ip4.c:846 (discriminator 1) /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/lwip/core/ipv4/ip4.c:810 /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/lwip/core/ipv4/ip4.c:787 /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/lwip/core/tcp_out.c:1272 (discriminator 4) /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/lwip/core/tcp_out.c:1073 /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/lwip/api/api_msg.c:1875 (discriminator 6) /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/lwip/api/api_msg.c:1875 (discriminator 6) /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/lwip/api/tcpip.c:474 I was beginning to think that my battery tender maintenance charger was the cause but I disconnected it a few days ago. Is this psram cache issue related or something else? I haven't written much code yet and it doesn't do a lot, especially when the car is off. Is there an easy way to poll the module for crash related info? I never understood what the boot reason numbers were: Detected boot reason: Crash (8/14) but I see now that there is a number for each core and are defined in the esp-idf/components/esp32/include/rom/rtc.h: typedef enum { NO_MEAN = 0, POWERON_RESET = 1, /**<1, Vbat power on reset*/ SW_RESET = 3, /**<3, Software reset digital core*/ OWDT_RESET = 4, /**<4, Legacy watch dog reset digital core*/ DEEPSLEEP_RESET = 5, /**<3, Deep Sleep reset digital core*/ SDIO_RESET = 6, /**<6, Reset by SLC module, reset digital core*/ TG0WDT_SYS_RESET = 7, /**<7, Timer Group0 Watch dog reset digital core*/ TG1WDT_SYS_RESET = 8, /**<8, Timer Group1 Watch dog reset digital core*/ RTCWDT_SYS_RESET = 9, /**<9, RTC Watch dog Reset digital core*/ INTRUSION_RESET = 10, /**<10, Instrusion tested to reset CPU*/ TGWDT_CPU_RESET = 11, /**<11, Time Group reset CPU*/ SW_CPU_RESET = 12, /**<12, Software reset CPU*/ RTCWDT_CPU_RESET = 13, /**<13, RTC Watch dog Reset CPU*/ EXT_CPU_RESET = 14, /**<14, for APP CPU, reseted by PRO CPU*/ RTCWDT_BROWN_OUT_RESET = 15, /**<15, Reset when the vdd voltage is not stable*/ RTCWDT_RTC_RESET = 16 /**<16, RTC Watch dog reset digital core and rtc module*/ } RESET_REASON; so my most recent reset was due to 8: "Timer Group1 Watch dog reset digital core" (and the 14 is probably cpu0 resetting cpu1 when the watch dog hit?) I am using Ticker10 based on Ticker1 code I saw in vehicle_nissanleaf.cpp. But I get crashes even if I ifdef out that code out. I've also attached a screen grab from my hologram.io account, I think it's showing just how frequently the crashes are. I could also eliminate my FreeBSD xtensa toolchain by doing a build under ubuntu, would that be worthwhile? Craig
Hard to see from the logs. It certainly seems like a watchdog initiated reset, but the backtrace shows it in the ip stack. What you are seeing is not at all normal, and seems to be periodic. You can rule-out the vehicle module as the cause of the problem by simply turning off the vehicle type, so no vehicle module is loaded at startup. Then see if it still crashes. Similar for server connections (are you using v2 or v3?). Regards, Mark.
On 27 Jun 2019, at 6:31 AM, Craig Leres <leres@xse.com> wrote:
I've been running a v3.1 module in my Cadillac for a few weeks now and recently realized that it crashes frequently. I see this on the status page:
Last boot was 12879 second(s) ago Time at boot: 2019-06-26 11:31:51 PDT This is reset #10 since last power cycle Detected boot reason: Crash (8/14) Crash counters: 8 total, 0 early
Last crash: abort() was called on core 0 Backtrace: 0x40096068 0x40096263 0x40115aa7 0x40232e95 0x4023312d 0x4023315d 0x40229d52 0x4022a780 0x40226576 0x402276d6 0x40227ad1 Version: 3.2.002-89-g0207c45e-dirty/ota_0/main (build idf v3.1-dev-2835-g151269458 Jun 22 2019 14:12:19) Firmware: 3.2.002-89-g0207c45e-dirty/ota_0/main (build idf v3.1-dev-2835-g151269458 Jun 22 2019 14:12:19) Running partition: ota_0 Boot partition: ota_0 Factory image: 3.2.002 OTA_O image: 3.2.002-89-g0207c45e-dirty OTA_1 image: 3.2.002-89-g0207c45e-dirty
Which translates to:
+ xtensa-esp32-elf-addr2line -e build/ovms3.elf 0x40096068 0x40096263 0x40115aa7 0x40232e95 0x4023312d 0x4023315d 0x40229d52 0x4022a780 0x40226576 0x402276d6 0x40227ad1 /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/esp32/panic.c:670 /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/esp32/panic.c:670 /home/jeroen/esp8266/esp32/newlib_xtensa-2.2.0-bin/newlib_xtensa-2.2.0/xtensa-esp32-elf/newlib/libc/stdlib/../../../.././newlib/libc/stdlib/assert.c:63 (discriminator 8) /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/lwip/core/ipv4/ip4.c:846 (discriminator 1) /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/lwip/core/ipv4/ip4.c:810 /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/lwip/core/ipv4/ip4.c:787 /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/lwip/core/tcp_out.c:1272 (discriminator 4) /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/lwip/core/tcp_out.c:1073 /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/lwip/api/api_msg.c:1875 (discriminator 6) /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/lwip/api/api_msg.c:1875 (discriminator 6) /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/lwip/api/tcpip.c:474
I was beginning to think that my battery tender maintenance charger was the cause but I disconnected it a few days ago.
Is this psram cache issue related or something else? I haven't written much code yet and it doesn't do a lot, especially when the car is off.
Is there an easy way to poll the module for crash related info?
I never understood what the boot reason numbers were:
Detected boot reason: Crash (8/14)
but I see now that there is a number for each core and are defined in the esp-idf/components/esp32/include/rom/rtc.h:
typedef enum { NO_MEAN = 0, POWERON_RESET = 1, /**<1, Vbat power on reset*/ SW_RESET = 3, /**<3, Software reset digital core*/ OWDT_RESET = 4, /**<4, Legacy watch dog reset digital core*/ DEEPSLEEP_RESET = 5, /**<3, Deep Sleep reset digital core*/ SDIO_RESET = 6, /**<6, Reset by SLC module, reset digital core*/ TG0WDT_SYS_RESET = 7, /**<7, Timer Group0 Watch dog reset digital core*/ TG1WDT_SYS_RESET = 8, /**<8, Timer Group1 Watch dog reset digital core*/ RTCWDT_SYS_RESET = 9, /**<9, RTC Watch dog Reset digital core*/ INTRUSION_RESET = 10, /**<10, Instrusion tested to reset CPU*/ TGWDT_CPU_RESET = 11, /**<11, Time Group reset CPU*/ SW_CPU_RESET = 12, /**<12, Software reset CPU*/ RTCWDT_CPU_RESET = 13, /**<13, RTC Watch dog Reset CPU*/ EXT_CPU_RESET = 14, /**<14, for APP CPU, reseted by PRO CPU*/ RTCWDT_BROWN_OUT_RESET = 15, /**<15, Reset when the vdd voltage is not stable*/ RTCWDT_RTC_RESET = 16 /**<16, RTC Watch dog reset digital core and rtc module*/ } RESET_REASON;
so my most recent reset was due to 8: "Timer Group1 Watch dog reset digital core" (and the 14 is probably cpu0 resetting cpu1 when the watch dog hit?) I am using Ticker10 based on Ticker1 code I saw in vehicle_nissanleaf.cpp. But I get crashes even if I ifdef out that code out.
I've also attached a screen grab from my hologram.io account, I think it's showing just how frequently the crashes are.
I could also eliminate my FreeBSD xtensa toolchain by doing a build under ubuntu, would that be worthwhile?
Craig <hologram.png>_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
This type of crash is the reason I now build the edge version on dexters-web.de without CONFIG_WIFI_LWIP_ALLOCATION_FROM_SPIRAM_FIRST. It seems to reduce these crashes, but I haven't done new statistics yet. Craig, you could also try if that helps for you. Regards, Michael Am 27.06.19 um 04:11 schrieb Mark Webb-Johnson:
Hard to see from the logs. It certainly seems like a watchdog initiated reset, but the backtrace shows it in the ip stack. What you are seeing is not at all normal, and seems to be periodic.
You can rule-out the vehicle module as the cause of the problem by simply turning off the vehicle type, so no vehicle module is loaded at startup. Then see if it still crashes. Similar for server connections (are you using v2 or v3?).
Regards, Mark.
On 27 Jun 2019, at 6:31 AM, Craig Leres <leres@xse.com> wrote:
I've been running a v3.1 module in my Cadillac for a few weeks now and recently realized that it crashes frequently. I see this on the status page:
Last boot was 12879 second(s) ago Time at boot: 2019-06-26 11:31:51 PDT This is reset #10 since last power cycle Detected boot reason: Crash (8/14) Crash counters: 8 total, 0 early
Last crash: abort() was called on core 0 Backtrace: 0x40096068 0x40096263 0x40115aa7 0x40232e95 0x4023312d 0x4023315d 0x40229d52 0x4022a780 0x40226576 0x402276d6 0x40227ad1 Version: 3.2.002-89-g0207c45e-dirty/ota_0/main (build idf v3.1-dev-2835-g151269458 Jun 22 2019 14:12:19) Firmware: 3.2.002-89-g0207c45e-dirty/ota_0/main (build idf v3.1-dev-2835-g151269458 Jun 22 2019 14:12:19) Running partition: ota_0 Boot partition: ota_0 Factory image: 3.2.002 OTA_O image: 3.2.002-89-g0207c45e-dirty OTA_1 image: 3.2.002-89-g0207c45e-dirty
Which translates to:
+ xtensa-esp32-elf-addr2line -e build/ovms3.elf 0x40096068 0x40096263 0x40115aa7 0x40232e95 0x4023312d 0x4023315d 0x40229d52 0x4022a780 0x40226576 0x402276d6 0x40227ad1 /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/esp32/panic.c:670 /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/esp32/panic.c:670 /home/jeroen/esp8266/esp32/newlib_xtensa-2.2.0-bin/newlib_xtensa-2.2.0/xtensa-esp32-elf/newlib/libc/stdlib/../../../.././newlib/libc/stdlib/assert.c:63 (discriminator 8) /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/lwip/core/ipv4/ip4.c:846 (discriminator 1) /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/lwip/core/ipv4/ip4.c:810 /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/lwip/core/ipv4/ip4.c:787 /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/lwip/core/tcp_out.c:1272 (discriminator 4) /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/lwip/core/tcp_out.c:1073 /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/lwip/api/api_msg.c:1875 (discriminator 6) /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/lwip/api/api_msg.c:1875 (discriminator 6) /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/lwip/api/tcpip.c:474
I was beginning to think that my battery tender maintenance charger was the cause but I disconnected it a few days ago.
Is this psram cache issue related or something else? I haven't written much code yet and it doesn't do a lot, especially when the car is off.
Is there an easy way to poll the module for crash related info?
I never understood what the boot reason numbers were:
Detected boot reason: Crash (8/14)
but I see now that there is a number for each core and are defined in the esp-idf/components/esp32/include/rom/rtc.h:
typedef enum { NO_MEAN = 0, POWERON_RESET = 1, /**<1, Vbat power on reset*/ SW_RESET = 3, /**<3, Software reset digital core*/ OWDT_RESET = 4, /**<4, Legacy watch dog reset digital core*/ DEEPSLEEP_RESET = 5, /**<3, Deep Sleep reset digital core*/ SDIO_RESET = 6, /**<6, Reset by SLC module, reset digital core*/ TG0WDT_SYS_RESET = 7, /**<7, Timer Group0 Watch dog reset digital core*/ TG1WDT_SYS_RESET = 8, /**<8, Timer Group1 Watch dog reset digital core*/ RTCWDT_SYS_RESET = 9, /**<9, RTC Watch dog Reset digital core*/ INTRUSION_RESET = 10, /**<10, Instrusion tested to reset CPU*/ TGWDT_CPU_RESET = 11, /**<11, Time Group reset CPU*/ SW_CPU_RESET = 12, /**<12, Software reset CPU*/ RTCWDT_CPU_RESET = 13, /**<13, RTC Watch dog Reset CPU*/ EXT_CPU_RESET = 14, /**<14, for APP CPU, reseted by PRO CPU*/ RTCWDT_BROWN_OUT_RESET = 15, /**<15, Reset when the vdd voltage is not stable*/ RTCWDT_RTC_RESET = 16 /**<16, RTC Watch dog reset digital core and rtc module*/ } RESET_REASON;
so my most recent reset was due to 8: "Timer Group1 Watch dog reset digital core" (and the 14 is probably cpu0 resetting cpu1 when the watch dog hit?) I am using Ticker10 based on Ticker1 code I saw in vehicle_nissanleaf.cpp. But I get crashes even if I ifdef out that code out.
I've also attached a screen grab from my hologram.io account, I think it's showing just how frequently the crashes are.
I could also eliminate my FreeBSD xtensa toolchain by doing a build under ubuntu, would that be worthwhile?
Craig <hologram.png>_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
On 2019-06-26 17:11, Mark Webb-Johnson wrote:
You can rule-out the vehicle module as the cause of the problem by simply turning off the vehicle type, so no vehicle module is loaded at startup.
Duh, I should have thought of that, excellent suggestion. The crashes continued. What's interesting to me is my dev module (an early V3.1) is on the bench, powered by a 12V brick and running the same code but never seems to crash. The canbus is not connected to anything but also it does not have a modem card. Then see if it still crashes.
Similar for server connections (are you using v2 or v3?).
To be able to use the iphone app I have v2 enabled. On 2019-06-26 22:38, Michael Balzer wrote:
This type of crash is the reason I now build the edge version on dexters-web.de without CONFIG_WIFI_LWIP_ALLOCATION_FROM_SPIRAM_FIRST.
It seems to reduce these crashes, but I haven't done new statistics yet.
Craig, you could also try if that helps for you.
Another good suggestion; instead of just editing sdkconfig directly I used: gmake menuconfig and then Component config -> ESP32-specific -> SPI RAM config and then turned off: Try to allocate memories of WiFi and LWIP in SPIRAM firstly. That took the "y" off of CONFIG_WIFI_LWIP_ALLOCATION_FROM_SPIRAM_FIRST. So. I haven't driven the car (it's the Z06's turn this week) but no crashes for almost 12 hours, a new record since I've had the module in the Cadillac. And since I was worried that noise from my battery tender was crashing the module it's been running off of the (very new, large delco AGM) battery since Sunday and my DVM still shows 12.7V. So I'm thinking turning off the cellular and gps when parked for N minutes, waking up, getting a fix, uploading to the server and turning back off might a good first pass on power savings mode. (But I really need to get a meter inline and see what the actual draw is when running on wifi vs. cellular...) Craig
participants (6)
-
Craig Leres -
Julien “JaXX” Banchet -
Mark Webb-Johnson -
Mark Webb-Johnson -
Michael Balzer -
Stein Arne Sordal