STM32L412 issues...

re.wolff9 · ‎2020-12-29

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?

re.wolff9 · ‎2020-12-31

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

waclawek.jan · ‎2020-12-31

Have you checked all the pins (directly the pins protruding from the plastic) against power supply and ground with a continuity tester?

> ... worked with STM32F072CB...

Okay, aren't there minor but substantial differences between 'F0 and 'L4 in the pinout?

JW

waclawek.jan · ‎2020-12-31

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

Leave it at the factory-programmed value.

JW

re.wolff9 · ‎2020-12-31

Update: I was wrong. I used the standard LQFP48 pinout from my library. I checked the datasheet (F072 vs L412) and... they are the same. At least for my purposes. I like the external BOOT0 pin, so I don't care about "PH3 / BOOT0" (L412) being different from "BOOT0" (F072). Similarly, I wired pin 36 VDD to 3.3V for the '072 and it's now "VDDUSB" to allow for more GPIOs to be lower-voltage, while still allowing for 3.3V USB power to be provided to the USB-module. Does not affect me.

Also, I don't have the SMPS version: That's only available in 64-pins and up.

Vangelis Fortounas · ‎2021-01-01

Hello

Take a look with STLink utility or CUBEProgrammer to nBOOT0 and nSWBOOT0 option bits. To be able to control BOOT0 functionality from BOOT0 pin, nSWBOOT0 option bit must be "1" .

re.wolff9 · ‎2021-01-01

yup. that's supposed to be the default, the way they are configured in the factory. And that's what I see in my device.

waclawek.jan · ‎2021-01-01

At this point you could perhaps compare your design to a "known good" board (NUCLEO), and/or get one physically and try your methods on that one.

JW

re.wolff9 · ‎2021-01-02

I tried comparing the schematic already, but it turns out that the nucleo for this chip is for the SMPS version.... I'm going to double check if they don't have another version too.

I got <something> working: If I mass-erase, I can program it over USB. I checked that Chibios had the definitions for this CPU, and it had.... Turns out it is still not supported, only the register definitions are present. Give me a couple of days to get something up and running. Working on "blinky".

re.wolff9 · ‎2021-01-02

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

re.wolff9 · ‎2021-01-02

OK! I have a blinky working!

At one point I copied my normal "dfuload" makefile target to this project and... it worked. (Verified: reset CPU into DFU mode, dnowload the flash memory and: perfect copy of the current binary, except that it had some remnants of an older binary after the end of the programmed binary! This proves that this didn't get programmed with a "mass erase"...) But next time it didn't and again failed on the "erase page" command. It seriously looks as if there is something fishy with the erase page on this CPU. I now have the mass erase in the makefile and this seems to work. I don't know how to mass-erase in the debugger, so I can't reset-load-continue in the debugger. But the debugger shows my blinky running my "count to 10 million"

The while (i--) asm("nop"); delay loop runs 1.5 times faster (4 clocks instead of 6) than on F0. =)

Update: USB-CDC works too. =) Glad I didn't have to dive into THAT mess.

P.S. While the "erase page" OFTEN doesn't work, the "mass-erase" SOMETIMES doesn't work. While not perfect, it is now workable. I prefer to debug with "dump this, dump that" commands over USB anyway.

I'm moving forward: You could say: there is something wrong, you should figure out what it is, but: I currently have "no clue". So I could spend ages on this, while when I continue I'll likely run into SOMETHING that ends up being a clue as to what's wrong....

It feels to me as if the erase flash commands time out because the CPU is running faster than expected (or the flash is slower than expected). or something like that.