Tool/software:
1、Chip registers FMPRE0 to FMPRE7 can be programmed, but data cannot be written to FMPRE8 to FMPRE15.
2、Chip registers FMPPE0 to FMPPE7 can be programmed, but data cannot be written to FMPPE8 to FMPPE15.
3、If the FMPRE0 register is fully set to 0, the chip will be permanently locked and cannot enter programming/debug mode again.
1、Chip registers FMPRE0 to FMPRE7 can be programmed, but data cannot be written to FMPRE8 to FMPRE15.
2、Chip registers FMPPE0 to FMPPE7 can be programmed, but data cannot be written to FMPPE8 to FMPPE15.
Hi,
Can you show how you program the registers FMPRE0 to FMPRE7? How did you program FMPRE8 to FMPRE15? Did you 'commit' the programming to these registers? You need to commit in order for the setting to become permanent.
3、If the FMPRE0 register is fully set to 0, the chip will be permanently locked and cannot enter programming/debug mode again.
What is the setting of FMPPE0 when you set FMPRE0 to 0? I suppose you are trying to enable execute-only protection, correct? You need to make sure that when you compile your code there is no literal data access to the blocks that you restrict to execute-only. Any literal data access to a execute-only block will be blocked. Please refer to the datasheet for details.
8.2.3.5 Execute-Only Protection
Execute-only protection prevents both modification and visibility to a protected flash block. This
mode is intended to be used in situations where a device requires debug capability, yet portions of
the application space must be protected from external access. An example of this is a company
that wishes to sell Tiva
C Series devices with their proprietary software preprogrammed, yet allow
the end user to add custom code to an unprotected region of the flash (such as a motor control
module with a customizable motor configuration section in flash).
Literal data introduces a complication to the protection mechanism. When C code is compiled and
linked, literal data (constants, and so on) is typically placed in the text section, between functions,
by the compiler. The literal data is accessed at run time through the use of the LDR instruction,
which loads the data from memory using a PC-relative memory address. The execution of the LDR
instruction generates a read transaction across the Cortex-M3's DCode bus, which is subject to the
execute-only protection mechanism. If the accessed block is marked as execute only, the transaction
is blocked, and the processor is prevented from loading the constant data and, therefore, inhibiting
correct execution. Therefore, using execute-only protection requires that literal data be handled
differently. There are three ways to address this:
1. Use a compiler that allows literal data to be collected into a separate section that is put into one
or more read-enabled flash blocks. Note that the LDR instruction may use a PC-relative address,
in which case the literal pool cannot be located outside the span of the offset, or the software
may reserve a register to point to the base address of the literal pool and the LDR offset is
relative to the beginning of the pool.
2. Use a compiler that generates literal data from arithmetic instruction immediate data and
subsequent computation.
3. Use method 1 or 2, but in assembly language, if the compiler does not support either method.
What is the setting of FMPPE0 when you set FMPRE0 to 0? I suppose you are trying to enable execute-only protection, correct? You need to make sure that when you compile your code there is no literal data access to the blocks that you restrict to execute-only. Any literal data access to a execute-only block will be blocked. Please refer to the datasheet for details.
Hi,
When the value of FMPRE0 is 0x00000000 and the value of FMPPE0 is 0xFFFFFFFF, the data written to the Flash Memory is all 0xFF. After we finish programming the above data, the SWD interface cannot be halt-enabled.Please help analyze the possible causes.
Can you show how you program the registers FMPRE0 to FMPRE7? How did you program FMPRE8 to FMPRE15? Did you 'commit' the programming to these registers? You need to commit in order for the setting to become permanent.
Hi,
We are programming the chip through the SWD interface. The programming operation refers to the instructions below. Data can be written successfully to FMPRE0 to FMPRE7 of the chip, but data cannot be written to FMPRE8 to FMPRE15. The same issue occurs with FMPPE.
Hi,
When the value of FMPRE0 is 0x00000000 and the value of FMPPE0 is 0xFFFFFFFF, the data written to the Flash Memory is all 0xFF. After we finish programming the above data, the SWD interface cannot be halt-enabled.Please help analyze the possible causes.
This is an unrealistic combination (FMPRE0=0 and FMPPE0=1) to allow program/erase to flash but not reads. Please refer to the datasheet.
We are programming the chip through the SWD interface. The programming operation refers to the instructions below. Data can be written successfully to FMPRE0 to FMPRE7 of the chip, but data cannot be written to FMPRE8 to FMPRE15. The same issue occurs with FMPPE.
I don't know why FMPRE8-15 cannot be written. Can you unlock the device first so all non-volatile registers are restored to their factory setting which is all 1's. After the unlock operation, just program FMPRE8-15 only. Do you see them programmed?
Under the same conditions, programming FMPRE1-7 with 0x00000000 does not affect the chip, so the issue may not be caused by the scenario you described
I'm confused. In your prior post, you said "When the value of FMPRE0 is 0x00000000 and the value of FMPPE0 is 0xFFFFFFFF, the data written to the Flash Memory is all 0xFF". This is why I said this combination is not realistic.
We have performed an unlock operation on the chip before programming. Is there any difference between programming FMPRE8-15 and FMPRE0-7? Since we are programming these 16 registers simultaneously, the data for FMPRE0-7 can be written to the chip, but FMPRE8-15 cannot. Could you please provide a detailed description of the programming process for these 16 registers? I would like to compare it with our operations. Thank you
This is why I asked if you could please unlock the device first and ONLY program FMPRE8-15 and NOT FMPRE0-7. Can you try this? I want to know if you only program FMPRE8-15 and not FMPRE0-7, can the write work?
Hi,
I program the FMPRE8-15 registers. See below first image. It works until the next power cycle. See the second image. After a power cycle, the FMPRE8-15 are not committed. I realized the issue is due to the MEM#18 errata. Please refer to the errata for details. You would need to recommit the register each time in your application after a power up.
After the power cycle, the FMPRE8-15 registers become 0xFFFFFFFF again.
Below is the code I use the program FMPRE8-15
HWREG(FLASH_FMA) = 0x10;
HWREG(FLASH_FMPRE8) = 0x0;
HWREG(FLASH_FMC) = FLASH_FMC_WRKEY | FLASH_FMC_COMT | FLASH_FMC_WRITE;
while(HWREG(FLASH_FMC) & FLASH_FMC_COMT)
{
}
HWREG(FLASH_FMA) = 0x12;
HWREG(FLASH_FMPRE9) = 0x0;
HWREG(FLASH_FMC) = FLASH_FMC_WRKEY | FLASH_FMC_COMT | FLASH_FMC_WRITE;
while(HWREG(FLASH_FMC) & FLASH_FMC_COMT)
{
}
HWREG(FLASH_FMA) = 0x14;
HWREG(FLASH_FMPRE10) = 0x0;
HWREG(FLASH_FMC) = FLASH_FMC_WRKEY | FLASH_FMC_COMT | FLASH_FMC_WRITE;
while(HWREG(FLASH_FMC) & FLASH_FMC_COMT)
{
}
HWREG(FLASH_FMA) = 0x16;
HWREG(FLASH_FMPRE11) = 0x0;
HWREG(FLASH_FMC) = FLASH_FMC_WRKEY | FLASH_FMC_COMT | FLASH_FMC_WRITE;
while(HWREG(FLASH_FMC) & FLASH_FMC_COMT)
{
}
HWREG(FLASH_FMA) = 0x18;
HWREG(FLASH_FMPRE12) = 0x0;
HWREG(FLASH_FMC) = FLASH_FMC_WRKEY | FLASH_FMC_COMT | FLASH_FMC_WRITE;
while(HWREG(FLASH_FMC) & FLASH_FMC_COMT)
{
}
HWREG(FLASH_FMA) = 0x1a;
HWREG(FLASH_FMPRE13) = 0x0;
HWREG(FLASH_FMC) = FLASH_FMC_WRKEY | FLASH_FMC_COMT | FLASH_FMC_WRITE;
while(HWREG(FLASH_FMC) & FLASH_FMC_COMT)
{
}
HWREG(FLASH_FMA) = 0x1c;
HWREG(FLASH_FMPRE14) = 0x0;
HWREG(FLASH_FMC) = FLASH_FMC_WRKEY | FLASH_FMC_COMT | FLASH_FMC_WRITE;
while(HWREG(FLASH_FMC) & FLASH_FMC_COMT)
{
}
HWREG(FLASH_FMA) = 0x1e;
HWREG(FLASH_FMPRE15) = 0x0;
HWREG(FLASH_FMC) = FLASH_FMC_WRKEY | FLASH_FMC_COMT | FLASH_FMC_WRITE;
Hi,
The command to write 0xA05F0003 to 0xE000EDF0, enabling debug and requesting the kernel to halt, failed to send.
Can you tell me who is writing to the 0xE000EDF0? This is the Debug Halting Control and Status register inside the Cortex-M4F processor. Normally, this is written by the debugger. Which debugger do you use? Do you happen to have the Memory Browser open? If you have the Memory Browser open then the debugger will read the flash content
If you are using CCS then I need to check with our toolchain experts on how the debugger writes to Debug Halting register and if there is any read operation involved where by any chance that it reads the flash for the first 64kB.
