pierremolinaro
commented
5 years ago Hello,
Thank you very much for your detailed report. I have read it and check my code, I have two suggestions.
First I use xSemaphoreGive in interrupt service routine ; the RTOS documentation says that xSemaphoreGiveFromISR should be used.
So, instead of
ifdef ARDUINO_ARCH_ESP32
void ACAN2517::isr (void) { xSemaphoreGive (mISRSemaphore) ; }
endif
write :
ifdef ARDUINO_ARCH_ESP32
void ACAN2517FD::isr (void) { BaseType_t xHigherPriorityTaskWoken = pdFALSE ; xSemaphoreGiveFromISR (mISRSemaphore, &xHigherPriorityTaskWoken) ; portYIELD_FROM_ISR () ; }
endif
But I am not sure this solves your problem.
The second suggestion is to disable interrupts within every beginTransaction / endTransaction block. For example: mSPI.beginTransaction (mSPISettings) ; . . . some stuff . . . mSPI.endTransaction () ;
becomes: mSPI.beginTransaction (mSPISettings) ;
ifdef ARDUINO_ARCH_ESP32
taskDISABLE_INTERRUPTS () ;endif
. . . some stuff . . . ifdef ARDUINO_ARCH_ESP32
taskENABLE_INTERRUPTS () ;endif
mSPI.endTransaction () ;
And CS should be asserted within the disable / enable interrupt block: mSPI.beginTransaction (mSPISettings) ;
ifdef ARDUINO_ARCH_ESP32
taskDISABLE_INTERRUPTS () ;endif
assertCS ()
. . . some stuff . . .
deassertCS () ;ifdef ARDUINO_ARCH_ESP32
taskENABLE_INTERRUPTS () ;endif
mSPI.endTransaction () ;
Doing so ensures that CS will be deasserted as soon as possible.
I hope this will help you
Best regards,
Pierre Molinaro
Le 27 mai 2019 à 09:10, Nick Kirkby notifications@github.com a écrit :
Using ESP32 with two MCP2517FD on one SPI bus, I seem to be observing a SPI contention problem. With both MCP2517 enabled, sharing a bus, with a third device injecting frames, the system reaches a state in which SERRIF is set on one of the drivers, indicating that the driver has transitioned to "restricted operation mode" (DS20005678B-page 9). This mode is reached more quickly when the bus is under heavy load.
To narrow this issue down, I disabled all but one of the MCP2517FD devices. There are no other devices on the SPI bus, apart from the ESP32.
A logic analyzer shows that the problem is correlated with the ESP taking an unusually long time to deassert nCS on one of the MCP2517 devices, indicating that one RTOS task may have preempted another.
https://user-images.githubusercontent.com/20824939/58401080-bb7f6b00-8011-11e9-8011-127903d84c2a.png I added a function to retrieve SERRIF https://github.com/pierremolinaro/acan2517/compare/master...nkirkby:concurrent_access_investigation?expand=1#diff-cd9bc0c0bbd45475fb25b66825a05a2eR1066, and called it from a 10ms task:
void check_serrif(void *) { Serial.println("SERRIF checker init"); for (int i = 0; i < 10; i ++) { digitalWrite(12, HIGH); vTaskDelay(100 / portTICK_PERIOD_MS); digitalWrite(12, LOW); vTaskDelay(100 / portTICK_PERIOD_MS); } Serial.println("SERRIF checker trigger pending, checking every 10ms");
static int has_printed; while (1) { if (canfi_board.CAN1_serrif_is_set()) { digitalWrite(12, HIGH); if (!has_printed) Serial.println("SERRIF'd"); else has_printed = 1; } vTaskDelay(10 / portTICK_PERIOD_MS); }} This seems to be a heisenbug https://en.wikipedia.org/wiki/Heisenbug. When I added a warning https://github.com/pierremolinaro/acan2517/compare/master...nkirkby:concurrent_access_investigation?expand=1#diff-cd9bc0c0bbd45475fb25b66825a05a2eR714 inside isr_core, the problem becomes unreproduceable. (It usually triggers in a few seconds otherwise)
I'll have a closer look at how semaphores are handled, but am posting to describe what I've found in the mean-time.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/pierremolinaro/acan2517/issues/5?email_source=notifications&email_token=AEWKZVGKEBSYPREACFHBULLPXOCONA5CNFSM4HPZFYYKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4GV6T4WA, or mute the thread https://github.com/notifications/unsubscribe-auth/AEWKZVAOA7PMZIP3BMICJADPXOCONANCNFSM4HPZFYYA.
driftregion
The interrupts are asserted simultaneously, and handled serially without hangups.
Flole998
Using ESP32 with two MCP2517FD on one SPI bus, I seem to be observing a SPI contention problem. With both MCP2517 enabled, sharing a bus, with a third device injecting frames, the system reaches a state in which SERRIF is set on one of the drivers, indicating that the driver has transitioned to "restricted operation mode" (DS20005678B-page 9). This mode is reached more quickly when the bus is under heavy load.
To narrow this issue down, I disabled all but one of the MCP2517FD devices. There are no other devices on the SPI bus, apart from the ESP32.
A logic analyzer shows that the problem is correlated with the ESP taking an unusually long time to deassert nCS on one of the MCP2517 devices, indicating that one RTOS task may have preempted another.
I added a function to retrieve SERRIF, and called it from a 10ms task:
This seems to be a heisenbug. When I added a warning inside
isr_core, the problem becomes unreproduceable. (It usually triggers in a few seconds otherwise)I'll have a closer look at how semaphores are handled, but am posting to describe what I've found in the mean-time.