STM32L412 issues...

[re.wolff9]

I have built many STM32 boards and usually bringing them up is a snap.

This time I'm having trouble.... The chip is the 48-pin STM32L412CB.

When I boot in DFU mode (it does so by default) I get

dfu-util: Error during special command "ERASE_PAGE" get_status

When I hook up the STLINK-V2 debugger, I seem to get ONE chance where the chip claims to get programmed ok. After that I always get:

ERROR flash_loader.c: flash loader run error

but in both cases... nothing gets programmed.

In the debugger I can dump memory at 0x20000000: RAM and I see some sort of vector table. Probably that "flash loader" program that st-util uploads. When I dump the memory at 0x08000000 (Main flasn), then I see just empty flash. What could be wrong to cause this behavior ?

One of the things that I see happening is that it always boots to the bootloader. But this can be explained by the first word in main flash still being 0xffffffff. ...

Any suggestions on what to try or what might cause this?

[Uwe Bonnes]

Try connect under reset in the debugger. Perhaps the device uses deep sleep or remaps needed pins (SWJ, UART).

[Piranha]

> One of the things that I see happening is that it always boots to the bootloader.

Well... And what's with the state of BOOT0 pin?

[re.wolff9]

Yup, my first thought was too: I have a short near the pushbutton that can pull BOOT0 high. Nope, voltage there is quite zero.

The debugger has a working connection to the chip. It reads the ID, it reads: "RAM: 40k, flash: 128k" just fine. I can then dump memory areas like RAM and flash and get different answers. When I dump the option byte area, I get "unable to read... ". I haven't tried reading peripherals like a GPIO port. So I don't think it is that.

It looks to me as if the "write-to-flash" works like this: It downloads a small program and the data-to-be-programmed into RAM, and then executes the program in RAM. This should then unlock the flash and program it. It looks to me as if this fails somehow....

Hmmmmm....

* Not being allowed to read the option bytes.

* reading flash as "empty"

might mean that it's in "RDP level 1". I should try a mass-erase. I've never used "readout protection"

Update: I tested some more, this time through DFU... I can specify "mass-erase" to DFU:

dfu-util -a 0 -U test2.bin -s :mass-erase
 
 

and after that I can use -U test3.bin to read back what's in the flash.... Turns out that the first sector (0x800) is blank, but there is data beyond that! That' data is identical to the program I'm trying to flash....

Oh, and currently dfu-util can't write to the device either:

dfu-util: Error during special command "ERASE_PAGE" get_status
 
 
 

[Piranha]

Is BOOT0 really pulled low or is it floating? :)

[waclawek.jan]

And, once checking BOOT0 pin's soldering, also check all supply and ground pins, including the analog ones. And have a look at VDD using oscilloscope.

JW

[re.wolff9]

I copied a Nucelo "example schematic" so I designed a 10k pulldown resistor on my first batch of STM32 designs. Now, occasionally to reduce the number of DIFFERENT components I will allow a 4k7 resistor there. (This will increase power-use by less than 0.5mA only WHILE someone is pressing the "BOOT" button).

The soldering looks pretty good. This is a picture of the patient that I took with a different purpose than to show the soldering. (So that's why half the pins are out of frame) 

Yeah. I should check VDD with a scope. :) Lemme do that.

[waclawek.jan]

What's that yellowish substance at the left upper edge? Maybe a quick wash would change things.

JW

[re.wolff9]

It's some solder-paste remnants. Apparently some solderpaste got plastered across this board. This is in fact my spare that I tried, but it behaves very much the same as the first one. (I populated all the through-hole componnets on the first, not expecting any problems with the CPU. )

I'll clean the paste off, it is thin enough not to cause problems, but, yeah, you never know. I didn't see it with the naked eye: It's that thin, the light on the microscope brings it out: "how can you miss that!?!!??"....

[Uwe Bonnes]

Bringing up new things is always hard. There are so many sources of error. Try to minimize them.Start with someyhing knows good. Check dfu-utils with that so you see your understanding of dfu-utils is right.Then step by step exchange things.