Interrupt Callback problems: Working for one peripheral, but not others of same type

[TheImmortal]

Title edited for length - please keep titles short, but descriptive.

Original title: "SPI callback interrupt does not work for SPI, but works if I switch to other SPI with identical settings, same for timers and other peripherals"

---

Hello,

There I have problem with callbacks, not only with SPI, but at this moment trying to solve there, I use SPI5 for communicate with sensor, worked well until I changed some completely unrelated settings elsewhere in cubeMX, after code generation I found what I do not getting data from sensor, in my code SPI DMA transfer was initiated by timer callback, timer simply calls HAL_SPI_Receive_DMA function at specified intervals, I noticed what timer stopped to work, I tryed change, disable, remove, clean, delete debug folder, add timer to config again - without success, then I switched to another timer and with this timer interrupts started to work again ! Next - SPI5, there is the same - clean, remove, delete... without any success, then I switched to another SPI (SPI6) and I got response from SPI callback ! My sensor in hardware tied to SPI5, I cant use any other SPI, but now I don't getting any response in callback then I use SPI5, systick stopped to work too until I switched to new timer, I dont know where is the problem, maybe cubeMX have some cache and use when generating code, maybe there is some relationships, but I getting problems almost everywhere, cubeMX and cubeIDE is updated.
How to find problem there ?

How and where to delete cache, settings or everything else so that bad settings will not generate again ?

[Bob S]

Without posting parts of your code we can't tell for sure.  But it sounds like you have some code that is either getting stuck in an interrupt handler, this preventing other, lower priority interrupt from being serviced.  Having systick stop incrementing is a big clue.

Remember that callback functions are called from the interrupt handler.  That means you can't do anything that "blocks" or takes a long time to complete (where "long time" is long compared to interrupt intervals).

Please post relevant portions of your code (not as attachments, but pasted in the chat using the "</>" code buttons.  Including callbacks.

[EDIT] Are you using an RTOS (FreeRTOS, ThreadX/Azure, Zephyr, etc.)?

[TDK]

The best solution would be to take ownership of your code and understand why things are not working. Stay on one thing rather than ping-ponging between different ones. Solve the SysTick problem--get it working, save code. Then add a timer, get it working, save code. Then add SPI, etc. If something stops working, diff the code to understand what has changed vs the code that previously worked. Be systematic.

You can blame CubeMX if you want, it may make you feel better, but it won't fix the code. If you think there's a bug in CubeMX, provide an IOC file as well as a detailed explanation of what the problem is--what happens in the code vs what you expect to happen.

To address the immediate question: IOC file and CubeMX doesn't have a cache. You must generate code after changing something for the code to be updated.