2025-07-12 12:09 AM - last edited on 2025-07-12 1:33 AM by Andrew Neil
2025-07-12 1:31 AM
Perhaps look at and show the code that's running on the part.
The generated code and the print output routines will be far more informative as to why it's not working as expected.
Definitely 32-bit, inspect registers with debugger.
2025-07-12 1:48 AM
Ok, thank you. Here I'll ask my friend about the code that runs in this part.
In this case, it doesn't necessarily mean the sector has gone bad, does it
2025-07-12 2:05 AM
>>In this case, it doesn't necessarily mean the sector has gone bad, does it
I don't understand what you mean.
Show the generated code, the configuration screens aren't helping me understand the source of the problem.
Make sure you're not reading the TIM2->CNT value into a smaller variable and truncating.
2025-07-12 5:17 AM - last edited on 2025-07-12 7:57 AM by Tesla DeLorean
void HAL_TIM_IC_CaptureCallback(TIM_HandleTypeDef *htim)
{
if(htim->Instance==TIM2)
{
if(htim->Channel==HAL_TIM_ACTIVE_CHANNEL_1
{
up_value=HAL_TIM_ReadCapturedValue(htim,HAL_TIM_ACTIVE_CHANNEL_1);
up_counter=__HAL_TIM_GET_COUNTER(htim);
This is the latest test for capturing peripherals, with no captured values at all
2025-07-12 5:19 AM
In the test of capturing peripherals, both upvalue and downvalue should have been captured, but the corresponding values were not obtained at all, they were both 0. That is to say, there is no corresponding hardware for capturing
2025-07-12 5:21 AM
On a microcontroller with a frequency of 480M, when running this code, the interrupt can only run up to 70K
2025-07-12 6:54 AM
Clock-tree setting shows: cpu running at 64 MHz. Why this ?
>On a microcontroller with a frequency of 480M, when running this code, the interrupt can only run up to 70K
Seems you run the 480M cpu at 64M . right ?
2025-07-12 6:59 AM
Show the variable definitions
2025-07-12 7:52 AM
super screens and code parts, but stil dont show if your up_value and other is realy
volatile uint32_t up_value...