STM32L073xx Internal Bootloader - Get Flash Size issue

Question

I tried recently to develop custom app flasher (based on stm32loader python module) for STM32L073xx microcontrollers but I stuck at one point.

This lib tries to obtain flash size from micro because for the same chip UID (0x447 - STM32L07x/L08x/L010) we can have different flash size. Lib sends command to read memory (cmd 0x11 0xEE) and now starts my problem:

• flash size is stored at address 0x1FF8007C (RM0367, section 34.1.1)
• internal bootloader allows to read memory in range of system memory: 0x1FF00000 - 0x1FF01FFF (AN2606 Rev35, ch.56 "Device-dependent bootloader parameters", STM32 series L0, PID 0x447)

It causes that when I try to read flash size from this address, I receive response 0x1F (NACK) and i cannot continue process.

Of course I could copy flash size byte somewhere in RAM before jumping to system bootloader or assume some flash size but then pc application won't be robust for all chips.

How it should be handled in proper way? Is there another address where flash size is stored?

---

Now I'm able now to read whole flash content, but there is new challenge. I've tried to perform mass erase to prepare flash for writing new content and surprise surprise...bootloader returns NACK for any type of mass erase!

My communication looks like that:

• enter bootloader
• send 0x7F, get 0x79 (ACK)
• send 0x44 0xBB, get 0x79 (ACK) - Extended Erase Memory command

now i tried following:

• send 0xFF 0xFF 0x00, get 0x1F (NACK) - Mass Erase
• send 0xFF 0xFE 0x01, get 0x1F (NACK) - Bank 1 Erase
• send 0xFF 0xFD 0x02, get 0x1F (NACK) - Bank 2 Erase

None of them work...any suggestions?

Answer 1

It's unclear why reading address 0x1FF8007C does not work, I get the same failure.

However, experimenting with a Nucleo-L073RZ shows that it will permit one to read 128 bytes starting at address 0x1FF80000, which will have the flash size value which you seek as its penultimate 16-bit word.

Thinking it might be an offset issue I tried reads at 0x1FF80000 + [0x70, 0x60, 0x40] none of which worked. Conversely, reading at 0x800007c does work, so offsets are allowed in general. And as the read size is sent after the point where the address is NAK'd, it's not an issue with a 32- or 16-bit read being required.

Anyway, reading out a 128 byte block should solve your problem.

Another idea would be to start at an address near the top of the largest flash size and read down until you stop getting a failure. Or you could load a little stub into RAM and execute it. But it seems like reading out 128 bytes will be your simplest solution.

As an aside, using https://github.com/florisla/stm32loader (which seems to be what is on pypi, you didn't say what you were using) I found that I had to reset the chip each time I invoked the program, so apparently it is not leaving the bootloader in the right state. Still, that is an improvement over another tool I'd tried a few months back, which refused to talk to the L07x bootloader at all, though it was fine with the L05x one...

If one really wanted to spend an afternoon descending a rabbit hole, it would probably be possible to set a breakpoint before sending the address CRC byte and trace the bootloader operation to the logic which generates the ACK or NAK, but as it's in ROM all you would probably learn is precisely what is or (apparently erroneously) is not allowed.