CCS/TM4C129XNCZAD: ROM_FlashErase and ROM_FlashProgram problem at 120MHz

I have not seen that issue before. What location are you erasing and then programming? What do you mean by "lock my software"? Do you still have JTAG access?

i try to answer as better as i can:

the software lock when i do this function, but only at 120MHz, because at 25MHz works correctly.

ROM_FlashErase(0xF4000);

if i try to pause the debug this is the error i get:

CORTEX_M4_0: Trouble Halting Target CPU: (Error -2062 @ 0x0) Unable to halt device. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 7.0.100.0)

the strange thing is that my display works, also the LED works, so is only a memory problem.

I also saw that the program sometimes works, i was thinking it's a problem about memory occupation but i'm using 26% of FLASH and 9% of SRAM

i didn't understand why but using

FlashErase(0xF4000);

works correctly.

after stop to

ROM_FlashProgram(0xF4000);

but again, removing ROM_

FlashProgram(0xF4000);

works correctly

What version of the TivaWare library are you using? I am not able to reproduce your issue using version 2.1.4.178 and the following code:

//*****************************************************************************
//
// Copyright (c) 2019 Texas Instruments Incorporated.  All rights reserved.
// Software License Agreement
// 
// Texas Instruments (TI) is supplying this software for use solely and
// exclusively on TI's microcontroller products. The software is owned by
// TI and/or its suppliers, and is protected under applicable copyright
// laws. You may not combine this software with "viral" open-source
// software in order to form a larger program.
// 
// THIS SOFTWARE IS PROVIDED "AS IS" AND WITH ALL FAULTS.
// NO WARRANTIES, WHETHER EXPRESS, IMPLIED OR STATUTORY, INCLUDING, BUT
// NOT LIMITED TO, IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
// A PARTICULAR PURPOSE APPLY TO THIS SOFTWARE. TI SHALL NOT, UNDER ANY
// CIRCUMSTANCES, BE LIABLE FOR SPECIAL, INCIDENTAL, OR CONSEQUENTIAL
// DAMAGES, FOR ANY REASON WHATSOEVER.
// 
//*****************************************************************************

#include <stdint.h>
#include <stdbool.h>
#include "inc/hw_types.h"
#include "inc/hw_memmap.h"
#include "driverlib/rom.h"
#include "driverlib/rom_map.h"
#include "driverlib/sysctl.h"
#include "driverlib/flash.h"

int
main(void)
{
    uint32_t ui32SysClock;
    uint32_t pui32Data[2];

    //
    // Run from the PLL at 120 MHz.
    //
    ui32SysClock = MAP_SysCtlClockFreqSet((SYSCTL_XTAL_25MHZ |
                                       SYSCTL_OSC_MAIN |
                                       SYSCTL_USE_PLL |
                                       SYSCTL_CFG_VCO_480), 120000000);

    //
    // Erase a block of the flash.
    //
    ROM_FlashErase(0xF4000);
    //
    // Program some data into the newly erased block of the flash.
    //
    pui32Data[0] = 0x12345678;
    pui32Data[1] = 0x56789abc;
    ROM_FlashProgram(pui32Data, 0xF4000, sizeof(pui32Data));

}

i'm using:

• driver 2.1.3.156
• Code Composer Studio 7.4.0.00015
• compiler TI v5.2.6
• Windows 10 x64 ver. 1903 

using your code i don't have problem, maybe i have some initialization, eth or usb, that create the problem with some interrupt.

i try to move your flash and erase after, to find what is the lock problem.

i have too much random problem.

i've tried to copy your Erase and Program before my problem and worked, the difference was that i used a #DEFINE for the address.

so, i have deleted the #DEFINE and use a fixed value, still have the problem.

i still don't get the problem, why the erase and program works the first time and not the second time?

i'm writing a value too big? actually is 12000 byte, it shouldn't be too big.

i also have seen that another project, with minimal changes in what the board to, but not in the driver, works correctly.

I am out of the office and will return on Wednesday October 16. I have asked a colleague to look into your issue while I am gone. 

i don't know if it's possible to have a teleservice, or another way to show you the problem, maybe a screen recording posted on youtube?

I modified my routine to program 12000 bytes and had no problem. Is there some reason you are using the older version of TivaWare and an old version of the compiler? Can you try using TivaWare 2.1.4.178?

i've tryed as you said with 2.1.4.178 but still not working.

the only thing that make it work is removing ROM_ before FlashErase and FlashProgram.

doing this the software continue working but i have other problem, my keypad stop working after some keypress.

also the RTC is flickering, something like data loss in SPI communication

This sounds like a system problem. Changing from 25MHz to 120MHz or from ROM_FlashErase() to FlashErase() may change the symptoms of the problem, but are not solving the problem. Are you servicing interrupts while the erase and program operations are on-going? If so, in any interrupt routine are you making an access (either data read or instruction fetch) to the upper half of the flash space. Such an access during the erase will stall the CPU until the erase has completed and this can cause issues in servicing real-time interrupts.

yes, i have continuous interrupt because i'm always reading an ADC, also i have interrupt for keypad, RS232, Ethernet, USB memory stick, ecc...

to access memory i just use a pointer to an address, i don't do any reading function, i don't know if this is the correct way.

i just do this at program start

	ROM_FlashIntClear(FLASH_INT_ACCESS);
	ROM_FlashIntEnable(FLASH_INT_ACCESS);
	ROM_IntEnable(INT_FLASH);

and then, for example

void ReadCalibrationParameters(TFlashCalibration *par)
{
	TFlashCalibration *tmp_ptr = NULL;

	if(par == NULL)
		return;

	tmp_ptr = (TFlashCalibration *)START_PARAMETER_CALIBRATION;
	memcpy(par, tmp_ptr, sizeof(TFlashCalibration));

	return;
}

i think your idea is going to the correct way because my software sometimes works and other not, only changing the size occupied in memory

The memcpy() function will do a read of the locations starting at the address pointed to by START_PARAMETER_CALIBRATION. If that address is in the upper half of flash (0x040000 or higher) the read will stall the CPU while the flash is erased. The same thing happens when programming the flash, but the individual programming operations happen much faster than the sector erase.

can you explain how can i change that bit while using the debugger? i'm a newbie in microcontroller world.

if it's this register i think it's arleady at 1 the bit 16

That is not the correct address. The Flash memory control base address is 0x400FD000, so the actual address is 0x400FDFC8. The easiest way to see it is to use the register window as shown below:

finally a good news! that bit is making it working, I have also fixed the keypad removing the delay in the interrupt and also the RTC is fixed with this bit!

how can i keep it always at 1?

thank you

Thank you Chester. This was a great help.

Thank you both for the support!

i've checked also the analog input and works correctly, everything seems ok now and i can move forward to get the ethernet working!