2019-12-09 10:54 AM
Hi all,
I'm trying to write a small program that will read the values from the temperature/humidity sensor. I will try to explain in detail what I have at the moment, but bear with me, I'm still a beginner in bare metal development.
I am using an STM32F103RB board, DHT22 temp/hum sensor, and FreeRTOS as middleware. The environment is STM32CubeIDE (eclipse based, arm gcc compiler, st-flash) with HAL driver and CMSIS BSP.
I have configured the TIM3_CH1/Trig on channel 6 and on pin PA6. Since the sensor is using a singel wire protocol, I am switching the mode of the GPIO from output to input and back in order to get the data in. The problem occurs when I call the HAL_TIM_IC_Start_DMA function. In it, the correct channel will be chosen, and the corresponding callbacks should be set. And that is exactly where I get the a hard fault interrupt. in particular at this specific line:
htim->hdma[TIM_DMA_ID_CC3]->XferHalfCpltCallback = TIM_DMACaptureHalfCplt;
in file stm32f1xx_hal_tim.c, line 2106.
I've added the handler in the HardFault_Handler, that gets the status of the registers, but, as a novice, that doesn't mean that much to me.
So, at the moment, I am stuck at this point.
I have included the entire project as an attachment, hopefully, it is not too much to ask, someone could have a look at it.
Thank you all in advance!
Vladimir
2019-12-09 11:16 AM
> I get the a hard fault interrupt. in particular at this specific line:
> htim->hdma[TIM_DMA_ID_CC3]->XferHalfCpltCallback = TIM_DMACaptureHalfCplt;
Single-step in disasm. Does the hardfault happen at the same instruction? Which one, and what's in its vicinity (best in mixed C/asm view)?
> I've added the handler in the HardFault_Handler, that gets the status of the registers, but, as a novice, that doesn't mean that much to me.
OK so post the info together with that above.
I don't Cube/HAL.
JW
2019-12-09 12:37 PM
Thank you kindly for the reply Jan.
After running the debugger in mixed mode with instruction stepping mode on, I can see that the interrupt always occurs on the same instruction:
2125 htim->hdma[TIM_DMA_ID_CC3]->XferHalfCpltCallback = TIM_DMACaptureHalfCplt;
080015e8: ldr r3, [r7, #12]
Oddly enough, the same instruction was executed for the previous C statment:
2124 htim->hdma[TIM_DMA_ID_CC3]->XferCpltCallback = TIM_DMACaptureCplt;
080015e0: ldr r3, [r7, #12]
and there was no problem at all.
I've attached an image with the listing of both C and asm code, and the contents of the registers right before executing the instruction in question.
2019-12-10 01:29 PM
After some digging around, the instruction that causes the hard fault (ldr r3, [r7, #12]) is nothing special at all, seems to be quite common throughout the code. But after assigning the first callback htim->hdma[TIM_DMA_ID_CC3]->XferCpltCallback = TIM_DMACaptureCplt; it seems to start causing issues. Since I don't really need to know when the data is half way received, I commented out assigning the first callback, just to see what happens. Assigning the second callback (TIM_DMACaptureCplt) succeeds, only to hard fault on the next such instruction.