Enabling interrupt is causes a hard fault

[jeet55]

enabling DMA interrupt is causing a hard fault
HAL_NVIC_EnableIRQ(DMA1_Channel1_IRQn);

[m98]

So I would suggest to just leave it disabled...
More details please.

[Psi]

Have you defined an interrupt handler for the DMA interrupt?

[jeet55]

yes i have and i also called the HAL IRQ handler in it

[newbrain]

Jeet55,
as I said last time I answered you, please help us to help you.

We are not psychic - at least, not me.

We don't know:
1. Which MCU you are using (an STM32, given the HAL - but there are hundreds of them)
2. What you are trying to achieve
3. How your code looks like
4. What you tried and did not work
5. Your degree of familiarity the C language (given the previous question, there might be some basic lack there - how are we supposed to know?)

Extracting this information piecemeal is tiring for all involved.
A good strategy when something is not working, is reducing the code to the very bare minimum that exhibits the problem (we don't need to read hundreds of line of unrelated stuff) and share it, maybe also stating what changes you tried to make it work.

As much the HAL are often (and often with reason) maligned for being bloated, inefficient and cumbersome, they generally work.
I have used DMA a number of times myself with no major issues.

[SiliconWizard]

So I would suggest to just leave it disabled...

"Doc, it hurts when I press right here!
- Just don't do it, then."
 

More details please.

Yep.

[Siwastaja]

Most likely, vector table just doesn't contain the address of your intended handler. In other words, you haven't successfully configured the interrupt handler function to be an interrupt handler function for said interrupt. Just a guess, but likely.

Tell us how you configured the interrupt handler. Deep down, it's nothing more than placing the address of the function in a correct place near the beginning of the flash memory, but how this is done "automatically" depends on the toolchain.

yes i have and i also called the HAL IRQ handler in it

What does this mean? You don't usually call interrupt handlers in interrupt handlers as you are claiming to do. What even is HAL IRQ handler?

[ejeffrey]

Mostly likely what Siwastaja said: the vector table is incorrect.  Make sure the vector table is correct and make sure that you are looking at the right vector table.  Make sure you know if the MCU is configured to use the vector table in flash or if it has been copied to SRAM.

Another possibility is that the vector table is correct and handler is faulting.  Put a breakpoint or toggle a GPIO at the start of the handler so you can see if it is being executed.  If you want to single step, make sure your debugger is in "single step assembly" mode --

When you say "hard fault" do you mean that you have a debugger attached and see that it enters the hard fault handler?  Or do you mean that it "locks up"?  Could the interrupt handler be infinite looping instead of a fault?

[newbrain]

[good entry for the guessing game snipped]

yes i have and i also called the HAL IRQ handler in it

What does this mean? You don't usually call interrupt handlers in interrupt handlers as you are claiming to do. What even is HAL IRQ handler?

This is quite normal and correct when using the HAL, either manually or relying on MX Cube generated code.
As an example:

Code: [Select]

void TIM1_BRK_UP_TRG_COM_IRQHandler(void)
{
  /* USER CODE BEGIN TIM1_BRK_UP_TRG_COM_IRQn 0 */

  /* USER CODE END TIM1_BRK_UP_TRG_COM_IRQn 0 */
  HAL_TIM_IRQHandler(&htim1);
  /* USER CODE BEGIN TIM1_BRK_UP_TRG_COM_IRQn 1 */

  /* USER CODE END TIM1_BRK_UP_TRG_COM_IRQn 1 */
}
This is generated by MX Cube when one specifies to use interrupts with TIM1.
TIM1_BRK_UP_TRG_COM_IRQHandler is the real ISR, declared (and defined as weak) in the startup code, a vector table entry.
HAL_TIM_IRQHandler is the generic HAL handler, good for all timers, so it need the handle as parameter (and cannot be an IRS).

  I swear my message originally ended like this:

As much the HAL are often (and often with reason) maligned for being bloated, inefficient and cumbersome, they generally work.
I have used DMA a number of times myself with no major issues (but don't tell Siwastaja!)

Then I removed the bold part before posting

When you say "hard fault" do you mean that you have a debugger attached and see that it enters the hard fault handler?  Or do you mean that it "locks up"?  Could the interrupt handler be infinite looping instead of a fault?

What is the airspeed velocity of an unladen swallow?
I still think this game is unfair.

[SiliconWizard]

Yeah, the OP needs to show us enough of their code so we can help though.

But yes, with STM32's HAL, the typical use of ISRs is to call a dedicated HAL function within each handled ISR. For the DMA, that typically looks like this (taken from an example project from STM):

Code: [Select]

/**
* @brief  This function handles DMA interrupt request.
* @param  None
* @retval None
*/
void DACx_DMA_IRQHandler(void)
{
  HAL_DMA_IRQHandler(DacHandle.DMA_Handle1);
}
Of course you can always implement the ISR another way, but if you stick to the HAL, then this is usually the way to go.
Here the HAL_DMA_IRQHandler() will in turn do the housekeeping (clear the interrupt flag, etc) and call callback functions depending on the interrupt cause. So, has the OP properly defined those callback functions? Failing to do so may explain the crash.

[cv007]

>Failing to do so may explain the crash.

Except that hal code is going to check for null before it uses any callback. Its also probably pretty hard to assign the callback function(s) improperly via a hal function. Navigating your way through the hal dma functions may help to figure out what is going on, but I'm guessing the programming mode here is 'use the hal', not 'understand what the hal is doing' ('what the hal its doing' ?).

Not an stm32 dma expert, although I own an 031g, but imagine its not hard to setup dma incorrectly to where improper alignment throws a wrench in the gears and you end up in hard fault.