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