Skip to main content
Associate III
October 18, 2023
Solved

HardFault Handler changing Clock Frequency

Good morning,

I am trying to read from adc two signals by first saving the signal with a certain clock frequency and then changing it using another one, i.e. changing the AHB clock divider. Going to debug it crashes on hard fault handler, regardless of the clock change but even trying to do two buffer reads and moving them to other variables it can't get into the second switch case. Any ideas? Thanks in advance

 

CODE

while (1)

{

u++;

switch(u)

{

case 1:

//SystemClock_ConfigDOWN();

for(i=0;i<ADC_BUF_SIZE/2;i++)

{

buf1[i] = (uint16_t)(adcBuf[i]&0x0000FFFF);

buf2[i] = (uint16_t)(adcBuf[i]>>16);

}

 

break;

 

case 2:

//SystemClock_ConfigUP();

 

 

for(i=0;i<ADC_BUF_SIZE/2;i++)

{

buf3[i] = (uint16_t)(adcBuf[i]&0x0000FFFF);

buf4[i] = (uint16_t)(adcBuf[i]>>16);

}

 

 

break;

 

 

default:

__NOP();

 

}

 

return 0;

}

 

This topic has been closed for replies.
Tesla DeLorean
Tesla DeLoreanBest answer
Guru
October 18, 2023

Look at what's actually faulting, ideally with something dumping context rather than a while(1) loop.

Determine if the point of failure is consistent or changing.

Speed changes should be relatively synchronous, for SYSCLK watch that you have adequate flash wait states, for APB/AHB watch that all the peripherals will shift gear, so speeds and baud rates will change, perhaps mid-word.

Watch current changes, check VCAP voltages/capacitance

Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..

2 replies

TDK
October 18, 2023

> Going to debug it crashes on hard fault handler, regardless of the clock change

Okay, so it has nothing to do with the clock change then. It's commented out in your code.

Those are pretty harmless statements. You don't show the definitions of the arrays. Perhaps they are writing out of bounds. You also don't mention a chip. Perhaps the memory access is not aligned.

Step through the code and figure out what statement exactly causes the hard fault and debug from there.

"If you feel a post has answered your question, please click ""Accept as Solution""."
Tesla DeLorean
Tesla DeLoreanBest answer
Guru
October 18, 2023

Look at what's actually faulting, ideally with something dumping context rather than a while(1) loop.

Determine if the point of failure is consistent or changing.

Speed changes should be relatively synchronous, for SYSCLK watch that you have adequate flash wait states, for APB/AHB watch that all the peripherals will shift gear, so speeds and baud rates will change, perhaps mid-word.

Watch current changes, check VCAP voltages/capacitance

Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..