2016-02-16 05:06 PM
Hello!
I am using a custom made STM32F302RE board. At the start of CAN initialisation, I wrote __HAL_CAN_DISABLE_IT(&hcan, CAN_IT_BOF); to disable all interrupts before initialising CAN. However, the codes go to hardfault handler after this. Why is that so? How do I rectify or solve this? Thanks!2016-02-16 07:27 PM
Somewhat indicative that the structure contains some junk or a broken pointer. Check that it is initialized.
Look at the instructions that are faulting, and the registers.2016-02-17 12:39 AM
Hi Clive,
I use the can pointer and have already verified that it is not broken. I am using the same set of codes for STMF302R8 custom made board and they work without going to handler but have issues on the STM32F302RE board.2016-02-18 03:45 AM
Hi mk.shasha,
May be a basic question: is the same project used as it is for both STM32F302RE and STM32F302R8?-Mayla-To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2016-02-18 06:06 AM
Ok, but it is a structure containing pointers to other structures, and regions of memory. Something in the chain is touching memory in a way that the processor objects too.
In Faulting the processor provides a host of context information for you to identify exactly what it is objecting too. Understand why it is angry, and work backward from there.For different processor models make sure the linker script reflects the sizes of the FLASH/SRAM accurately, and the stack/heap placement/size are valid.2016-02-24 11:14 PM
Hi Mayla,
I am not using the same project but the CAN codes for both firmware is very similar.2016-02-24 11:16 PM
Hi Clive,
Thanks a lot for your reply. I have verified and amended my heap and stack sizes/placements and also Flash memory address. However, I am still getting hardfault handler. I noticed that this error appears when trying to disable interrupts in CAN_IER register, in particular. But I am still not able to solve it. Any more suggestions?/2016-02-25 01:21 PM
Do you have a Joseph Yiu model Hard Fault handler, he's covered this in his books, here and on other ARM Forums. This can print out data to a terminal, and you can add other code to automate the reporting of your own system state. This can be easier than mining through the debugger, and stack frame data.
This would provide you with some register/fault statistics, examining those and the structures they point to you should be able to determine the nature of the fault.Based on the data you've reported so far, I'm inclined to think that the handle (and structure behind it) have been overwritten in some fashion. This could be from some errant pointer, memcpy's or background DMA.You should perhaps sanity check the code being used for the CAN_IER operation, ie make sure the pointer isn't NULL, and points to a valid range in RAM, and then iterate into the structure and check pointers in there. Ideally you want to be able to identify the condition that is going to precipitate the Hard Fault, and catch it before it happens. Once you've done that you need to work your way back through your code applying this test until you can contain/confine where the damage is occurring.