[Ovmsdev] Transition to new esp-idf

Mark Webb-Johnson mark at webb-johnson.net
Tue Jan 16 08:49:54 HKT 2018


Really, just storage; temporary storage space for log files, scripts, data captures, etc.

Also useful for getting things in and out of the system.

For example: put a firmware on the root of the SD CARD as ovms3.bin, insert it, and this is what happens:

I (47547) sdcard: SD CARD has been inserted. Auto-mounting...
W (47737) ota: AutoFlashSD Current running partition is: factory
W (47737) ota: AutoFlashSD Target partition is: ota_0
W (47737) ota: AutoFlashSD Source image is 1582464 bytes in size
W (47737) ota: AutoFlashSD Preparing flash partition...
W (52587) ota: AutoFlashSD Flashing image partition...
W (59977) ota: AutoFlashSD Setting boot partition...
W (60937) ota: AutoFlashSD unmounting SD CARD
W (60937) ota: AutoFlashSD OTA flash successful: Flashed 1582464 bytes, and booting from ‘ota_0'

ets Jun  8 2016 00:22:57
rst:0xc (SW_CPU_RESET),boot:0x1f (SPI_FAST_FLASH_BOOT)
configsip: 156795334, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:4468
load:0x40078000,len:0
load:0x40078000,len:12988
entry 0x40078d14

I (173) ovms_main: Set default logging level for * to WARN

Welcome to the Open Vehicle Monitoring System (OVMS) - Async Console

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

OVMS > vfs ls /sd
ovms3.done

That (a) detected a SD CARD was inserted, (b) found the /sd/ovms3.bin firmware file, (c) flashed that to a free ota partition, (d) set the ota partition as the one to boot from, and (e) rebooted into it. For users without wifi, that is probably how they are going to update firmware.

P.S. For those of you testing this, to switch back to factory:

OVMS > ota boot factory
Boot from factory at 0x00010000 (size 0x00400000)

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: factory

OVMS > module reset
Resetting system...

OVMS > ota status
Firmware: 3.0.0/factory/main build (idf v3.1-dev-217-g5bf85d06) Jan 16 2018 08:03:11
Running partition: factory
Boot partition: factory

OVMS > metrics list m.version
m.version                                3.0.0/factory/main build (idf v3.1-dev-217-g5bf85d06) Jan 16 2018 08:03:11

This can all be done with simple SD CARDs. No complex driver installs, or firmware flashing software.

Regards, Mark.

