[Ovmsdev] OVMS v3.1 crashes during boot continuously

[Henrik Scheel]

> welcome :)

Thanks :-)

> See https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/148
> ?and the new 12V section in the user guide.


Ok, I will look into that when I have a functioning module.

> So the Soul doesn't top up the 12V battery from the main battery? How much capacity does the 12V battery have on the Soul?

Kia Soul EV does not top up the 12 Volt battery when off. The capacity is 50 Ah. If I recall correctly, the original battery had 48 Ah. 

> See https://github.com/espressif/esptool/wiki/espefuse -- you can try the dump command and send the results to Espressif. If your ESP32 really lost its efuses,
> I think that's a warranty issue.


I ran the dump. It did not report CRC error, nor all1’s or 0’s. Is there any reason not to share the output from the dump command publicly?

I am guessing the current rebooting issue could be an issue with my build. It is my first OVMS build, based on sources pulled Aug 4, and I may have done something wrong, have the wrong version of some tool installed, or something may have changed in the repos since the developer guide was last tested by someone.

Can I download bootloader.bin, ovms3.bin and partitions.bin from somewhere, and flash those instead of my build?

Henriks-MBP:OVMS.V3 henrik$ make print_flash_cmd
--flash_mode dio --flash_freq 40m --flash_size detect 0x1000 bootloader/bootloader.bin 0x10000 ovms3.bin 0x8000 partitions.bin

Is “make flash” always supposed to bring the device to a functioning state, when configured and built as described in the developer config (i.e. by cp support/sdkconfig.default.hw31 sdkconfig and then make menuconfig)?

I seem to get errors when connecting to the device, e.g. when flashing:
…
AR build/xtensa-debug-module/libxtensa-debug-module.a
LD build/ovms3.elf
esptool.py v2.3.1
Flashing binaries to serial port /dev/tty.SLAB_USBtoUART (app at offset 0x10000 )...
esptool.py v2.3.1
Traceback (most recent call last):
  File "/Users/henrik/esp/esp-idf/components/esptool_py/esptool/esptool.py", line 2637, in <module>
    _main()
  File "/Users/henrik/esp/esp-idf/components/esptool_py/esptool/esptool.py", line 2630, in _main
    main()
  File "/Users/henrik/esp/esp-idf/components/esptool_py/esptool/esptool.py", line 2355, in main
    esp = chip_class(args.port, initial_baud, args.trace)
  File "/Users/henrik/esp/esp-idf/components/esptool_py/esptool/esptool.py", line 193, in __init__
    self._port = serial.serial_for_url(port)
  File "/Library/Python/2.7/site-packages/serial/__init__.py", line 88, in serial_for_url
    instance.open()
  File "/Library/Python/2.7/site-packages/serial/serialposix.py", line 272, in open
    self._reconfigure_port(force_update=True)
  File "/Library/Python/2.7/site-packages/serial/serialposix.py", line 438, in _reconfigure_port
    [iflag, oflag, cflag, lflag, ispeed, ospeed, cc])
termios.error: (22, 'Invalid argument')
make: *** [flash] Error 1
Henriks-MBP:OVMS.V3 henrik$ make flash
Flashing binaries to serial port /dev/tty.SLAB_USBtoUART (app at offset 0x10000 )...
esptool.py v2.3.1
Connecting........_____....._____....._____....._____....._____....._____....._____....._____....._____....._____

A fatal error occurred: Failed to connect to ESP32: Timed out waiting for packet header
make: *** [flash] Error 2
Henriks-MBP:OVMS.V3 henrik$ 

Could all of this conceivably be caused by “bad” USB hardware? I connect the device via a cheap Hama device for converting my thunderbolt port to standard USB.

Best regards,
Henrik
-- 

Venlig hilsen / best regards 
Henrik R. Scheel

Spjeldager Consult ApS
Spjeldager 9 
DK-2630 Taastrup 
CVR: 34491399 
T: +45 2720 9828 
http://www.spjeldager.dk/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20180806/23d0e209/attachment.htm>