LAUNCHXL-F280049C: Can FAPI write or erase blocks within sectors?

Hi GI,

You mentioned 4 issues with the flash API above.

I would like to discuss the first issue at first.

Regarding the blocks:  Can you give clarity with example of addresses and explain what you are not able to accomplish?

Thanks and regards,
Vamsi

Vamsi Gudivada said:

Can you give clarity with example of addresses and explain what you are not able to accomplish?

FAPI is not able to erase a single block size 128, 256, 512, 1024, 2048 bytes. Fapi sector erase has only start address and no end address within a sector. Is that a limitation of the FSM or FAPI?

Some issues were caused by F021 library not being in the same LSRAM address space as the pu16DataBuffer input data. Also (.data) section does not like F021 library in his address space or the #pragma control data. If F021 library is in a different LSRAM section than pu16DataBuffer input data, nothing will be programmed to the flash sector start address or any other incremented start address.

Putting the F021 library RAMGS0_A address space had similar results, since the #pragmas used to call F021 library function program mode buffer data was never input. These issues have nothing to do with 64 bit alignment and should be added to FAQ and user PDF. 

Hi Vamsi

So we can't access the flash memory via custom C code without FSM controller getting in the way? Oddly we can write LSRAM via custom C code but not Flash memory. 

Hi GI,

We can't do without FSM - that is correct.

As you know, Flash is a non-volatile memory and hence it involves a sequence of electric events to erase or program.  This is controlled by the FSM.

If you don't have further questions on this particular topic, I will close this thread.  For other questions, you can open a separate post - this helps us to track the questions better and help you.

Thanks and regards,
Vamsi

Hi Vamsi,

Yet we can Read Flash memory via custom C code without accessing FSM control. That does not make sense how older TM4C MCU class and other ARM Cortex MCU classes custom C code can access flash address space to write to sectors but newer C2000  x49c can't. Seems something other than FSM is stopping that from being possible? I have mentioned TM4C class (flash.c) can write buffer data to flash memory as Blocks smaller than sector size.

 Seems to me FAPI can write blocks if code was updated to handle smaller writes inside sectors aligned 64/128 bits. Can you check with management as to when such FAPI code update might be allowed? The reason for the request is obvious as to stop ware degradation of flash cells in sectors over time.

Regards,

Hi GI,

Can you clarify one thing: Are you trying to program already programmed locations without an erase?  Or are you trying to program unprogrammed locations in a sector in which a few other locations are already programmed?

Thanks and regards,
Vamsi

Vamsi Gudivada said:

Can you clarify one thing: Are you trying to program already programmed locations without an erase? 

No the blocks are all FFFF in the sector. I confirmed the TM4C can write flash on 128KB or even 256KB block level and first erases the block, not all blocks in the sector. Applicaiton indexes blocks by using program data first word of a block as a pointer, add 1 to increment to the next free block. Now I have to do fancy patch to jump over 15 blocks to the beginning of the next sector to erase.  

Good thing I saved the project this AM since it was doing just that last PM and it worked great until being powered off. Crazy NMI exception stops code dead in debug, out of the blue started doing that. So I modified cast pointer (unit16_t) into array[] buffer *name in the function that verifies sector blocks checksum are valid or not. I think the CPU is having issue with for loop calculating rapid block checksums, cause NMI during runtime but not debug. So I bumped up flash read wait states from 5 to 6 made no difference in this code piece until buffering the cast word pointer. Still does not work after target power is removed but can reset every time after closing debug and CCS. That issue has me puzzled, any ideas why even added delay in the 4 loop does not help?

#pragma CODE_SECTION(FlashPBIsValid, ".fapi.ramfunct");
#pragma FUNCTION_OPTIONS (FlashPBIsValid, "--opt_level=0 --opt_for_speed=0")
static bool
FlashPBIsValid(uint16_t *pui16Offset)
{
    static uint32_t ui32Idx;
    static uint32_t ui32Sum;
    uint16_t uc16Offset[0]; // stops debug NMI
    *uc16Offset = *pui16Offset; // stops debug NMI

    //
    // Check the arguments.
    //
    ASSERT(pui16Offset != (void *)0);

    //
    // Loop through the bytes in the block, computing the checksum.
    //
    for(ui32Idx = 0, ui32Sum = 0; ui32Idx < g_ui16FlashPBSize; ui32Idx++)
    {
        ui32Sum += uc16Offset[ui32Idx];

    }
       //
    // The checksum should be zero, so return a failure if it is not.
    //
    if((ui32Sum & 255) != 0)
    {
        return(0);
    }

    //
    // If the sum is equal to the size * 255, then the block is all ones and
    // should not be considered valid unless is the first block to write.
    //
    if((g_ui16FlashPBSize * 255) == ui32Sum)
    {
        return(0);
    }


    //
    // This is an invalid parameter block keep searching.
    //
    return(1); //
    
}

Hi GI,

Did you check the reason for the NMI in the registers?

Thanks and regards,
Vamsi

