[Ovmsdev] ESP-IDF v4 / v5 - baby steps

Sat Feb 18 17:12:23 HKT 2023

Ludovic,

the issue is bound to the docker image version, I was using 
"espressif/idf", which is "latest".

The build works using the same sdkconfig with 
"espressif/idf:release-v5.0" (and again fails at that mbedtls module 
when switching back to the "latest" image).

So to build the current experimental state, I recommend using the docker 
image and basically doing the steps Ludovic formalized in the github action:

### SETUP ###

cd ~/esp/Open-Vehicle-Monitoring-System-3

# setup branch:
git remote add llange 
git at github.com:llange/Open-Vehicle-Monitoring-System-3.git
git branch -t experimental-esp-idf-build-workflow 
llange/experimental-esp-idf-build-workflow

# switch to branch:
git checkout experimental-esp-idf-build-workflow
git submodule update --init --recursive

# apply mongoose patch:
git apply --directory=vehicle/OVMS.V3/components/mongoose/mongoose 
vehicle/OVMS.V3/support/mongoose-espv5.patch

# install v5 sdkconfig defaults:
cp vehicle/OVMS.V3/support/sdkconfig.defaults.esp5 
vehicle/OVMS.V3/sdkconfig.defaults

# install v5 idf components:
cp vehicle/OVMS.V3/support/idf_component.yml.esp5 
vehicle/OVMS.V3/main/idf_component.yml

### BUILD ###

cd ~/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3

# launch docker shell:
docker run --rm -v $PWD:/project -w /project -it espressif/idf:release-v5.0
# init docker image (needs to be done on every start):
apt-get update && apt-get install -y dos2unix

# OPTION 1: start with default config:
rm vehicle/OVMS.V3/sdkconfig
# NOTE: this will build for ESP32 >= rev3, excluding the SPIRAM bug 
workarounds

# OPTION 2: update your existing sdkconfig:
idf.py menuconfig
# → press '/'
#   … enable FREERTOS_ENABLE_BACKWARD_COMPATIBILITY
#   … disable FREERTOS_ASSERT_ON_UNTESTED_FUNCTION
#   … disable MG_ENABLE_SSL

# build:
idf.py build

# flash & start USB monitor:
idf.py app-flash && idf.py monitor

The build boots & works, issues you described excluded.

An issue I didn't expect:

I (0) cpu_start: Starting scheduler on APP CPU.
E (0) task_wdt: esp_task_wdt_add(747): TWDT was never initialized
…
E (10) task_wdt: esp_task_wdt_add(747): TWDT was never initialized

…and then repeated 4x per second:
E (3130) task_wdt: esp_task_wdt_reset(783): task not found

I'll try to find the cause, as we cannot silent these ("early" logging) 
they make using the shell challenging.

But, besides that, it has Wifi & cellular connectivity, so looks very 
promising -- nice work, Ludovic!

Regards,
Michael

