cancel
Showing results for 
Search instead for 
Did you mean: 

HardFault Handler changing Clock Frequency

davidec
Associate III

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;

}

 

1 ACCEPTED SOLUTION

Accepted Solutions

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
Up vote any posts that you find helpful, it shows what's working..

View solution in original post

2 REPLIES 2
TDK
Guru

> 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".

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
Up vote any posts that you find helpful, it shows what's working..