SERCOM USARTs causing hard fault on SAMC21

Go To Last Post
4 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi all,

 

Fairly new to Cortex M recently... I've come across an issue whilst working with a SAMC21J18A (on the devices Xplained board) - where fast bursts of incoming traffic on the various USARTs are causing a Hard Fault exception in the core. All execution hangs, and if I break during a debug session I can see I'm stuck in a while(1) inside of Dummy_Handler.

 

Note the volume of traffic doesn't cause the fault, only when large bursts of data come in fast. The core is running at 48MHz, the USARTS at 115200 baud - and are writing to/reading from FIFOs that simply overwrite if full, i.e. these modules execute the same instructions regardless of speed of incoming traffic.

 

Dummy_Handler appears to handle unused IRQs based on it's documentation (which in itself is interesting, because I have only 3 interrupts enabled; SysTick to drive my task scheduler, and SERCOM3 & 4 to handle USART traffic - all of which are handled) - so I've added in a call to CMSIS's __get_IPSR() which returns 3, i.e a Hard Fault.

 

CMSIS documentation on __get_IPSR()

 

/**
 * \brief Default interrupt handler for unused IRQs.
 */
void Dummy_Handler(void)
{
		volatile uint32_t phantom;
		phantom = __get_IPSR();
        while (1) {
        }
}

 

There are two USARTS in use in this application, one communicating with another device - the other echoing what's incoming/outgoing on the first USART out to a PC terminal). These are interfacing with FIFO modules that I've used extensively in other applications before.

 

If I take a look at NVIC.ISPR when hung up, there are two interrupts set - SERCOM3 and SERCOM4 - both are handled (otherwise my two USARTs wouldn't be working at all, as all communications in this application are handled using interrupts).

 

How do I go about finding out more about what's causing this hard fault, given it doesn't actually appear to be an unhandled interrupt. The Call Stack unfortunately just shows the line (268) where Dummy_Handler exists.

 

>	xxx.elf! Dummy_Handler Line: 268
 	xxx.elf! <signal handler called> Line: 268
 	xxx.elf! exception_table Line: 268

In addition, the only interrupt bits set in both SERCOMs are a combination of DRE, TXC and RXC - all of which are handled. No frame errors etc.

 

 

Last Edited: Mon. Nov 15, 2021 - 07:53 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

After some more debugging - we've found the root cause to this issue; an array overflow in the application layer of the software, to which the serial modules are passing data to. The application was running several hundred indices past the end of an array - so a hard fault makes sense, giving we were reading to and writing from out of bounds elements.

 

But - the questions above still stand, assuming the root of this problem was still unknown - how would I go about hunting down the cause of a hard fault in a little more detail? I've just started reading The Definitive Guide to ARM® Cortex®-M0 and Cortex-M0+ Processors, so I'll post back if I find anything useful in there.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

duckduckgo trace cortex m0 hard fault?
Perhaps something like: https://www.freertos.org/Debuggi...

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jtw_11 wrote:
How do I go about finding out more about what's causing this hard fault

https://community.arm.com/support-forums/f/embedded-forum/3257/debugging-a-cortex-m0-hard-fault

 

(includes the one linked by  ezharkov  in #3)

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Thu. Nov 18, 2021 - 09:55 AM