STM32 not executing firmware

[dmwahl]

I have a project that includes a STM32L152. It has been built up before, and had no major issues so I assume that the design is at least functional (I did not design it myself, although am familiar with it). The firmware file has been confirmed working on another copy of the hardware, so I know it's not a firmware issue. I can communicate with the STM32 via my ST-Link V2 programmer, load firmware, and pull the serial number off it so I conclude that at the very least it's functional.

The problem I'm having is that the firmware doesn't seem to execute at all. I've checked a few things, but am fairly unexperienced with the STM32 line (used to 8-bit Atmels mostly). I could just build another board, but I'd rather figure out what's wrong first. Schematics and BOM are at https://endless-sphere.com/forums/viewtopic.php?f=14&t=57673&start=25#p1016913 for reference.

1. I've verified the firmware has loaded properly (disconnected the programmer, removed power to board, reconnected and everything still has the proper checksum). Same hex file runs fine on other copies of the board.
2. I've checked that the clock input to the MCU looks good (12Mhz, 0.4Vmin, 2.2Vmax, nice clean sine wave. See attached image).
3. Reset line is high
4. I've loaded a basic "LED blink" firmware that I know is good since it works on other hardware, and no blinking.
5. Supply voltage is stable at 3.0V (linear reg fed by USB)
6. Checked that all the components are soldered correctly, no bridges or open pins anywhere.

Any suggestions?

[Rerouter]

this part of the datasheet stands out to me,

Boot modes
At startup, boot pins are used to select one of three boot options:
• Boot from Flash memory
• Boot from System Memory
• Boot from embedded RAM
The boot loader is located in System Memory. It is used to reprogram the Flash memory by
using USART1 or USART2. See STM32™ microcontroller system memory boot mode
AN2606 for details.

[jnz]

Boot pin needs a 10k resistor to ground iirc, to boot from flash.

[bingo600]

Isn't the HSE supposed to be 3v3 Cmos level ?
I think i read it had to be on a F0'

But then with 2v2 you might be home free.

What are you using to generate the HSE with ?
I'm interested because i have a F0' that i need to drive with an external HSE , from an OCXO , and need to "amplify the signal"


/Bingo

[eck]

Boot pin needs a 10k resistor to ground iirc, to boot from flash.

Both BOOT0 and BOOT1 (shared with PB2) should be pulled down. The schematics look good from that perspective. I guess the problem calls for a debugger...

[gamalot]

If you use Keil's IDE to develop your firmware, try to erase full chip before download and see if it works.

[richardman]

If the same hex file works on other boards of the same design, and if there does not appear to be solder bridge, then the most unlikely become possible - you just may have a bad MCU. I have seen reports like this from customers.

[dannyf]

I would check power, ground, reset pin, and the boot0/1 pins first, and compare them with the working board.

[andyturk]

When the mcu comes out of reset, the default is for it to use the internal RC clock. The fact that your 12MHz crystal is doing something suggests that the code got at least as far as clock configuration.

[Jeroen3]

^^ If the HSE works, it's enabled. It's never enabled by default unless you've programmed OTP's.

Attach the debugger, go to assembler view and start stepping. Make sure "go to main" is unticked.
Put a breakpoint in reset, start of main, the default handler and the hardfault handler. (should fit max 4 breakpoints)

[dmwahl]

Thanks for all the replies so far. I'll try to respond to all of them

I figured that if the HSE is working, the mcu has at least started executing code. I'll add some breakpoints and see if I can figure out where it's stopping. Datasheet states 0.7xVdd for the min HIGH level and 0.3xVdd for the max LOW level so I'm at least within recommendations there.

BOOT0 is tied direct to ground, and as I recall with BOOT0 at ground, BOOT1 is a "don't care".

I've tried all manner of options programming, tried erasing the chip prior to program, checksum after cold boot, reduced programmer frequency. Nothing seems to help. Given the checksum is correct, I suspect my problem is elsewhere.

If it gives a clue somehow, when I first start up the attached LCD flashes a few segments where I know there should be text, then goes blank. Almost as if it's starting to run then stopping which seems consistent with the fact that the HSE is at least working. I hate to do it, but I might just pull the mcu off and tack some wires onto the I2C pins and a nucleo board to see if I can communicate that way. Ugh.

[janoc]

Flashing the code to a wrong address? Had that happen before ... Or it is encountering some hard fault and is stuck in a handler. Attach a debugger and step, as said by the others.

[dannyf]

"
If it gives a clue somehow"

Seems to me you can benefit from a blinky right now.

[dmwahl]

I haven't had much time to work on this lately, but I did probe the RTC clock as well and noticed that while it's oscillating at the correct frequency and is a nice sine wave, the peak voltage is only around 600mV, well below the requirement of 0.7Vdd spec'd by the datasheet. Could that be a reason for the apparent lock-up? I don't have a specific need for the LSE oscillator, so I can easily remove/disable it if it's a potential cause. I know it takes longer to start up than the HSE, and watching the scope the startup time for the LSE is about the same amount of time that the LCD powers up for. I'm trying to avoid modifying the firmware code if possible here.

Also, can I debug without the SWO line connected? I do have the official ST-Link V2, but never used it as a debugger.

[dannyf]

F1 is known to have difficulties getting lf crystals to oscillate - not enough drive.

Not sure about L1.

And not sure why it is tied to your code not being executed.

[Jeroen3]

You don't need the SWO pin. You need SWCLK (Serial Wire Clock) and SWDIO (Serial Wire Data In Out).

If the crystal fails to generate valid clock, the switchover to HSE won't be completed and the sysclk will remain on HSI.
Your startup code most likely uses an while( !HSE_Ready ){} approach and will therefore never pass the clock initialization.

[richardman]

If the crystal fails to generate valid clock, the switchover to HSE won't be completed and the sysclk will remain on HSI.
Your startup code most likely uses an while( !HSE_Ready ){} approach and will therefore never pass the clock initialization.

The ST code (usually) has a timeout, and break out of the test loop, but yes, a check with the firmware code is definitely in order.

[dannyf]

Turn on mco.

[dmwahl]

What will turning on MCO do for me since I know that the HSE is working? Will it not output the clock signal if the application is locked or stuck in a wait loop?