Am 18.02.23 um 00:53 schrieb Ludovic LANGE:
> Hi Michael,
>
> I'm sorry to read that you're facing those issues.
>
> It's almost certain that my sdkconfig, after being changed back and 
> forth to disable certain modules that would not compile, is now not in 
> a "pristine" state, and that's certainly why your build and mine do 
> not activate the same compilation paths.
>
> I'll be interested in getting your sdkconfig file to see what is left 
> to fix to have it properly compile.
>
> (In the meantime I have forced the compilation of this part of the 
> module, fixed the compilation errors you were likely to have, and 
> force-pushed those fixes on the 2 branches experimental-esp-idf-v5 and 
> experimental-esp-idf-build-workflow)
>
> Regarding the linking error, I'm not sure why you have it, as it's 
> looks like it is part of the mbedtls of ESP-IDF 5.0 - I'll see if I 
> can reproduce it when I have your sdkconfig.
>
> Regards,
>
> Ludovic
>
> Le 17/02/2023 à 22:54, Michael Balzer a écrit :
>> Ludovic,
>>
>> using the docker image I managed to make some progress.
>>
>> I can now start the build process, but then run into printf format 
>> errors on main/ovms_module.cpp, e.g.
>>
>> /project/main/ovms_module.cpp: In function 'void 
>> print_blocks(OvmsWriter*, TaskHandle_t, bool)':
>> /project/main/ovms_module.cpp:438:37: error: format '%d' expects 
>> argument of type 'int', but argument 4 has type 'uint32_t' {aka 'long 
>> unsigned int'} [-Werror=format=]
>>
>> I'm here:
>>
>> commit 19e36125c6e0597c901eb82a546ef82c1dea8a1e (HEAD -> 
>> experimental-esp-idf-v5, llange/experimental-esp-idf-v5)
>> Author: Ludovic LANGE <llange at users.noreply.github.com>
>>
>> I thought maybe you've sorted that out in your new build branch, but 
>> apparently that has the same error, which leaves me wondering how the 
>> automated build can work…
>>
>> I see you don't have CONFIG_FREERTOS_USE_TRACE_FACILITY in your new 
>> "sdkconfig.defaults.esp5", so the module isn't included in your 
>> build. But you also have CONFIG_FREERTOS_GENERATE_RUN_TIME_STATS=y, 
>> which automatically enables CONFIG_FREERTOS_USE_TRACE_FACILITY in my 
>> setup.
>>
>> Disabling both options, I just almost got through, just a final 
>> linker error:
>>
>> /project/components/zip/libzip/lib/zip_crypto_mbedtls.c:124: 
>> undefined reference to `mbedtls_pkcs5_pbkdf2_hmac'
>>
>> I assume there are more differences in your new branch / sdkconfig, 
>> I'll try that one next.
>>
>> Regards,
>> Michael
>>
>>
>> Am 10.02.23 um 09:37 schrieb Ludovic LANGE:
>>> Hi,
>>>
>>> Just as a curiosity, I setup GitHub to build the v5 branch with 
>>> "GitHub actions".
>>>
>>> You can find the latest runs here : 
>>> https://github.com/llange/Open-Vehicle-Monitoring-System-3/actions
>>>
>>> The configuration file is here : 
>>> https://github.com/llange/Open-Vehicle-Monitoring-System-3/blob/experimental-esp-idf-build-workflow/.github/workflows/build-ovms.yml
>>>
>>> /Note: It's a specific branch because I had to add some 
>>> configuration files (default sdkconfig options for example), change 
>>> the reference to wolfssl submodule, add a patch for our mongoose 
>>> version, ... ; but in the future I could make a PR for this feature 
>>> if we find it useful./
>>> /(I also would like to experiment a little bit with static code 
>>> analysis, unit tests, etc...)/
>>>
>>> Regards,
>>>
>>> Le 06/02/2023 à 15:23, Ludovic LANGE a écrit :
>>>> Hi again,
>>>>
>>>> Additionally, I've just verified that the official docker image for 
>>>> ESP-IDF (doc: 
>>>> https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/tools/idf-docker-image.html 
>>>> ) is able to build the branch.
>>>>
>>>> The only thing to add to the image is the "dos2unix" utility ("apt 
>>>> update && apt-get install dos2unix"), after that you'll be able to 
>>>> build the image.
>>>>
>>>> Do not forget to update your sdkconfig (enabling FreeRTOS 
>>>> compatibility and unchecking SSL for mongoose) before building, and 
>>>> to do the patches for mongoose / wolfssl as described here: 
>>>> https://github.com/llange/Open-Vehicle-Monitoring-System-3/blob/experimental-esp-idf-v5/README.md
>>>>
>>>> Then "idf.py build" should work - at least !
>>>>
>>>> I've used the `docker run --rm -v $PWD:/project -w /project -it 
>>>> espressif/idf:|release-v5.0|` command to have a shell prompt 
>>>> (launch that in your source file path)
>>>>
>>>> Then install dos2unix, launch menuconfig, then build.
>>>>
>>>> Tell me how it works for you.
>>>>
>>>> (You may have some component build failure ; depending on the 
>>>> sdkconfig flags, I'm still trying to document it)
>>>>
>>>> Regards,
>>>>
>>>
>>>
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com
>>> http://lists.openvehicles.com/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.openvehicles.com
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/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/20230218/d7ba7b34/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 203 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20230218/d7ba7b34/attachment-0001.sig>