STM32L4R5ZI is hitting "HardFault_Handler" after

[KM.8]

Hello,

I am using the stm32L4R5ZI Nucleo board with a MT9V024 camera sensor and a USB drive.

I am using the HAL/STM32cubeMX library for the DCMI functionality using 10-bit parallel data with HSync and VSync as well (13 wires with 10-bit+Vsync+Hsync+DCMIclock).

MT9V024 is a 752x480 monochrome sensor.

The MT9V024 sensor is outputting 8-bit parallel images at 66 fps (frames per second), but I just want to capture a single frame and the DCMI is set to "DCMI_MODE_SNAPSHOT".

The issue I am having is once I call "HAL_DCMI_Start_DMA()" in main.c, the interrupt "DMA1_Channel1_IRQHandler()" is called and causes "HardFault_Handler".

I have tried to pull Hsync and Vsync to see if the interrupt is the issue.

When the Vsync and Hsync wires are removed, the DMA1_Channel1_IRQHandler() interrupt is no longer called (I assume DCMI is looking for Vsync start of image).

This also verified that the camera data is making it to the stm32L4 controller.

I checked the "uint8_t cameraBuffer[]" of size 360960 pixels and is filled with NULL values.

I attached my code to this point, but I am not sure how to debug the "HardFault_Handler".

Google searches yield accessing error registers, but I am sure that I am doing something VERY BAD and I am not sure how to approach this issue.

I also included a picture of the test setup with the camera and microcontroller boards.

Could someone please convey what I am doing wrong with DCMI/DMA/USB or how to debug the "HardFault_Handler"?

Thank you,

Keith

[Tesla DeLorean]

>>how to debug the "HardFault_Handler"?

Well here we have the handler do something more useful than spin in a while(1) loop.

The trick is to understand where the fault is occurring, and the register states, so you can inspect the code and come to some conclusion about how it got there, or what it is touching. Look at a disassembly listing, look at the .MAP

Does it always fail at the some spot with the same conditions? Does it occur due to the interrupt.

Are structures properly initialized? Are malloc() calls and other pointer checked for viability.

Instrument the code so you know how it is flowing and interacting.

//*************************************************************************
 
/* In Keil in startup.s
 
HardFault_Handler\
 PROC
 EXPORT HardFault_Handler
 
 ; Determine correct stack
 
 TST lr, #4
 ITE EQ
 MRSEQ R0, MSP ; Read MSP (Main)
 MRSNE R0, PSP ; Read PSP (Process)
 
 MOV R1, R4
 MOV R2, R5
 MOV R3, R6 ; [e-mail]
 
 EXTERN hard_fault_handler_c
 B hard_fault_handler_c
 ENDP
 
*/
 
 
//*************************************************************************
 
void hard_fault_handler_c(unsigned int * hardfault_args, unsigned int r4, unsigned int r5, unsigned int r6)
{
 printf ("[Hard Fault]\n"); // After Joseph Yiu
 
 printf ("r0 = %08X, r1 = %08X, r2 = %08X, r3 = %08X\n",
 hardfault_args[0], hardfault_args[1], hardfault_args[2], hardfault_args[3]);
 printf ("r4 = %08X, r5 = %08X, r6 = %08X, sp = %08X\n",
 r4, r5, r6, (unsigned int)&hardfault_args[8]);
 printf ("r12= %08X, lr = %08X, pc = %08X, psr= %08X\n",
 hardfault_args[4], hardfault_args[5], hardfault_args[6], hardfault_args[7]);
 
 printf ("bfar=%08X, cfsr=%08X, hfsr=%08X, dfsr=%08X, afsr=%08X\n",
 *((volatile unsigned int *)(0xE000ED38)),
 *((volatile unsigned int *)(0xE000ED28)),
 *((volatile unsigned int *)(0xE000ED2C)),
 *((volatile unsigned int *)(0xE000ED30)),
 *((volatile unsigned int *)(0xE000ED3C)) );
 
 while(1);
}
 
//*************************************************************************

[AvaTar]

Here is a good read about the system registers, and hardfault causes:

http://www.keil.com/appnotes/files/apnt209.pdf

Would have set a direct link, if there was such thing in this wondful editor...

[KM.8]

I did a "Clean Build" and "Build All" and I am no longer inside the Hard_Fault_Handler.

I am still getting NULL values in my "cameraBuffer[]" array.

Does anyone have any experience debugging DCMI and DMA?

I do not know why the following call is not putting data in the "camerabuffer[]" array (from main.c, line 166/167.

hal_status = HAL_DCMI_Start_DMA(&hdcmi, DCMI_MODE_CONTINUOUS, (uint32_t)cameraBuffer , CAMERA_FRAME_BUFFER_SIZE);

It seems that there is something not right with the stm32cubeMX linking DCMI to DMA, but I am not sure.

I am following the stm32L496G-Discovery as an example project, but it is not an identical match for saving to a USB drive.

I am referencing a STM32F769I_EVAL example in the "camera" folder for how to use the USB with a DCMI interface.

[KM.8]

Inside the "HAL_DCMI_Start_DMA()" function, it calls a function called "DCMI_TransferSize()"

Should I be using 32-bit DMA transfers or 8-bit transfers? Does it matter?

I attached a picture of the stm32cubeMX DMA/DCMI configurations.

[KM.8]

..