2025-01-19 01:27 AM - edited 2025-01-19 02:28 AM
Hi,
i have an issue, where i implemented using DMA. The DMA works seemingly without issues, but when debugging and using the start/pause buttons, the hard fault happens.
Would the be a smart way to *simulate* a pause/start of a debug session??
EDIT:
I found out, that this issue only happens when the interrupt is activated:
volatile uint16_t adcArray[12]
void DMA1_Channel2_IRQHandler(){
ADC_TEST_2_ON
// Transfer complete
if( READ_BIT(DMA1->IFCR, DMA_IFCR_CTCIF2) ){
DMA1->IFCR |= (DMA_IFCR_CTCIF2); // Clear bit transfer complete
// tempFETBits = 0;
// battVoltBits = 0;
// throttleBits = 0;
// buttonSensBits = 0;
tempFETBits = adcArray[0];
ADC_TEST_2_OFF;
}
// Transfer error
if( READ_BIT(DMA1->IFCR, DMA_IFCR_CTEIF2) ){
DMA1->IFCR |= (DMA_IFCR_CTEIF2); // Clear bit
//TODO: save event
while(1);
}
ADC_TEST_2_OFF;
}
2025-01-19 02:45 AM
Debug the hardfault. Check content of the fault registers (SCB_CFSR and its components). If you are using an IDE which provides you a backtrace (call stack, whateverisitcalled), look at the point where the fault handler was called (taking into mind that imprecise error happens a couple of instructions before that point), in mixed C-disasm view, to see what was the cause of fault.
JW
2025-01-19 03:44 AM - edited 2025-01-19 03:44 AM
In the meanwhile, i found out, that the hardfault only happens, when i resume out of the DMA handler. But if it was resumed from the DMA handler, while other handlers happend when the DMA handler was active, then this problem does dont happen.
I dont see a problem with my program, so i would just try to work without DMA interrupt. The hard fault was a INVPC.
I wonder if it would haunt me at a later stage?
2025-01-19 09:44 AM
>>I wonder if it would haunt me at a later stage?
What part?
Suggests you're DMA is trashing, or servicing routines are trashing the stack.
Would avoid using auto/local for DMA buffers, and context/scope can change.
Watch alignment and abutting structures, especially when using cache management. The CM7 expecting 32-byte alignment.
Perhaps also watch maximal stack depth in worst-case scenarios.
2025-01-19 09:52 AM - edited 2025-01-19 09:53 AM
@Tesla DeLorean wrote:What part?
The part is the whole issue itself.
Suggests you're DMA is trashing, or servicing routines are trashing the stack.
I have commented out everything in the interrupt: Still it is creating this issue, under the very specific condition described above.
Essentially this Interrupt is doing nothing (except clearing the flag and causing the issue).
2025-01-21 08:51 AM
@Tobe wrote:when debugging and using the start/pause buttons, the hard fault happens.
Remember that halting debug is intrusive.
Things like timers can carry on counting, UARTs can carry on receiving while the CPU is halted - but the CPU then won't be able to action interrupts in a timely manner.
I don't know about DMA, but maybe it can keep running, but stuff falls over when the CPU is halted and unable to handle completion...?
In some cases (eg, watchdog), there are options to control what happens during a debug halt - have you checked for such options relating to DMA?
@Tobe wrote:I found out, that this issue only happens when the interrupt is activated:
I'm not sure if that supports the above hypothesis or not ... ?
2025-01-21 09:06 AM
Which STM32 part is this thread discussing?
DMA has unfettered access to memory. Sanity check what address/lengths it's being handed. Perhaps put guard zones front/back of buffers. The size is past to the DMA controller as transfer UNITs, not bytes
INVPC suggests it's popping some context, PC/LR off the stack. Or some corrupt pointer / call-back where it's transferring control. Thumb Code expects the PC to have an ODD address (Bit0=1)
2025-01-21 09:15 AM
Its a G431KBT6
2025-01-21 09:20 AM
Yes, its quite complicated. Even worse, when you have to debug the debug session!
Where would i found these options for debug halt?
2025-01-21 09:29 AM
@Tobe wrote:Where would i found these options for debug halt?
In the Chip's Reference Manual