Hi Vamsi,

Read last post it sums up what and why checksum code above is causing flash NMI exception. Also going to try the Fletcher checksum utility to replace sum part of the above function. Will report if any progress made.

LAUNCHXL-F280049C: All flash registers are 0x0 after _C_Int00() - C2000 microcontrollers forum - C2000︎ microcontrollers - TI E2E support forums

No progress as Fletcher checksum has the same NMI in debug as the above code snip. Seems to read sector has a sum before it faulted. This was with 4 flash random read wait states, where 3 waits seem to fault much sooner in F6 as F7 step then jumps to NMI exception. Yet 3 wait states cause incorrect check sum being returned and seldom NMI exception.

Oddly enough ECC errors only happen after a sector 256KB block with 155KB write bytes has been programed by FAPI. Application doing any kind of checksum causes flash NMI. The flash initialization wait states value cannot stop the NMI exceptions from ECC errors as the sector start address is being corrupted only after FAPI programs a sector.

3.4.7 DCSM Safe Code Copy Reset (SCCRESET)
The device has a dual-zone code security module (DCSM) that blocks read access to certain areas of the flash memory. To facilitate CRC checks and copying of CLA code, TI provides ROM functions to securely access those memory areas. To prevent security breaches, interrupts must be disabled before calling these functions. If a vector fetch occurs in a safe copy or CRC function, the DCSM triggers a reset. This security reset (SCCRESET) is similar to a SYSRS. However, the security reset also resets the debug logic to deny access to a potential attacker. After a security reset, the SCCRESETn bit in RESC is set.

Where is the RESC register located, not in DCSM register view.

Hi Vansi,

It seems FAPI enables ECC during Fletcher checksum. Though I disabled ECC after Flash initialization so Fletcher checksum should not default to use ECC?

Tried to disable ECC before Fletcher checksum and enable after in several places. Though similar strategy did not stop NMI reset when application checks the same sector free space in a previously programmed block with blank space. Zone security only allows checksum or other blank test when start of any sector are FFFF(65535). Cause seems to be DCSM security errata condition. When flash zones are unlocked, DCSM only allow the sector to be programmed one time from the start address, no adding data midblock, perhaps even to the end of the sector. The ECC error occurs as zone security cuts off reading data.   

// Call Flash Initialization to setup flash wait states. This function must
// reside in RAM. It does exist LSRAM2_3 section (.TI.ramfunc)
Flash_initModule(FLASH0CTRL_BASE, FLASH0ECC_BASE, 5);

/* Disable ECC mode */
Flash_disableECC(FLASH0ECC_BASE);

Hi GI,

Fletcher checksum does not enable ECC.

Thanks and regards,
Vamsi

Hi Vamsi,

Agree but interesting enough FAPI initialization appears to enable ECC. I can disable ECC before Fletcher runs but sum never completes since DCSM drives NMI and watchdog stops device tampering. So in runtime the MCU resets when either method checksum asserts. The checksum starts midblock in free space after the first 155 bytes are written to the first block that new free space is not on a 64bit boundary and may be the cause for NMI. 

Hi GI,

FAPI initialization does not enable ECC.

Flash initialization function from the driverlib enables ECC.  I am sure you would have seen that code long ago since that code is available.

Thanks and regards,
Vamsi

Hi Vamsi,

The code snip I posted above shows ECC had been forced to disable right after flash initialization.  FAPI set active flash bank or FAPI initialization is Re_enabling ECC after it was disabled. Disabling ECC prior to Fletcher check some makes no difference to stop NMI just from reading that flash address space middle of the first sector block while debug stepping.

Notice too FAPI does OPT checksum right after initialization FAPI set active flash bank. I'm not using OPT ROM though it too is FAPI ECC program space and that OTP checksum might be causing a DCSM security issues as Vivek mentions such. My seemingly misplaced belief that ROM was not touched by the application it should not be an issue in any part of unlocked DCSM. The POR or hard reset NMI exception stops SCI to print 502 error message. Perhaps OPT checksum caused an illegal exception at that point, cannot be debugged by CCS since it only happens at runtime.  

Hi GI,

None of the flash API functions enable ECC.  NMI reset can enable it.

Flash API does read the unsecure TI-OTP to ensure that the flash trims are intact (via checksum).  If you are using ROM flash API (are you? please confirm), then ROM flash API is also unsecure.  Hence, there should not be any issue for the ROM flash API to read the TI-OTP in terms of security.

Even if you are not using the ROM flash API, flash API reading unsecure TI-OTP should not cause any issue.

Thanks and regards,

Vamsi

Am not using ROM flash API.  Using F021_F32_eabi library, loads into LSRAM. I comment out FAPI set active flash bank and still won't boot after POR. Guessing OTP checksum completed after commenting out call to check valid block via Flecher. Yet MCU will not reset or POR boot unless comment out call in HAL to load FAPI module after flash has initialized into LSRAM.

Hi GI,

