STM32L053 bootloader unable to erase

[lee23]

Posted on June 03, 2016 at 20:23

I'm writing a USART boot-uploader for a project of ours, testing it on an STM32L053 discovery board. I can bring up the bootloader and talk to it just fine, send all the GET commands for info (It reports chip id 0x417, bootloader version 0x31, available commands include 0x44 extended erase).

But when I send the extended erase command (0x44, 0xBB), I get back a NAK (0x1F) right away, even before I get a chance tell it to do an erase all or page-by-page. I've seen in AN2606 the read-protect/unprotect trick, but when I try that it ACKs the first (0x82) command, but then does not respond at all to the second (0x92).So how do I erase pages on this chip to prepare for writing? I've also seen mention of some chips being ''locked'', but I do not want to overwrite the bootloader itself, just upload a normal app to the normal flash location.Is this possibly an eval-board thing getting in my way? #stm32-discovery-bootloader

[Tesla DeLorean]

Posted on June 03, 2016 at 21:11

Does the Flash Loader Demonstrator application work?

Are you using Even Parity? What baud rate?Can you send Read Memory commands? Do they work?Are you sending a byte at a time or programmatically?

[lee23]

Posted on June 03, 2016 at 22:05

I don't currently have access to a Windows machine to try the demonstrator. I'll try to borrow one.

Parity is good (that one took me a while to debug), rate is 115200. I'm not seeing any dropouts in either direction.Read command (0x11, 0xEE) also gets an immediate NAK (0x1F) reply.I'm sending and receiving bytes with app_uart_fifo.c, driven by a state machine that's basically send / wait for reply / send / wait for reply / etc.  As I said, it's all working perfectly for the GET commands, just not read/erase (haven't tried write yet--I assume I need to erase first).

[lee23]

Posted on June 03, 2016 at 23:56Borrowed a Windows machine and ran the demonstrator. Starts fine, telling me everything I already know...hardware capability, software versions, etc.I then try ''erase flash'': Erase all fails, but choosing a single page succeeds, and selecting all succeeds. So it's at least getting past the initial command ack.''Upload'' from chip works as well.So, is there a simple way for this app to show me the conversation going over the serial port, or will I have to sniff that myself?

[Tesla DeLorean]

Posted on June 04, 2016 at 01:00

The read command would need a 9-byte packet. I wouldn't send a byte at a time through an OS. I've used RealTerm in HEX mode to send packet streams.

There are Windows based tools to bug the serial port.

[lee23]

Posted on June 07, 2016 at 23:28

Thanks for the help...turns out it was objecting to my issuing a ''write unprotect'' command. After that, it refused all reads and writes and erases. Take it out, and all is well. Also, it seems to be happier at 57600.