2

Struggling with this issue for days now and can't find a solution. Maybe someone saw something like this before and can give me a hint.

I have FreeRTOS running on an STM32L4 with different tasks. One of these tasks should handle CAN communication.

In the CAN interrupt enable register (CAN_IER) I set the enable for ERRIE, BOFIE, EPVIE, FMPIE0 and TMEIE. The application ends up in an infinite loop error with the following trace

Call Trace

I figured out that if I remove the enable for the TMEIE (Transmit mailbox empty interrupt enable) the application starts to run normally but also crashes as soon as one of the other interrupts trips (e.g. if a message is received).

Is this something obvious, maybe an issue with my interrupt handling? Or can someone guide me in the right direction?

mohammadsdtmnd
  • 545
  • 3
  • 17
po.pe
  • 2,548
  • 1
  • 10
  • 25
  • Without all the source we're very unlikely to be able to help. – pjc50 Oct 06 '20 at 13:44
  • 4
    Looks to me as though you aren't handling the CAN interrupts. Have you written or included any code for functions like `CAN1_TX_IRQHandler()`, `CAN1_RX0_IRQHandler()`, etc? – brhans Oct 06 '20 at 13:46
  • I can't provide all the source as on one hand it's huge and on the other hand I'm not the owner of all of it. I was therefore hoping that this behavior is typical for a certain mistake (e.g. wrong interrupt initialization). – po.pe Oct 06 '20 at 13:47
  • @brhans There's a proprietary CANopen stack running that should handle that, at least that's my expectation. Altough searching the project for `CAN1_TX_IRQHandler()` didn't give any result... – po.pe Oct 06 '20 at 13:49
  • Even with a stack to handle it, you probably still need to create those interrupt handler functions which will be called when the interrupt occurs - probably all they need to do is make another call into the stack. I'm assuming that your stack is written to be generic so that it works on many different devices, so the stack won't have the device-specific interrupt handler functions. This *should* be documented in the reference manual for your stack... Perhaps search the stack code for interrupt handler functions and see if there are any comments to tell you how to link them in. – brhans Oct 06 '20 at 13:54
  • Well the stack itself is generic but the RTOS support files are chip specific. Further there are samples which as well don't include separate handlers (but which also don't work... so that's not telling much). I'll dig in this direction and let you know when I found something! Thanks in the meantime! – po.pe Oct 06 '20 at 14:03
  • is this a CAN stack/lib/binding that anyone can purchase? link to its documentation? – vicatcu Oct 06 '20 at 14:21
  • 2
    It was indeed the missing IRQHandler, sometimes you just miss the forrest for the trees. Anyway thousand thanks for the hint! @vicatcu None of their sources is open for download, including the documentation – po.pe Oct 06 '20 at 14:46
  • That looks like a call stack/stack trace, which is mildly useful. A decent debugger should have actual instruction trace. The various free Eclipse hellspawns from silicon vendors do not come with decent debuggers. – Lundin Oct 07 '20 at 07:59
  • Anyway, the source of the ISRs and the vector table are sufficient. – Lundin Oct 07 '20 at 08:00
  • Then answer your question and accept it's answer, Thx it helped me. – mohammadsdtmnd Dec 08 '22 at 06:19

1 Answers1

0

It trurned out that the implementation of the IRQHandler was missing...

po.pe
  • 2,548
  • 1
  • 10
  • 25