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]

DId I report back about the "yellowish stuff"? IRL it was "nowhere to be found" . I cleaned the PCB with IPA anyway.

[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.

[re.wolff9]

Thanks. So the design has worked with an STM32F072CB for ages.... So I took the design, kept most of the layout and added a few components. The CPU part is completely the same except for three more pins going to the new ssection on the PCB. (I normally put the SWD connector on the side of the PCB, but with the additional circuit it is now smack-in-the-middle. As the users are not going to be using that: "F* it, let's leave it there.... )

Attached the scope to the VCC(3.3V) signal. The scope doesn't trigger with the trigger set to 3.16V and triggering a failed download.

I've been using dfu-util for ages. Only used the mass-erase once, but I've been programming the STM32F072's whit it for a while.

I've tried "unprotect" and... Now 0x6000 more bytes of mainmemory have been wiped. SOMETHING is happening...

Update: Decoupling: It's worked without the officially recommended 4.7uF and the '072 for ages, but maybe.... I've added the 4.7uF capacitor and ... no change. (The regulator has a 1uF output capacitor and

Update: Requesting a mass-erase without any upload or download seems to ignore the mass-erase request. So I started using -U to get it to do something. The manual then hints at "mass-erase" needs to be with a a download, so I tried a download... Lo and behold.... Now it wants me to add "force". Great, but... it apparently was IGNORING the mass-erase command because I was doing "uploads" and not "downloads" sigh. Anyway.... Somehow the second attempt worked.

Option bytes.... page 88 of the reference manual specifies 0xffeff8aa as the default value of the option bytes.... This means IMHO that bit 20 is supposed to be low. Bit 20 is documented as: "Reserved, must be kept at reset value". This is IMHO "weird": Usually the reserved bits are unimplemented (do nothing). But why would such a bit be programmed to zero in the factory? The only thing I can think of is that it's a feature they tried implementing, and "1" enabled "0" disabled was the logical polarity of the bit. Then... turns out the feature doesn't work, and even interferes with normal operation. So you need to disable the feature which they are supposed to do in the factory.

Anyway.... My CPUs come from the factory with FFFFF8AA in the options register: Not as it should be according to the datasheet.

Now what? Program to the datasheet-documented-default, or violate "keep at reset value"? (I'm going to try to program it to the documented default).