Update: unicore mode is unusable for us. Further tests showed CAN processing times get really bad (i.e. milliseconds, not microseconds). This affects especially live control and monitoring via OBD2 / CANopen, also the RX callbacks get processed with a too high delay to be able to overwrite control frames that need fast responses (like charge current control on the Twizy). Also I got the same bug event as before while running in unicore mode, so either this bug isn't related to the PSRAM issue or unicore mode is not sufficient as a workaround. I'm going back to dual core. Regards, Michael Am 18.10.19 um 21:04 schrieb Michael Balzer:
Everyone,
the PSRAM issue still isn't solved, users reported new events and I had two events myself today. So toolkit -98 also doesn't fix the issue completely for us.
Following the findings of @neoniusTR (Thomas Rogg), I have enabled building the OVMS in FreeRTOS unicore mode, i.e. FreeRTOS and all tasks only running on core 0.
My previous load measurements showed we're only using max. ~20% of the CPU, and my test runs with a unicore build don't exhibit any slowness or sluggishness.
To use unicore mode, build with CONFIG_FREERTOS_UNICORE=Y.
I've just released the unicore build to my edge branch on dexters-web.de so will be able to gather some user feedback.
Regards, Michael
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26