Hi, I reacently desgined my first custom STM32 hardware. I am using an STM32L432KCUx controller and the firmware i programmed it with does not seem to be executed.

[DKers.1]

I use Cube Programmer V2.4 and i am programming the chip using USB DFU mode. Its a simple firmware with a blinking LED to get to know how programming unsing DFU works. I tested the firmware on the NUCLEO L432kc board and there it seems to work fine.

There is no ST-Link or SWD Connector on the Hardware (I know thats not a smart move for new hardware).

First I tried Dfuse Demo but could not get the MCU out of DFU mode. With Cube Programmer the mcu seems to switch into execution mode but nothing happens.

I checked all connections and traces on the pcb with multimeter and osciloscope on the output pin to the LED.

Firmware is made using MBED Studio and MBED version 6.3.0.0

Thanks for your anwser in advance

[waclawek.jan]

Did you try to turn power off and then on again (i.e. perform power-on reset)?

JW

[Tesla DeLorean]

Make sure BOOT0 is pulled LOW

[DKers.1]

Thanks for your anwsers!

I tried the following:

Cube Programmer using USB DFU mode and selection "Run after Programming" -> Cube Programmer sucessfuly programs the chip then initiates start sucessfully but nothing happens.

Then i tried to see if BOOT0 is really pulled low (I am using a SPDT switch and a 10k resitor) -> it is pulled low -> then reset -> nothing happens

I powered down the board and waited until the power supply section capacitors where drained -> then pluged it in again and turned it on -> nothing happens

I compared the NUCLEO boards firmware on the flash using the built in st-link and it is exaclty the same as the firware file and the custom board chips flash, so the firmware is not the issue

I have a power indication LED on the board and i know the chip is powered correctly.

[waclawek.jan]

 > Firmware is made using MBED Studio and MBED version 6.3.0.0

Try native code. Blinky shouldn't be that hard to do in plain C without any "library". I have some simple examples on efton.sk/STM32.

JW

[Tesla DeLorean]

So perhaps your code is actually running?

Don't use the HSE / PLL, don't reconfigure the clocks and just leave it to run from the ~2.097 MHz MSI

Enable a UART, or a couple of GPIO you can drive in opposite directions. Perhaps toggle something you can scope.

Implement something in Error_Handler() and HardFault_Handler() so you can observe if it goes there to die.

[DKers.1]

Hi, thanks for the sugestions.

I have erased the MCUs User Flash and not configured any Clocks or PLL, just uploaded the original Firmware with Mbed as well as HAL firmware. (I have not tried blank C code yet). Still not working. Could not get any Peripheral to be driven or at least could not detect any change on the Peripherals. My coworkers are currently reviewing the Layout and Schematic to see if they might be faulty. We have also uploaded the original Mbed blinky to a different Product with an STM32 L4 Chip via USB DFU and there it seems to work fine. We compared the Flash memory and could not detect anything.

Hower i realised that wen den Device is connected vie USB DFU to the Cube Programmer the Flash memory Size is displayed as 512Kbytes even though i know that the L432KCUx only has 256Kbytes. I could not read any flash register above the 256Kbyte size anyways.

Orderd a simple PCB with all I/O pins of the L432kc exposed and an voltage regulator to test. The company has not used the L432KC chip so far but we have multiple products using L4, F4 and H7 chips and nobody in development can explain this behaviour yet.

I might also add that we have 10 instaces of the new L432kc Hardware and tested this on all of them with the same result.

[DKers.1]

Thank you all for your help,

For some Reason removing the HSE from the PCB kind of fixed the problem. After removing the HSE and its load Capacitors from all 10 sets of Hardware, the Software seems to function without a hitch on all of them (exept for limited IO Speed). The Team did not find any PCB issues and compared it to other L432KC designs. We decided to go with a different MCU that is already pretty well known with the Team to continue Product development.