# STM32F0 - interrupt/breakpoint not working on certain hardware

OK I realise this sounds like a dumb/noob question but please do read it through before calling me an idiot - at this stage I'll gladly take it if you can spot where I've gone wrong!

The scenario:

We have an existing working PCB design using an STM32F051K4, multiple boards have been built & programmed and all have performed as expected.

Populating a new bare PCB with just the micro, its associated smoothing/decoupling caps, and BMP/SWD (debug/ICP) header the SysTick interrupt would not fire and breakpoints set in the debugger would not trigger (setting break main would never trigger!).

I have tried several fresh boards, micros from two different batches, getting a more skilled colleague to solder the board... and none of them work!

The complete environment:

Boards are a fairly basic PCB with STM32F051K4U6 / K6U7 (UFQFPN32 package) microprocessor plus a couple of 100n / 4u7 capacitors around the 3v3 rail.

In the test setup, the board is powered, programmed, and debugged by a Black Magic Probe (BMP) via GDB.

The firmware is based on generated code from STM32CubeMX using low-level (LL) libraries, compiled in SW4STM32, initialising only the basic system clock / systick and setting all GPIO pins to analogue (floating / High Z).

The pseudo-code of the entire thing is as follows - standard init purely as-generated by CubeMX:

LL_Init();
SystemClockConfig(); // Include SysTick IRQ
LL_SYSTICK_EnableIT(); // Enable the SysTick interrupt
MX_GPIO_Init();
while(1)
{
count++;
//optionally toggle a pin here to prove it's running
}


The SysTick_Handler simply increments a global ticks variable.

Then the main loop literally just increments a count while we wait for the SysTick that never comes.

The code compiles, and via GDB/BMP downloads and runs - in the "good" board I can set break main and break SysTick_Handler and both will be triggered as soon as the board is run.

In the "bad" boards the breakpoints are never tripped and the interrupt never fires (ticks remains 0) despite the main loop counting upwards (and, if I toggle a pin in main(), I can see it toggle). However, the micro can be stopped and single-stepped and GDB reports no errors setting breakpoints. programming, etc.

I have checked the interrupt vectors in the startup code and they are as expected.

I am really stumped by this, my best-guess is there's some pin that needs to be pulled up or down or something, or perhaps some extra power rail smoothing is needed somewhere that the fully-populated board introduces, but I would NOT expect the micro/debugger to be that sensitive?

I've checked and re-checked the code, the boards, the components fitted, the soldering job, and my sanity (TBC) to no avail.

Any ideas gratefully received at this stage!

Edit to address questions in comments (in order & as I can):

@ChrisStratton:

The binary is identical every time, from the working running board I am then detaching GDB, issuing BMP "power disable", swapping boards, "power enable", scan, re-attach, load the binary, run. Not touching the IDE at all.

Hard to be 100% sure the ground pad is soldered as it's under the chip in the UFQFPN32. All power pins (2x VDD + VDDA) are connected and have smoothing caps per the datasheet.

I have not (yet) tried other interrupts as I would have to write new code to interrupt from a GPIO pin for example.

I don't have a discovery board with this micro on so can't try that.

Linker & startup are generated by CubeMX for this part and are obviously working on the "good" board with no modification.

@SamGibson:

The "bare" board is minus peripherals such as MAX232, I2C EEPROM, external voltage regulator, etc. just has the micro, debug header, and power supply caps / relevant pullups (BOOT0, NRST) fitted.

I'm not currently in a position to post photos/schematics, I will if I can.

