Skip to main content
M
Mmcdo.1
Visitor II
November 18, 2020
Solved

Problem with bootloader flash erase/read.

  • November 18, 2020
  • 2 replies
  • 2035 views

I am trying to program the FLASH via the bootloader on USART1 of an STM32L431RBT6.

I can successfully access the bootloader with boot0=1 and a reset.

The bootloader properly acknowledges all the following commands, and returns the correct information:

0x7F

0x00 (Get)

0x01 (Ger version)

0x02 (Get ID)

0x63 (write protect)

0x73 (write unprotect)

0x82 (readout protect)

0x92 (readout unprotect)

However, when I try and read or erase the flash the processor seems to reset internally (NRST goes low).

An example of this is the following sequence:

Send: 0x7F (connect)

Receive: 0x79 (ACK)

Send: 0x73 0x8C (write unprotect)

Receive : 0x79 (ACK)

Send: 0x44 0xBB  (extended erase)

Receive : 0x79 (ACK)

Send: 0xFF 0xFF  0x00 (Mass erase)

Receive: (No response and processor resets)

The problem is the same if I try and do a bank 1 erase (0xFFFE) or bank 2 erase (0xFFFD) etc…

I will note as well that if I don’t do the “write unprotect�? command prior to the flash erase, then the processor does respond with NAK i.e.

Send: 0x7F (connect)

Receive: 0x79 (ACK)

Send: 0x44 0xBB  (extended erase)

Receive : 0x79 (ACK)

Send: 0xFF 0xFF  0x00 (Mass erase)

Receive: 0x1F (NACK) (no reset)

I am not sure what is going on or what I am doing wrong. These resets don’t appear to originate from any external source and are an internal reset of the processor.

Any advice? Thanks!

Some more info:

Bootloader: 3.1

Processor ID: 4.35 (53d)

options:

0693W000005BrXtQAK.png

    This topic has been closed for replies.
    Best answer by TDK

    You should read two ACKs for write unprotect per AN3155.

    The logic otherwise seems okay. Possibly you're missing something else on the line. I would put a logic analyzer on the line so you can see exactly what is sent at what time.

    The write unprotect should not be necessary, so it's likely something is wrong.

    Erasing flash can take more power as well. Ensure the chip is well powered and isn't causing a BOR.

    2 replies

    T
    TDKAnswer
    Super User
    November 18, 2020

    You should read two ACKs for write unprotect per AN3155.

    The logic otherwise seems okay. Possibly you're missing something else on the line. I would put a logic analyzer on the line so you can see exactly what is sent at what time.

    The write unprotect should not be necessary, so it's likely something is wrong.

    Erasing flash can take more power as well. Ensure the chip is well powered and isn't causing a BOR.

    M
    Mmcdo.1Author
    Visitor II
    November 19, 2020

    Thanks for pointing out the two ACK. I completely missed that!

    It seems the mass erase is working now, but I still can't read/write the flash, all address requests e.g. 0x80000000 are denied with NAK.

    e.g.

    Send: 0x31 0xCE (write )

    Recv: 0x79 (ACK)

    Send: 0x80 0x00 0x00 0x00 0x00 0x80 (address 0x80000000 + checksum)

    Recv: 0x1F (NACK)

    ... etc... (everthing else is NACK'd)

    If I do a "write unprotect" command before the write the proc. resets as stated before. I have looked at the signals on a logic analyzer everything looks correct...

    T
    TDK
    Super User
    November 19, 2020
    0x80000000 isn’t in flash.
    M
    Mmcdo.1Author
    Visitor II
    November 19, 2020

    Well, I am glad there are smart poeple on the internet like you, I'd be completely lost otherwise. I was able to write the fLASH.

    Terms & ConditionsAccessibility statement