> On 16 Jan 2018, at 3:40 AM, Greg D. <gregd2350 at gmail.com> wrote:
> 
> Just to ask (don't shoot me - I'm new here!)...  Why do we need SD cards on the module?  What is the end-user scenario that makes them essential?
> 
> Greg
> 
> 
> Michael Balzer wrote:
>> I've found the missing RAM. It's allocated for the SD card:
>> 
>> OVMS > module memory 
>> Free 8-bit 117364/286352, 32-bit 17972/45144, SPIRAM 0/0
>> 
>> I (34235) sdcard: SD CARD has been inserted. Auto-mounting...
>> 
>> OVMS > module memory 
>> Free 8-bit 89348/286352, 32-bit 17972/45144, SPIRAM 0/0
>> --Task--     Total DRAM D/IRAM   IRAM SPIRAM   +/- DRAM D/IRAM   IRAM SPIRAM
>> Tmr Svc               4  27804      0      0         +4 +27804     +0     +0
>> 
>> I (68065) sdcard: SD CARD has been removed.
>> 
>> OVMS > module memory 
>> Free 8-bit 117332/286352, 32-bit 17972/45144, SPIRAM 0/0
>> --Task--     Total DRAM D/IRAM   IRAM SPIRAM   +/- DRAM D/IRAM   IRAM SPIRAM
>> Tmr Svc               0     12      0      0         -4 -27792     +0     +0
>> 
>> …again…
>> 
>> OVMS > module memory 
>> Free 8-bit 117332/286352, 32-bit 17972/45144, SPIRAM 0/0
>> --Task--     Total DRAM D/IRAM   IRAM SPIRAM   +/- DRAM D/IRAM   IRAM SPIRAM
>> Tmr Svc               0     12      0      0         -4 -27792     +0     +0
>> 
>> I (114985) sdcard: SD CARD has been inserted. Auto-mounting...
>> 
>> OVMS > module memory 
>> Free 8-bit 89348/286352, 32-bit 17972/45144, SPIRAM 0/0
>> --Task--     Total DRAM D/IRAM   IRAM SPIRAM   +/- DRAM D/IRAM   IRAM SPIRAM
>> Tmr Svc               4  27804      0      0         +4 +27792     +0     +0
>> 
>> E (141205) sdmmc_cmd: sdmmc_read_sectors_dma: sdmmc_send_cmd returned 0x107
>> E (141205) diskio_sdmmc: sdmmc_read_blocks failed (263)
>> I (141515) sdcard: SD CARD has been removed.
>> 
>> OVMS > module memory 
>> Free 8-bit 117332/286352, 32-bit 17972/45144, SPIRAM 0/0
>> --Task--     Total DRAM D/IRAM   IRAM SPIRAM   +/- DRAM D/IRAM   IRAM SPIRAM
>> Tmr Svc               0     12      0      0         -4 -27792     +0     +0
>> 
>> 
>> Btw, I think the RAM usage of the telnet server is also higher than before:
>> 
>> OVMS > module memory 
>> Free 8-bit 117332/286352, 32-bit 17972/45144, SPIRAM 0/0
>> 
>> OVMS > wifi mode client 
>> Starting WIFI as a client for any defined SSID
>> I (380175) wifi: wifi firmware version: 403db1d
>> I (380175) wifi: config NVS flash: enabled
>> I (380175) wifi: config nano formating: disabled
>> I (380185) wifi: Init dynamic tx buffer num: 16
>> I (380185) wifi: Init data frame dynamic rx buffer num: 16
>> I (380185) wifi: Init management frame dynamic rx buffer num: 16
>> I (380185) wifi: wifi driver task: 3ffe3db4, prio:23, stack:4096
>> I (380185) wifi: Init static rx buffer num: 4
>> I (380185) wifi: Init dynamic rx buffer num: 16
>> I (380195) wifi: wifi power manager task: 0x3ffe846c prio: 21 stack: 2560
>> I (380195) wifi: mode : sta (30:ae:a4:37:25:88)
>> W (390205) wifi: incorrect scan type: 1073534024
>> I (392615) esp32wifi: Found SSID devolo-f4068d73a03e - trying to connect
>> I (393945) wifi: n:11 2, o:1 0, ap:255 255, sta:11 2, prof:1
>> I (394595) wifi: state: init -> auth (b0)
>> I (394605) wifi: state: auth -> assoc (0)
>> I (394605) wifi: state: assoc -> run (10)
>> I (394625) wifi: connected with devolo-f4068d73a03e, channel 11
>> I (394665) esp32wifi: WiFi UP with SSID: devolo-f4068d73a03e, MAC: 30:ae:a4:37:25:88, IP: 192.168.2.101, mask: 255.255.255.0, gw: 192.168.2.1
>> I (394665) telnet: Launching Telnet Server
>> I (397615) wifi: pm start, type:0
>> 
>> OVMS > module memory 
>> Free 8-bit 89700/286352, 32-bit 17972/45144, SPIRAM 0/0
>> --Task--     Total DRAM D/IRAM   IRAM SPIRAM   +/- DRAM D/IRAM   IRAM SPIRAM
>> tiT                 128    716      0      0         +0   +484     +0     +0
>> AsyncConsole          0  16552  26404      0         +0 +16356     +0     +0
>> NetManTask            8    488      0      0         +8   +488     +0     +0
>> wifi                  0   1600      0      0         +0  +1600     +0     +0
>> eventTask             0   7564      0      0         +0  +7564     +0     +0
>> 
>> 
>> …but I'm not sure about that, haven't tested that in a while.
>> 
>> 
>> So, SD cards now work, and I'll not be able to use them due to the RAM usage… :(
>> 
>> 
>> 
>> Am 15.01.2018 um 19:21 schrieb Michael Balzer:
>>> Transition went fine. "make flash" didn't even erase "/store", I had expected that to happen, good to know.
>>> 
>>> And…
>>> 
>>> OVMS > sd status 
>>> SD CARD is inserted
>>> Name: SL32G
>>> Type: SDHC/SDXC
>>> Speed: default speed
>>> Size: 30436MB
>>> CSD: ver=1, sector_size=512, capacity=62333952 read_bl_len=9
>>> SCR: sd_spec=2, bus_width=5
>>> 
>>> → me too (the minion) :)
>>> 
>>> 
>>> BUT… after reconfiguration to the same components as before, I'm now missing about 30-40 KB of free RAM.
>>> 
>>> After loading just the Twizy module & the v2 server, I'm now again down to…
>>> 
>>> OVMS > module memory 
>>> Free 8-bit 2632/286352, 32-bit 17972/45144, SPIRAM 0/0
>>> 
>>> …so it crashes as soon as it needs to actually do anything, like sending a notification.
>>> 
>>> This is without any of the new CAN logging stuff yet, that's stashed away for the transition.
>>> 
>>> I'll now check the config again for any more options to save RAM…
>>> 
>>> Regards,
>>> Michael
>>> 
>>> 
>>> Am 15.01.2018 um 06:48 schrieb Stephen Casner:
>>>> In order for the the "module memory" and "module tasks" commands to
>>>> work, the configuration needs to be changed from the sdk.default.hw30
>>>> that Mark just provided. CONFIG_FREERTOS_USE_TRACE_FACILITY needs to
>>>> be enabled, CONFIG_HEAP_POISONING must be enabled (LIGHT or
>>>> COMPREHENSIVE), and CONFIG_HEAP_TASK_TRACKING must be enabled.  I have
>>>> attached a diff for the sdkconfig.  That diff also includes a section
>>>> for enabling telnet, which some of you may be using.
>>>> 
>>>> Please also note that in this revised implementation of "module
>>>> memory" the block address is now the address that is returned from
>>>> malloc, not the address of the header that precedes it, and the length
>>>> of the block is now exclusive of the debugging overhead.
>>>> 
>>>>                                                         -- Steve
>>>> 
>>>> On Mon, 15 Jan 2018, Mark Webb-Johnson wrote:
>>>> 
>>>>> All committed and pushed now.
>>>>> 
>>>>> Developers MUST now update their ESP IDF and XTENSA build tools to use this new build. They should also compare sdkconfig and sdkconfig.defaults.hw30 to verify differences. I also suggest you do a ‘make flash’ (rather than ‘make app-flash’) at least once, to update the bootloader to the latest (as bootloaders before v2.1 are no longer supported).
>>>>> 
>>>>> Check
>>>>> https://esp-idf.readthedocs.io/en/latest/get-started/index.html#setup-toolchain <https://esp-idf.readthedocs.io/en/latest/get-started/index.html#setup-toolchain> <https://esp-idf.readthedocs.io/en/latest/get-started/index.html#setup-toolchain> <https://esp-idf.readthedocs.io/en/latest/get-started/index.html#setup-toolchain>
>>>>> to see the version of XTENSA toolchain required for latest Espressif IDF ‘master’ builds. As of this writing, it is 1.22.0-80-g6c4433a-5.2.0.
>>>>> 
>>>>> I hope this goes smoothly for you.
>>>>> 
>>>>> Regards, Mark.
>>>>> 
>>>>> commit dfcc658557fc480bcccb09b23bc24399bb6e7497 (HEAD -> master, origin/master, origin/HEAD)
>>>>> Author: Mark Webb-Johnson <mark at webb-johnson.net> <mailto:mark at webb-johnson.net>
>>>>> Date:   Mon Jan 15 07:56:45 2018 +0800
>>>>> 
>>>>>     Provide a sdkconfig.default.hw31 for OVMS v3.1 hardware
>>>>> 
>>>>> commit 003592d553c881f735fb228b08836a13c306cec3
>>>>> Merge: e58c5b6 b28db5e
>>>>> Author: Mark Webb-Johnson <mark at webb-johnson.net> <mailto:mark at webb-johnson.net>
>>>>> Date:   Mon Jan 15 07:49:13 2018 +0800
>>>>> 
>>>>>     Merge branch 'for-master'. This requires ESP-IDF v3.0 support:
>>>>> 
>>>>>     OVMS developers should now:
>>>>> 
>>>>>     1] Pull the latest OpenVehicles IDF, and checkout MASTER branch.
>>>>> 
>>>>>     2] Update XTENSA tools to match version required by Espressif for MASTER branch.
>>>>> 
>>>>>     3] For ovms hardware v3.0, a sdkconfig default file sdkconfig.default.hw30 has
>>>>>        been provided. That can be merged/copied to sdkconfig as appropriate.
>>>>> 
>>>>>     4] For ovms hardware v3.1, a sdkconfig default file sdkconfig.default.hw31 will
>>>>>        been provided in the next update.
>>>>> 
>>>>>     5] It is recommended that developers perform at least one full 'make flash'
>>>>>        with this version, to update the bootloader to latest. Note that the
>>>>>        sdkconfig.default.* files are now set to require bootloader at least v2.1
>>>>>        (or later), and bootloader v2.0 is no longer supported.
>>>>> 
>>>>>     Enjoy.
>>>>> 
>>>>> 
>>>>>> On 15 Jan 2018, at 7:25 AM, Mark Webb-Johnson <mark at webb-johnson.net> <mailto:mark at webb-johnson.net> wrote:
>>>>>> 
>>>>>> Merge is ok, but triple checking a couple of things. Should be committed and pushed within the next half hour.
>>>>>> 
>>>>>> Regards, Mark
>>>>>> 
>>>>>>> On 15 Jan 2018, at 1:09 AM, Stephen Casner <casner at acm.org> <mailto:casner at acm.org> wrote:
>>>>>>> 
>>>>>>> Mark,
>>>>>>> 
>>>>>>> It looks like you were not able to do the sdkconfig.default and merge
>>>>>>> as you planned?
>>>>>>> 
>>>>>>>                                                       -- Steve
>>>>>>> 
>>>>>>>> On Fri, 12 Jan 2018, Stephen Casner wrote:
>>>>>>>> 
>>>>>>>>> On Sat, 13 Jan 2018, Mark Webb-Johnson wrote:
>>>>>>>>> 
>>>>>>>>> @Steve can you update our master clone to latest from Espressif and
>>>>>>>>> make sure your stuff is still ok?
>>>>>>>> I have just now done this.  I had already done a rebase a few days ago
>>>>>>>> before committing the improved version of the OS changes so I could
>>>>>>>> issue a pull request.  There were a few commits since then, which I
>>>>>>>> have now merged.  My code still runs correctly.
>>>>>>>> 
>>>>>>>>> I guess steps for developers will be:
>>>>>>>>> 
>>>>>>>>> 1) pull the openvehicles IDF and switch to master branch. Sub module update.
>>>>>>>>> 
>>>>>>>>> 2) download and install xtensa build chain to match.
>>>>>>>>> 
>>>>>>>>> 3) update OVMS master, make clean, check menu config, then build and play.
>>>>>>>> Sounds right.
>>>>>>>> 
>>>>>>>>> I can get my part done by Sunday 14th night (HKT), so suggest to do
>>>>>>>>> the Merge of the OVMS firmware master branch then.
>>>>>>>> I'll be sleeping then, so you can go ahead and do the merge.
>>>>>>>> 
>>>>>>>>                                                       -- Steve
>>>>>>> _______________________________________________
>>>>>>> OvmsDev mailing list
>>>>>>> OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
>>>>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
>>>>>> _______________________________________________
>>>>>> OvmsDev mailing list
>>>>>> OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
>>>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
>>>> >
>>>> 
>>>> 
>>>> _______________________________________________
>>>> OvmsDev mailing list
>>>> OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
>>> 
>>> -- 
>>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>> 
>>> 
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
>> 
>> -- 
>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>> 
>> 
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

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


More information about the OvmsDev mailing list