• Are you loading the same binary in each case? Can you verify with GDB on the running board that the vector table is in use, and that it contains the right address? Do any other interrupts work? What if you intentionally trigger a fault? Did you connect all the power and ground pins? What is your clock source? Can you run the code on a Discovery board? Are you sure your linker map and startup files are valid for the part in use? – Chris Stratton Nov 14 '18 at 17:58
• John, Hi - I didn't see an explanation of the hardware differences between your "full" working boards (all of them working?) and your "minimal" non-working boards (all of them not working?). Close-up photos of example boards from each group ("full" vs. "minimal"), as well as schematics would be helpful. Focus on differences - what is different / what has changed since the working boards were made? Without the answers from those questions (so this suggestion might not make sense), I suggest to add parts onto a non-working "minimal" board, to see if it then works as a "fully populated" board. – SamGibson Nov 15 '18 at 0:27
• Check supply voltage level and compare to working board. I've had STM32 running at around 2.8V from USB debugger (should have been 3.3V, but something was sinking voltage), the MCU was running but some weird things were happening occasionally. – wildfireheart Nov 15 '18 at 13:10
• Any QFN behaving in an odd manner should have the solder connections inspected under high power at an angle. Raise the microscope, crank up the power, and hold the board in your hand so you can look into the inside corner where package meets board at an angle. Video won't have the dynamic range, it needs to be optical and eyeball. Given the only ground is the pad, you should spend the $40 to get a hot air tool and desolder one to look for wetting. Also make sure the ground pad on the PCB is actually ground ;-) . And try the test of transplanting chips between good and bad boards. – Chris Stratton Nov 15 '18 at 15:03 ## 1 Answer Thanks for the update. Due to the restrictions which prevent supplying photos & schematics, I would follow the plan outlined in my earlier comment, in order to make progress, including: • Make a list of all the physical differences between the working "full" and non-working "minimal" boards, and their component parts including PCB, their sourcing, history/age etc. Also, measure the voltages at all possible nodes (even better to use a 'scope to view the waveforms - DMM measurements can be misleading) and compare them between the working and non-working boards. • Take a non-working "minimal" board and add components to it (testing after each step) until it is a "full" board. At some point along that process, it might start to work (e.g. breakpoints start to trigger) - since your "full" boards work, and that's what you are progressing towards. Investigate the last changes made just before that point, since whatever that change was, caused a change in the board's behaviour (in this case, from non-working to working). It's possible that the above step of converting a non-working "minimal" board, step-by-step, into a "full" board might not result in a "full" board which works. In that case, there must be one or more differences between the original "full" working boards, and the newly-made "full" but non-working board (otherwise, the newly-made board would also work - so there must be differences). Your challenge is to find them, using knowledge that only you have about the hardware of the two boards, the design, the sourcing of the components etc. • Another approach to consider, is to reverse the direction of the investigation: Start with a known-working "full" board. Then remove components from it, step-by-step, testing after each change, until it has only the same components as your current non-working "minimal" boards. Did that board stop working during this process? If so then, as in the process working in the reverse direction of changes above, whatever you just changed to cause that difference in behaviour (here, changing from working to non-working) is the point to investigate, using your knowledge of the hardware and the design etc. If you start with a working "full" board, and remove all the components to make it a "minimal" board and it still works, then there are one or more differences between your working "minimal" board, and your non-working "minimal" boards. Again, since you have them in your hands, you have more knowledge than we do about the differences. In that situation, I would also consider moving components, one at a time, from a non-working "minimal" board, to a working "minimal" board, testing after each change. Again, if/when the working board stops working, the last component that was moved from the non-working board, will tell you something about the cause of that change in behaviour. • Of course there are risks of getting misled during this process, due to practical issues like damaging components during transfer from one board to another, soldering problems (shorts or bad joints) etc. etc. Therefore after any change in behaviour during testing, it's important to consider the (hopefully small, but non-zero) possibility of an "own goal" during the troubleshooting. • The first thing I'd transplant would be to swap the MCUs between working and non-working boards and see if the problem follows the chip or the board. A nightmare with an iron but pretty easy with hot air, and being QFN that is hopefully already in use. Also, erase and re-program a good one (hopefully enough are available to risk one) – Chris Stratton Nov 15 '18 at 15:13 • @ChrisStratton - Hi, yes, good points. I'm leaving the OP to decide the fine details about the order of component changes, as only he knows the difficulties involved with his equipment, his boards, his available MCUs to risk them etc. When I've used similar approaches in the past, it's been impossible for anyone outside the team to decide such fine details, as they don't have enough knowledge of the constraints. In this case, we're outside the OP's "team" :-) As you say, swapping the MCUs might even be the last thing to do, if a hot air station isn't available. – SamGibson Nov 15 '18 at 15:22 • If hot air isn't available, then the soldering of this only-grounded-through-the-pad QFN chip is highly suspect to begin with. And no one's time is worth so little as to make doing this the hard way to save$40 in tools sensible. – Chris Stratton Nov 15 '18 at 15:30
• Being honest, the more you guys say it the more I'm doubting the QFN centre pad is soldered down properly - we do have hot air & microscopes so I'll have a play around and see if I can sweat one into working. – John U Nov 15 '18 at 15:37