Craig, nice analysis & solution, merged. Using the config macro would have been OK though, we will need to introduce separate builds for revision 3 anyway to benefit from the fixed SPIRAM issue. Btw: did you find some time to do the performance tests I suggested? Doesn't take long, just a couple of minutes. Regards, Michael Am 10.03.21 um 05:47 schrieb Craig Leres:
This issue will be solved with this pull request:
https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/585
Starting with revision 2 of the ESP32, the function of the "enable wakeup interrupt" bit in the interrupt enable register changed to mean "divide BRP by 2". The OVMS SJA1000 code enables "all interrupts except arbitration loss" which includes the wakeup interrupt/divide BRP bit. This causes the can baud to be configured at half the requested speed; a workaround is to set the speed to 2X desired.
The (minimal) fix is to clear this bit when revision is >= 2. Since we're not using sleep, we could also just always clear that bit. But in the long run I'm hopeful that the ability to use effectively larger BRP values will mean V3 hardware will be able to run can1 at lower speeds, e.g. 33K.
At first I was looking at the can module in the esp-idf; even the old version we're running has code to do with this issue! But cleverly, it's a compile time #ifdef instead of run time check based on observed version (?!?!) I think the way it works is you define CONFIG_ESP32_REV_MIN to the lowest hardware version you want to support and it assumes you have at least that. Which seems silly to me. I tried converting it to a run time check and it didn't work -- that's when I figured out OVMS uses it's own SAJ1000 driver code.
Thanks to Thomas Heuer for reaching out to me and giving a pointer to this forum post:
https://www.esp32.com/viewtopic.php?t=15581#p59670
which was key in figuring this out.
Craig
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26