That looks very promising now, thanks for the update! Regards, Michael Am 16.02.2018 um 10:33 schrieb Mark Webb-Johnson:
New 3.1 hardware is looking very good.
To recap: Unable to get WROOM32 modules with more than the standard 4MB flash on-board, 3.0 used an external 16MB flash chip. That worked well (in the end), but was a pain to get right. RAM was also tight, so we wanted to make sure we had room for expansion and change to a WROVER module (same as WROOM32, but with an extra 4MB flash RAM). When we tried to move the same approach to the 3.1 hardware using WROVER modules, we couldn’t get it to work. The change from 3.3v to 1.8v caused issues, but worse the Espressif IDF just didn’t support the combination of external flash and PSRAM. So, we hand-modified some WROVER modules to swap 4MB->16MB flash chip, as well as sourced a supplier of WROVER modules with 16MB flash on-board. These are now working well.
I can now switch to QIO mode (which should speed things up). Previously, we had to use DIO mode (with external flash). After setting the menuconfig for that, here is what the boot loader tells us:
I (30) boot: ESP-IDF v3.1-dev-391-g8d8d62da 2nd stage bootloader I (30) boot: compile time 16:24:20 I (43) boot: Enabling RNG early entropy source... I (44) qio_mode: Enabling default flash chip QIO I (44) boot: SPI Speed : 40MHz I (47) boot: SPI Mode : QIO I (51) boot: SPI Flash Size : 16MB
In theory, we can go to 80MHz, but the forums have lots of comments about how tight that is on timing so we are going to stay at 40MHz.
SPI RAM gets initialised just fine:
I (743) spiram: SPI RAM mode: flash 40m sram 40m I (747) spiram: PSRAM initialized, cache is in low/high (2-core) mode. ... I (1656) spiram: SPI SRAM memory test OK I (1656) heap_init: Initializing. RAM available for dynamic allocation: I (1656) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM I (1663) heap_init: At 3FFBC198 len 00023E68 (143 KiB): DRAM I (1669) heap_init: At 3FFE0440 len 00003BC0 (14 KiB): D/IRAM I (1675) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM I (1683) heap_init: At 40099404 len 00006BFC (26 KiB): IRAM ... I (1693) spiram: Adding pool of 4096K of external SPI memory to heap allocator
OVMS > module memory Free 8-bit 119128/282436, 32-bit 424/27596, SPIRAM 4193928/4194252 --Task-- Total DRAM D/IRAM IRAM SPIRAM +/- DRAM D/IRAM IRAM SPIRAM tiT 0 0 0 128 +0 +0 +0 +128 Housekeeping 40564 5120 0 12 +40564 +5120 +0 +12 no task 5348 0 0 0 +5348 +0 +0 +0 esp_timer 52328 0 644 0 +52328 +0 +644 +0 main 16448 0 0 0 +16448 +0 +0 +0 ipc0 11096 0 0 0 +11096 +0 +0 +0 ipc1 12 0 0 0 +12 +0 +0 +0 Tmr Svc 884 6444 0 0 +884 +6444 +0 +0 AsyncConsole 108 0 26404 0 +108 +0 +26404 +0
SD CARD works well:
I (1004) sdcard: SD CARD has been inserted. Auto-mounting... I (1004) gpio: GPIO[13]| InputEn: 0| OutputEn: 1| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0 OVMS > test sdcard SD CARD test starts... SD CARD written 0/2048 SD CARD written 128/2048 SD CARD written 256/2048 SD CARD written 384/2048 SD CARD written 512/2048 SD CARD written 640/2048 SD CARD written 768/2048 SD CARD written 896/2048 SD CARD written 1024/2048 SD CARD written 1152/2048 SD CARD written 1280/2048 SD CARD written 1408/2048 SD CARD written 1536/2048 SD CARD written 1664/2048 SD CARD written 1792/2048 SD CARD written 1920/2048 Cleaning up SD CARD test completes
OVMS > vfs ls /sd component.mk sd_card_example_main.c log.txt FOO.TXT stubby ovms3.done
Putting an ovms3.bin into the root directory of the SD card, and rebooting, even has the desired affect of an OTA update:
I (1015) sdcard: SD CARD has been inserted. Auto-mounting... I (1015) gpio: GPIO[13]| InputEn: 0| OutputEn: 1| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0 W (1095) ota: AutoFlashSD Current running partition is: factory W (1095) ota: AutoFlashSD Target partition is: ota_0 W (1095) ota: AutoFlashSD Source image is 1582464 bytes in size W (1095) ota: AutoFlashSD Preparing flash partition... W (9315) ota: AutoFlashSD Flashing image partition... W (18275) ota: AutoFlashSD Setting boot partition... W (19215) ota: AutoFlashSD unmounting SD CARD W (19215) ota: AutoFlashSD OTA flash successful: Flashed 1582464 bytes, and booting from ‘ota_0'
rst:0xc (SW_CPU_RESET),boot:0x3b (SPI_FAST_FLASH_BOOT)
OVMS > ota status Firmware: 3.0.0/ota_0/main build (idf v3.1-dev-217-g5bf85d06) Jan 16 2018 08:03:11 Running partition: ota_0 Boot partition: ota_0
OVMS > metrics list m.version m.version 3.0.0/ota_0/main build (idf v3.1-dev-217-g5bf85d06) Jan 16 2018 08:03:11
CAN buses:
OVMS > can can1 start active 1000000 Can bus can1 started in mode active at speed 1000000Kbps
OVMS > can can2 start active 1000000 Can bus can2 started in mode active at speed 1000000Kbps
OVMS > can can3 start active 1000000 Can bus can3 started in mode active at speed 1000000Kbps
OVMS > can log trace CAN logging active: Type:trace; Path:''; Filter:off; Vehicle:; Note: info logging is done at log level debug, frame logging at verbose
OVMS > log level verbose Logging level for * set to verbose
OVMS > can can3 tx standard 100 01 02 03 04 V (1478305) canlog: TX can3 id 100 len 4: 01 02 03 04 | .... V (1478305) canlog: RX can1 id 100 len 4: 01 02 03 04 | .... V (1478305) canlog: RX can2 id 100 len 4: 01 02 03 04 | ….
OVMS > can can2 tx standard 100 01 02 03 04 V (1598675) canlog: TX can2 id 100 len 4: 01 02 03 04 | .... V (1598675) canlog: RX can1 id 100 len 4: 01 02 03 04 | ....
OVMS > can can1 tx standard 100 01 02 03 04 V (1688155) canlog: TX can1 id 100 len 4: 01 02 03 04 | .... V (1688155) canlog: RX can2 id 100 len 4: 01 02 03 04 | ….
OVMS > can can3 tx extended 100 01 02 03 04 05 06 07 08 V (1716925) canlog: TX can3 id 00000100 len 8: 01 02 03 04 05 06 07 08 | ........ V (1716925) canlog: RX can1 id 00000100 len 8: 01 02 03 04 05 06 07 08 | ........ V (1716925) canlog: RX can2 id 00000100 len 8: 01 02 03 04 05 06 07 08 | ........
Seems to be a problem with receiving on CAN3. Doesn’t really make sense, as it can transmit. I’ll look into this.
Still a few things to check, but it seems we are ok for 3.1 production.
Now on to the SPI RAM support. Planning a base class that can be derived from. Objects there will be allocated from SPI RAM as highest priority (but normal RAM for 3.0 hardware without SPI RAM).
Regards, Mark.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26