I have a single core project where I need to turn on the capture and the match functions on timer 0.
I turn on the Capture 1 on Timer 0 and everything works fine. But as soon as I turn on the Match 1 with interrupt. I get a hard fault. When I step through the code I can't find where the hard fault is actually generated. Stepping through the code I get no hard faults.
The code is also running a USART (USART2) in polling mode to transmit some data.
 
					
				
		
 Sabina_Bruce
		
			Sabina_Bruce
		
		
		
		
		
		
		
		
	
			
		
		
			
					
		Hello Safi,
I've tried replicating the hard fault like you mentioned with no luck.
This is what I did to try to reproduce the behavior.
I'm using MCUXpresso IDE v10.3.1 [Build 2233] [2019-02-20] and the SDK Version 2.5.0.
I have imported the lpcexpresso55s69_ctimer_match_interrupt_example and used this as a base. I deleted the main source file and copied the portion you provided. I also imported the missing drivers such as the fsl_usart. I also made sure to include the proper drivers in the main source file.
Once the project was built I tried both stepping through the code(F6) and running the session (F8), but neither way caused a hard fault.
Let me know if you have any observations over what I've done so I can continue to assist you.
Best Regards,
Sabina
No. sprintf is not the entire issue.
I noticed something.
static ctimer_callback_t *s_ctimerCallback[FSL_FEATURE_SOC_CTIMER_COUNT] = {0};
Where FSL_FEATURE_SOC_CTIMER_COUNT = 5
This seems incorrect since callbacks should be 8 (4 for matches and 4 for captures if I am not mistaken).
Could this be a cause of the fault?
 
					
				
		
 Sabina_Bruce
		
			Sabina_Bruce
		
		
		
		
		
		
		
		
	
			
		
		
			
					
		I've added some sprintf and still not hardfaults.
The FSL_FEATURE_SOC_CTIMER_COUNT is regarding the number of Ctimers available.
This would be the CTIMER0, CTIMER1, CTIMER2, CTIMER3, CTIMER4. So that number should not be changed.
When you copied the code to a different base project are you still getting a hardfault, if so are you able to detect it when you step through the code (or only if you run de debug session)?
Let me know, if so ill copy the code back(with my minor addons to test it) that you provided so you can test it out and see if the results are different.
Best Regards,
Sabina
Hi Sabina,
I think I was initially wrong that it was the interrupts. I now believe it is some issue with the sprintf.
I copied the code to a no hosted project and used the sprintf and USART combo. As soon as I hit the sprintf, I get a hard fault.
I am using Newlib so I believe it should support sprintf? especially with floats?
Regards,
Safiullah Hussaini
