title: SysTick interrupt does not fire if GDB attached before it is enabled
body: <p>I have an ATSAMD21E18A micro that I am using with semi-hosting. In order for the semi-hosting to work, GDB needs to be "attached" before the first bkpt instruction. On the other hand, I have inexplicably found that the SysTick interrupt will not fire if GDB was already attached when I configured it. If I want to the SysTick interrupt to fire, I have to perform a reset (power-off via a button) and tell GDB to continue when it hasn't yet configured the micro (that is, it hasn't sent breakpoints over or anything else), and then hit Ctrl-C to initialize debugging mode after the SysTick configuration but before we get to <code>initialise_monitor_handles</code>.</p>
  
  <p>I have verified that the start function is <em>only</em> copying over the relocatable data segment, zeroing the zero segment, and setting the right initial stack pointer value. We are writing our code without libraries like CMSIS.</p>
  
  <p>Also I can confirm that I have no issues when the debugger is not attached (JLinkGDBServer through an Atmel SAM-ICE), besides needing to remove the semi-hosting stuff.</p>
  
  <p>Also, the SysTick COUNT does still correctly count even when the interrupts themselves don't fire. Also the SysTick pending interrupt bit PENDSTSET in ICSR, is in fact set when this happens.</p>
  
  <p>My code follows:</p>
  
  <pre><code>int main()
  {
      // enable system timer interrupt
      SYS_TICK-&gt;STATUS = 0; // (CSR)
      SYS_TICK-&gt;PERIOD = 48000; // (RVR) fire at 1khz for 48mhz clock
      SYS_TICK-&gt;STATUS = 0b111; // use processor clock, w/ interrupt, and enabled
      SYS_TICK-&gt;COUNT = 1; // (CVR) avoid high unknown value
  
      // dumb busy loop
      util_idle_ms(2000); // &lt;&lt;&lt; I hit Ctrl-C to break here!
  
      initialise_monitor_handles();
  
      // ... more system initialization and everything else
  }
  </code></pre>
  
  <p>I have seen some similar seeming questions here on StackOverflow, but they seemed to be too vague to get good answers.</p>
  
  <p>Edit:
  Here are possibly relevant register values taken during the busy loop for the run that doesn't call the SysTick handler (no hard reset, GDB attached before SysTick configured):</p>
  
  <pre><code>SYS_TICK_CSR/STATUS: 0x10007
  SYS_TICK_RVR/PERIOD: 48000
  SYS_TICK_CVR/COUNT: 5245 (varies of course)
  NVC_ISER: 0 (and we expect this since SysTick is considered an exception, and not an interrupt)
  DHCSR: 0x30003/0x1030003 (C_MASKINTS is not set; I've seen both values show up)
  ICSR: 0x400f00f (it really wants to run the SysTick handler)
  PRIMASK: 0
  xPSR: 0x2100000f (IPSR is 0x0f/SysTick)
  </code></pre>
  
  <p>And for the run that calls the SysTick handler just fine (hard reset with GDB attaching after SysTick configuration):</p>
  
  <pre><code>SYS_TICK_CSR/STATUS: 0x10007
  SYS_TICK_RVR/PERIOD: 48000
  SYS_TICK_CVR/COUNT: 16892 (varies of course)
  NVC_ISER: 0
  DHCSR: 0x10003/0x1030003 (I've seen both values show up)
  ICSR: 0 (SysTick handler already run)
  PRIMASK: 0
  xPSR: 0x2100000f
  </code></pre>
  
  <p>So the register values here do not yet seem to reveal anything new to me... Please help inform me of other potentially relevant registers to check!</p>
  
  <p>Just for interest, the reason this is important to me is because I have gotten gprof to work on this chip, based on <a href="https://mcuoneclipse.com/2015/08/23/tutorial-using-gnu-profiling-gprof-with-arm-cortex-m/" rel="nofollow noreferrer">https://mcuoneclipse.com/2015/08/23/tutorial-using-gnu-profiling-gprof-with-arm-cortex-m/</a>
  And although I do have to hit Ctrl-C at just the right time after a hard reset, it does work like this!</p>
  
  <p><strong>Edit</strong>
  I have found that I had a misunderstanding where I thought running <code>load</code> in GDB performed a soft reset. I have since found that although it returns execution to reset vector, various peripherals and other registers are not in fact reset. If I perform a soft reset in GDB with <code>monitor reset</code> then I don't need to Ctrl-C during a delay to attach GDB and both SysTick and SemiHosting will work.</p>
  
  <p>The problem occurs when SysTick is configured and then <code>load</code> is run in GDB, without an explicit hard or soft reset. In this case, SysTick does not fire interrupts. Most of my debugging went like this, loading new code and immediately expecting it to work so I could evaluate it. Just running <code>monitor reset</code> is a better workaround than before, but I still would prefer to know the reason for SysTick's misbehavior!</p>