[Ovmsdev] Things are getting louder

Fri Feb 16 18:35:20 HKT 2018

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 at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20180216/933b778f/attachment.htm>