2020-11-18 08:47 AM
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:
Solved! Go to Solution.
2020-11-18 02:26 PM
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.
2020-11-18 02:26 PM
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.
2020-11-19 09:03 AM
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...
2020-11-19 09:44 AM
2020-11-19 10:41 AM
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.