Writing in STM32L4x1 flash memory in C

Question

I am trying to write in STM32L476's flash memory using a JTAG ST-Link/V2 on Windows 7. No software has to be uploaded, I only need to write data in a non-volatile place where it can be read and deleted.

As a newbie regarding hardware and being efficient only when programming non-embedded regular C, I am afraid I might harm or modify irrevocably the flash memory. Also, I am not really sure regarding what I can or cannot do.

I have figured out reading the manual that writing in 0x08000000 memory place seemed to be a good idea. Using C code to make calls to ST-Link_Utility :

const char CMD_ACCESS_ST_UTILITY[] = "cd C:/Program Files (x86)/STMicroelectronics/STM32 ST-LINK Utility/ST-LINK Utility&&ST-LINK_CLI.exe ";

bool STLINKWriteSystemCalls(void)
{
    char cmd[200] = "";


    strcpy(cmd, CMD_ACCESS_ST_UTILITY); // cmd to access utility
    strcat(cmd, "-c"); // Then connect with ST-Link
    if (system(cmd) != 0)
        return false; // If failed exit


    strcpy(cmd, CMD_ACCESS_ST_UTILITY);
    strcat(cmd, "-r8 0x08000000 0x100"); // Read to check if there is data already

    // I haven't managed yet how I'll compare the result of read
    // To FFFF but that's not the main issue

    if (system(cmd) != 0)
        return false; // If failed exit


    strcpy(cmd, CMD_ACCESS_ST_UTILITY);
    strcat(cmd, "-w8 0x08000000 0x00"); // Write data into 0x080000000
    if (system(cmd) != 0)
        return false; // If failed exit

    return true;
}

Is there a better way to do this regarding where to write and how to write (errors checking, ressource used etc) ?

you can use openocd and should be able to just run commands on the terminal (telnet) to flash, for SWD I use openocd exclusively, for the bootloader, another story (wrote my own tool). — old_timer, May 22 '17 at 14:16

LPs · Accepted Answer · 2017-05-22T17:43:00.390

1

Main things to know about flash memories:

Flash memories are page erasable, in your case page size if 2K. What does it means? That you must be sure that your code does not resides in the 2k range of page.
After erase the state of all bytes in memory is 0xFF.
Write to a flash byte means, at raw level, to modify bits set to 1 to bit set to 0. If you want to modify a bit from 0 to 1 you must erase a whole page.

ST-Link_Utility does it embedded way, so when you write to flash it erase a whole sector ans then write data. The same if your code is required to ease data after they are used.

By default your mCU, at startup, uses 0x0000 0000 aliased address of 0x0800 0000.

First words should contain the reset vector and the default vector table. Reset vector is always the first instruction to be executed.The reset vector in this table will contain a branch to an address which will contain the reset code.

So, in other words, At the time of power up, the processor jumps at fixed location 0x0, which means it jumps at 0x0800 0000. Obviously the address you selected is not correct ;)

edited May 22 '17 at 17:43

answered May 22 '17 at 12:14

LPs

16,045
8
30
61

"So, in other words, At the time of power up, the processor jumps at fixed location 0x0, which means it jumps at 0x0800 0000" I am not sure I get why this is a problem. You're saying that the address 0x0800 0000 is already used or should already be used to store the reset and the default vector table ? Thus wriring personnal data at this address would overwrite important information ? – Badda May 22 '17 at 12:19
If I understand correctly, I must watch out for everything inside a page before writing into it since erasing or modifying what I wrote will cause the whole page to be erased ? I am sorry but I have still trouble understanding what is the problem with the `0x0800 0000` address. Actually it is FF, so how could it possibly contain the default and reset vector ? Sorry if it is obvious – Badda May 22 '17 at 13:41
1

@Badda Yes and no. The problem is that 0x08000000, as I wrote, is the address where mCU jumps to see where the code is located. So if you write to it St utility will erase the whole page and write your data loosing the previous data written. So you overwrite what the mCU look for at startup. – LPs May 22 '17 at 13:44
Thanks. I think I get it. Can I ask you a last favor, may be adding the reference where in the documentation you found the part saying the MCU jumps to that specific address ? – Badda May 22 '17 at 13:52
1

@Badda Is how [ARM](http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0337e/ch05s09s01.html) works. You can find a lot of info on the webjust searching for _Boot sequence ARM_ – LPs May 22 '17 at 14:54
1

@LPs : More specifically it is how ARM Cortex-M works - not _all_ ARM architectures. – Clifford May 22 '17 at 16:55
1

@Badda : The parts of the STM32L4x1 that are specific to the ARM Cortex-M4 are not described in STM32L4x1 User Manual, but are provided by [ARM's technical documentation](http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.subset.cortexm.m4/index.html). – Clifford May 22 '17 at 16:59
@Clifford Yes. I was not so precise as I should. – LPs May 22 '17 at 17:14
1

@Badda Easiest source fot that kind of information is reference manuals from ST. In case of STM32L4x1 you mentioned, refer to RM0392 where under section 2.6 Boot configuration you can find exactly what has been discussed here. – J_S May 22 '17 at 17:14

Jeroen3 · Answer 2 · 2017-05-22T12:21:31.267

Good news! Since you're using ST Link utility you can't destroy the chip. It will simply refuse to write where there is no accessible memory.

The only way to permanently lock yourself out of the chip is to enable the read protection to the maximum level 2. To do this you have to write to the option bytes. And you do not accidentally write 0xCC33 to the lock bytes.

One thing to consider is that the chip only writes halfwords (16 bits) and only when the FLASH is still 0xFFFF (erased state). Otherwise it will return write error.

Update: manual snippet frome RDP. Code read protection.

Level 2: No debug
In this level, the protection level 1 is guaranteed.
In addition, the Cortex®-M4 debug port, the boot from RAM (boot RAM mode) and the boot from System memory (boot loader mode) are no more available.
In user execution mode (boot FLASH mode), all operations are allowed on the Flash Main memory. ...
The level 2 cannot be removed at all: it is an irreversible operation.

In short: do not write to 0x1FFF7800.

For example, if I tried to write in the OTP, either JTAG would allow me to erase the data later, either writing would fail ? I didn't quite get the "permanently lock yourself out of the chip " part, English not being my native language and being still learning the technical vocabulary. Could you please explain it a bit further ? — Badda, May 22 '17 at 11:54

Writing in STM32L4x1 flash memory in C

2 Answers2

Linked