[Ovmsdev] PSRAM fix in esp-idf release v3.3
dexter at expeedo.de
Thu Jul 16 17:27:48 HKT 2020
I've merged the latest release/v3.3 esp-idf into our idf fork and merged
the PSRAM fix test branch into our OVMS master.
To build now, you need to:
1. Update your toolchain to release 1.22.0-96-g2852398-5.2.0: download
the toolchain for your OS from
simply replace your existing toolchain installation by unpacking the
archive. Test your toolchain installation by checking
2. Pull our latest esp-idf master and -important- update the submodules
3. Pull/checkout our latest OVMS master
4. Update your sdkconfig from support/sdkconfig.default.hw31
The build should then result in version
3.2.013-298-g025f838b/factory/edge (build idf v3.3.2-879-g0137aef47 Jul
16 2020 10:53:38) or higher.
Am 15.07.20 um 08:07 schrieb Michael Balzer:
> Yes, differences on the test branches are minor, also in esp-idf.
> But we probably also need to pull in the latest changes on the esp-idf
> 3.3 branch, which may be some more work.
> I'll fetch the current toolchain version and check what is needed.
> Am 15.07.20 um 04:13 schrieb Mark Webb-Johnson:
>> Finally… Crazy that this took so long.
>> We have a GetOVMSHardware() in ovms_version.cpp that picks up
>> the esp_chip_info_t structure and has chip.revision (documented as
>> "chip revision number”). That is stored in metric m.hardware. My
>> bench unit is showing rev=ESP32/1. I checked a bunch of recent cars
>> connected to api.openvehicles.com <http://api.openvehicles.com>, but
>> all showed the same. So not sure if the v3 silicon is not reported in
>> that chip.revision, if we are just using existing stocks, or an IDF
>> update is required to pickup the new silicon version number. The v3
>> seems fairly recent (March 2020?) and I don’t see a v2 listed.
>> Anyway, I’ve just yesterday received a new batch of modules so will
>> check those to see if it shows up.
>> What do we need to do to switch to this? Presumably I turn off
>> auto-build of the firmware on api.openvehicles.com
>> <http://api.openvehicles.com>, you merge your SPIRAM branch to
>> master, we tell everyone to download the new toolchain, then we
>> switch both our edge builds back to master branch with new toolchain?
>> Apart from the CONFIG_SPIRAM_SUPPORT 2MB workaround, I can’t see any
>> significant differences between remotes/origin/spiram-fix-test and
>> master? Is the only difference the ovms_websockethandler.cpp change
>> to std::string (vs extram::string)?
>> Regards, Mark.
>>> On 15 Jul 2020, at 2:11 AM, Michael Balzer <dexter at expeedo.de
>>> <mailto:dexter at expeedo.de>> wrote:
>>> it seems the fix has finally arrived in the official release 3.3 branch:
>>>> In the v3 silicon, the issue has been fixed, and the workaround is
>>>> no longer required.
>>> I guess that means from some manufacturing point on we should
>>> provide two builds, one for the older hardware and one for the
>>> modules with v3 chips, as the fix definitely has a performance impact.
>>> 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 <mailto:OvmsDev at lists.openvehicles.com>
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com
> 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
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OvmsDev