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.

[TheImmortal]

When working with code there is always the same things - setting pinout, enabling peripheries, then in code starting/enabling/using, finished with one then next... There problems is after code generation, now I stuck with SPI, I changed timers to others and started to work, except I cant change SPI to another one, I ques what there is some like cash which "remember" what is used before and keeps/doing something wrong with same options, helps only switching to other peripheries/interfaces, and its related to callbacks, callbacks just do not firing, I getting busy error then trying to start timer in interrupt mode using HAL_TIM_Base_Start_IT, but like I mentioned - after switching to another timer the problem is gone... Now I trying to deal with SPI5, nothing helps there, power cycle, PC reboot, cleaning, code regeneration, there is something more....

What happened - systick, SPI5, timers and everything worked well, after disabling FMC (because of other problems there where is missing default generated code) and some other peripheries/interfaces adjustments in cubeMX, systick on timer 18, SPI5, few (or all) timers where is used callbacks stopped working, I switched systick to use timer 6, other few timers to others and started to work, SPI5 for test to SPI6 and working, switching back to SPI5 and do not work !

Interesting thing what earlier I used timer 6 for systick, after some code generation it stoped to work, then I switched to timer 18 and solved problem, now after last stuck I switched back to timer 6, and now working, its like some memory/cache which erases after some time and problems with same periphery is gone !

I am not 100% sure if its cubeMX problem or maybe compiler ! Changing optimization, switching from debug to release does not change anything.

[TheImmortal]

Code doesn't stuck anywhere, just callbacks is not firing, if let say I trying to start timer in interrupt mode HAL_TIM_Base_Start_IT I getting busy error, but no crash or stuck anywhere, helping only switching timer o periphery/interface, I can switch timer, but cant switch SPI or other interface, changing priority do not work, for tests I do not used any RTOS.

[TheImmortal]

There is current ioc file, and some part of code with timer and spi callback:

HAL_TIM_Base_Start_IT(&htim11);

void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim){
  if (htim == &htim11) {
    if (IRresync == 0) {
      __HAL_TIM_SET_COUNTER(&htim11, 0);
      	if (HAL_SPI_Receive_DMA(&hspi5, buff, 164) != HAL_OK){
	  HAL_TIM_Base_Stop_IT(&htim11);
	}
      //HAL_GPIO_TogglePin(GPIOP, GPIO_PIN_6);
    }
  }
  if (htim->Instance == TIM6)
  {
    HAL_IncTick();
  }
}

uint8 testspi;
void HAL_SPI_RxCpltCallback(SPI_HandleTypeDef * hspi){
  if (hspi->Instance == SPI5) {
    //SCB_InvalidateDCache_by_Addr((uint32_t*)(((uint32_t)buff) & ~(uint32_t)0x1F), 164 + 32);
    testspi = buff[0] & 0x0F;
  }
}

[TheImmortal]

The problem is gone after creating new project and setting everything again - pinout, code and everything else, but still there is few cubeMX bugs which now is on STM side, I am not sure if cubeMX will not generate again with bugs, in any way, cubeMX is great tool, just some bugs takes to much time, and missing there normal hints about settings.