On Cortex-M1, all non-recoverable faults will enter HardFault.
If the cause is associated to an instruction, then on entry to the HardFault handler, the memory location at SP + 24 will contain the address of the instruction that generated the HardFault; the cause of this is typically execution of an UNDEFINED instruction, or more likely (assuming your code is written in C) attempting to perform a mis-aligned memory access (for example as the result of an unpredictable cast in C, e.g, casting a char pointer to a word pointer and dereferencing), or, if you integrated the NIC yourself, generation of an AHB error (HRESP = 1). Other causes include the use of a BKPT without a debugger attached, or an SVC instruction at too higher priority (or on a Cortex-M1 without OS extensions).
Failing that, if you are using interrupts, then you need to ensure that the least-significant bit of the vector table entries are set, so as to execute Thumb code rather than in the unimplemented/unsupported ARM mode.
If the cause is associated to an instruction, then on entry to the HardFault handler, the memory location at SP + 24 will contain the address of the instruction that generated the HardFault; the cause of this is typically execution of an UNDEFINED instruction, or more likely (assuming your code is written in C) attempting to perform a mis-aligned memory access (for example as the result of an unpredictable cast in C, e.g, casting a char pointer to a word pointer and dereferencing), or, if you integrated the NIC yourself, generation of an AHB error (HRESP = 1). Other causes include the use of a BKPT without a debugger attached, or an SVC instruction at too higher priority (or on a Cortex-M1 without OS extensions).
Failing that, if you are using interrupts, then you need to ensure that the least-significant bit of the vector table entries are set, so as to execute Thumb code rather than in the unimplemented/unsupported ARM mode.