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:
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:
now i tried following:
None of them work…any suggestions?
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.
Answered by Chris Stratton on November 11, 2021
1 Asked on January 17, 2021
2 Asked on January 14, 2021 by ultralisk
1 Asked on January 13, 2021 by justin-kennedy
0 Asked on January 12, 2021 by mark-crowder
1 Asked on January 12, 2021 by sbo
1 Asked on January 11, 2021 by bem22
0 Asked on January 11, 2021 by bright-day
1 Asked on January 9, 2021 by thekraken86
1 Asked on January 8, 2021 by user3201500
1 Asked on January 8, 2021 by foxie
1 Asked on January 7, 2021
1 Asked on January 7, 2021 by paa
2 Asked on January 7, 2021 by spinjector
0 Asked on January 6, 2021 by jaym
0 Asked on January 6, 2021
1 Asked on January 6, 2021 by paolo-linaac
Get help from others!