Where did you get the F021_Float32_eabi library?  What exactly does this do?  Did you generate it?  If yes, how did you generate the F021_Float32_eabi library?

Please clarify.

Thanks and regards,

Vamsi

Vamsi, F021 float32 library is not the exact name verbatim though it seems to support floating pinot data types via pu16DataBuffer. If unsure perhaps the version of FAPI you are using did not include the F021 float32 library file. I had asked you about this library and never got an answer of why it was part of the API.

Vamsi Gudivada said:

Even if you are not using the ROM flash API, flash API reading unsecure TI-OTP should not cause any issue.

The OTP checksum fails via high speed PLL (100MHz) but succeeds via UniFlash 10MHz PLL. UniFlash can software reset the MCU as OTP checksum does not fault. Like to inform that FAPI program mode appears to have written random bytes in flash bank0 link pointer memory space. The DCSM link pointers are >> 1 byte and there are garbage bytes in the higher address range around the link pointers that don't belong. 

That may have occurred auto ECC program mode expecting it to increment pu16DataBuffer without designer needing to provide incremented pointer 4 loop. To me the word length inferred the applications input buffer length and the example using 8 was an arbitrary value of 8 words. The TM4C application had while(1) loop, No 4 loop. Shouldn't FAPI have known his library alignment (.bss) section was ALIGN(4) not ALIGN(8). This FAPI code C2000ware v4.1is a bit risky as designed, needs guard bands added to his program mode. Perhaps XDC110 makes 128bit writes to DCSM link pointer flash addresses, not 64bit writes. Oddly enough program start address was in bank 1 not bank 0, where FAPI corrupted blank link pointer memory.

There are other intermittent failures to read OTP and Flash sector checksums, not listed in the errata advisory sheet. Either of the two F021 libraries produce the same results, random failure of OTP checksum at 100MHz PLL speed. This issue is not detectable via UniFlash as OTP checksum will pass every time at 10MHz PLL speed without generating NMI.

I had never used UniFlash until this week someone might have mentioned it had DCSM utilities. I knew the name and believed it was only a command line firmware flash utility like DFUprog. CCS debug did not have a register lineup of the DCSM area like UniFlash has.

Vamsi Gudivada said:

Float32 flag enabled during compilation of this library means that the library can be embedded in the projects that have float32 flag enabled for compilation.

Oddly both libraries still compile embedded without error with command (--float_support=fpu32).  

Vamsi Gudivada said:

Are you saying it is locking the PLL for 10MHz only?  Please clarify.

Yes UniFlash sets the PLL 10MHz according to the settings/utils tab and CCS debug does not. And ROM boot works after stopping debug, hard reset runs FAPI set active flash bank until the first POR, then it breaks.

Hi GI,

1) When you say "both libraries", what are those two? Please clarify.

2) CCS flash plugin and Uniflash use the same config - there should not be any difference.  I did not develop them separately - both use the same codebase.  Uniflash GUI settings show that it uses the 10MHz INTOSC2 as the clock source - it is not the SYSCKOUT.  Same thing with the CCS flash plugin - CCS flash plugin GUI also shows the same thing.  

Thanks and regards,
Vamsi

Vamsi Gudivada said:

1) When you say "both libraries", what are those two? Please clarify.

F021 eabi libraries, not the F021 ROM library. Doesn't seem to be any difference during compile and F32 switch is a moot point.

Vamsi Gudivada said:

Same thing with the CCS flash plugin - CCS flash plugin GUI also shows the same thing.  

Actually, CCS debug HAL is setting PLL for SYSCLK 100MHz, can be confirmed by registers view. The XDC110 is set for 5.8MHz in debug.

Fletcher checksum often overflows (long) when (.data) is placed in RAMGS0_A. Checksum of 256KB block has 156 stored words and the rest of the block are FFFF. When (.data) is placed in LSRAM2_3 and F021 eabi library (LSRAM0_1) the block checksums are more consistent as source stepping ISR is disabled set to source stepping disabled in debug options. Elaborated below, e.g. :

CCS debug break point run session has ISR source stepping enabled when set to disabled debug options. When (.data) is placed in RAMGS0_A stepping (F5,F6,F7) works mostly as expected versus (.data) in LSRAM2_3, disables source stepping ISR's and stepping gets very slow, even stalls at times. A new post will address how (static) pointers >> shift variable value as F7 stepping return to the preempted ISR step.

So the previous data of the functions declared pointer >> shifting the value. Example: declared pointer address 0x0009C000 prior to Fletcher checksum, when preempted to handle ISR the (F7) return to Fletcher same static pointer is now 0x000000C0. Note: CPU IP being at the head of an ISR function, F7 shifted the pointer data that was well below 22 bits of compilers pointers restriction. The C2000 compiler forbids assigning a volatile pointer, though static is typically used in ARM Cortex for that very reason.

Hi GI,

Before starting the discussion on the fletcher checksum, could you tell me if the original question of this post is answered? 

If yes, let us start the fletcher checksum question in another post.

Thanks and regards,
Vamsi