LAUNCHXL-F280049C: FAPI Blank check bank1 sector 15 over runs

Hi,

The Subject matter expert is out of office until Thursday. Please expect response by Friday when he is back to office

Regards, Santosh

Hi,

The length that you pass for the blank check function should be the number of 32-bit words and not 16-bit words.  Could you check what you are using for the length?

Thanks and regards,

Vamsi

Hi Vamsi,

The text states to enter the sector length, not a number of words. The other sectors 12,13,14 have length 0x001000 do not overshoot address into 0x00A0000. Also the blank check text does not mention the length has to be for only one sector. It would seem typical to issue one FAPI command with sector start address and blank check range being any number of sectors in the bank. It seems to work either way without error except for Bank 1 sector 15.

Example 0x004000 should blank check 4 sectors starting from the sector address entered and not overshoot the length past sector 15.

Hi,

Let me review the guide and get back to you.

Thanks and regards,
Vamsi

Hi,

Please see below snapshot taken from the F280049 flash API guide: https://www.ti.com/lit/pdf/spnu628 

u32Length should be in 32-bit words.

Please note: I am out of office; our team will monitor this for you.  

Thanks and regards,

Vamsi

HI Vamsi,

Yet flash sectors are configured as 4096 bytes, not 8192 bytes.

Blank check by sector addressing should handle sector extent via ui32value relative to flash banks CMD file configuration, right? Again only sector 15 is causing an error. Sector 12,13,14 blank check without errors.

Vamsi Gudivada said:

u32Length should be in 32-bit words

Are the flash bank sectors defined (f280049_cpu_is_flash.cmd) not defined as 32-bit lengths?

 Is the text saying blank checks words FAPI can't access or use to store data? Is sector blank check crossing flash banks 0 & 1 incorrectly?

Hi GI,

The sector size should be 32-bit length. Are you referring to a specific or generic linker cmd file(f280049_cpu_is_flash.cmd)? I'll need some more time to look into this.

Thanks,

Charles

Hi Charles,

Charles Roberson said:

The sector size should be 32-bit length.

How does one make 4096 sector size (0x001000) morph into uint32_t without adding larger sector size? Infact 4096 byte sector length fits inside uint16_t, not uint32_t. The uint32_t might express (length of entire bank, not a single region), e.g. bank 0/1 blank check, not a single sector of either bank. Yet that works too in any other sector other than 15.

Since there are no more flash sectors after 15, perhaps blank check code needs to subtract 1 word for banks 0/1 sector 15. The text does not state blank check has to assert a call for each sector, only input an address length to indicate an extent of sectors. A single call also causes exception when it counts from sector 12 past the last Dword in sector 15, ending on 0x00A0000 word not being erased. 

Hi,

The second parameter in below function call should be 0x800 and not 0x1000.  This function needs the number of 32-bit words that you want to check for blank status.

oReturnCheck = Fapi_doBlankCheck((uint32 *)0x09F000, 0x001000, &oFlashStatusWord);

Please try 0x800 and let us know how it goes.

Thanks and regards,

Vamsi

Vamsi Gudivada said:

Please try 0x800 and let us know how it goes.

You are aware that 0x800 is only 2048 32bit words and the x49c Fapi sectors are 4096 32bit words on 64bit flash alignment in CMD file. The x49c flash sectors are Not 16-bit R/W, perhaps then 2048 length 0x800 would be acceptable for a blank check length. Perhaps FAPI was written for 64bit flash banks of different MCU class than x49c if what you are convinced of is remotely true. Why would a 32bit MCU class have 16bit flash sectors is the question to ask ...  

Again three other sectors (12-14) work as expected length of 0x1000 as 4096 32bit Words. Sector 15 has an issue in the FAPI rewrite to overshoot the 4096 words of the sector even via 0xFFE length. We had to put a length of 0x0 for sector 15,

There seems to be other bugs such as program async sectors with DCSM banks 1 & 2 flash sectors 12-15 proven unsecure but FAPI will not write any data to 64bit aligned Flash sectors. Even when they are confirmed to be 32bit blank check and CCS debug Memory Browser (0xFFFF.FFFF).  My first sector 12 to program flash is 0x009C000 also blank checked 0x1000 length.  

Hi GI,

Each of the F280049C flash sector has 0x1000 16-bit words OR 0x800 32-bit words.

If you are asking why the flash API read functions are asking for 32-bit word length: To speed up the read verify, customers requested for 32-bit read implementation instead of 16-bit reads.  If there is a need for 16-bit reads, customer can implement it.

Let me know if you want to discuss in a meeting to help clarify your questions.

Thanks and regards,
Vamsi

Hi Vamsi,

You seem to be implying flash is only 16 bit accessible by FAPI 

That just does not seem correct as FAPI needs 64-bit flash alignment for flash R/W and 128-bit for OTP. Again, blank checks 4096 bytes on any other sector other than 15 without throwing an exception, how do you explain that?

Yet TRM Fig 3.17 implies 64 bits wide ECC corrected data direct from flash banks 0 and 1.

It don't matter at this point since FAPI program command (auto ECC mode) is having int16_t data buffer size issue to write floating point values via FSM. The C language operators C2000 compiler are not recognizing all integers in floating point buffer arrays. The (size_of) operator simply stops input of floating-point hexadecimal string at the decimal point even though integers exist on the right of the decimal point. Work needs to be done to C language operators so they work with the FPU, at least (size_of) and [ (float32_t) array[1] = {0.0} ] should be able to read all integers right of the decimal point. The inline strlen() also stops at decimal point, I added decimal point recognition into custom itoa() and seems to ignore CCS debug decimal point as if it really is not there. 

TRM Fig 3.17 shows corrected ECC data is 64-bits wide and Figure 3.16 shows 16 bits Flash/OTP blocks seems a misprint! Why on earth would 32-bit CPU with 32-bit instruction fetch bottle neck C code into 16-bit data bus to R/W flash memory is the question of the day? That does not add up to being even logical when only specific data within a sector needs to be updated sometime many times in the MCU decades life span.

TRM states flash 128 bits wide or 64 bits alignment on Flash Bank0 and 64 bits on Bank1. Would not the statement in blue be misleading if flash sectors data bus width is only 16 bits wide? 

3.12.1 Features
Features of Flash memory include:
• Up to two Flash banks (Bank0 and Bank1) (refer to your device-specific data manual for the number and size
of the Flash banks)
• One FMC controlling up to two Flash banks
• 128 bits (bank width) can be programmed at a time along with ECC
• Multiple sectors providing the option of leaving some sectors programmed and only erasing specific sectors
• User-programmable OTP locations (in user-configurable DCSM OTP, also called USER OTP) for configuring
security, OTP boot-mode and boot-mode select pins (if you are unable to use the factory-default boot-mode
select pins)
• Flash pump shared by the two banks
• Enhanced performance using the code-prefetch mechanism and data cache in FMC
• Configurable wait states to give the best performance for a given execution speed
• Safety Features:
– SECDED-single error correction and double error detection is supported in the FMC
– Address bits are included in ECC
– Test mode to check the health of ECC logic
• Supports low-power modes for Flash bank and pump for power savings
• Built-in power mode control logic
• Integrated Flash program/erase state machine (FSM) in the FMC

Example divide FB0 or FB1 each 65,536/16 = 4096 sector length as the memory allocation shows. FAPI must be able to save (float32_t or float) data from the FPU or it is a useless API for saving motor control parameter floating point data for the EV industry. The motor control SDK 4.01 universal motor control SDK were designed specifically to use FPU float32_t parameters. FAPI program command input data buffer (uint16_t) is primitive and needs to evolve from 2017 last update Version 1.56.01.00. My reason for FAPI being required for remote updates of individual specific motor parameters, not the entire firmware. TI has diverged from older Motorware MCU classes, there is no alternative way to write 32-bit floating point ECC parameter data other than FAPI.

Sectors 12-15 are configured in device flash CMD file and both banks are 65,534-16 bits for errata advisory.

Vamsi Gudivada said:

For other sectors, even if you cross the sector end, there is still valid flash memory and hence it would work.

Ok that makes sense to me now you elaborate issue like that and obviously still a bug since 4096 bytes fits into Iint16_t address size. 

The buffer size error issue seems is a compiler issue with C operator (dot) in floating point values that seems to stop FAPI dead in its tracks. They are all typed as float32_t values but should convert down fit float16_t if that type existed in driverlib types.h 

Hi GI,

Are you saying that you are able to assign a value of 4096 to an unsigned int variable (16-bit)?  And are you saying it is a bug?  Please let me know if I understood correctly.

Thanks and regards,
Vamsi

Hi Vamsi,

Yes 0x001000 is 4096 length without compiler error. As you confirmed x49c sectors can only be blank checked to 2048 bytes. Yet the x49 sectors are 4096 byes in 2021. I put 0x800 for now and seems when FAPI was last updated in 2017 C2000 flash sector length was only 2048 bytes long. I think that may also cause an issue in FAPI programming C code logic of 4096 length sectors with 32 blocks.

I changed to use pointer to indicate to FAPI the 16DataBuffer block to write. In the ARM cortex code can check SYSCTRL registers for flash block address that points to the beginning flash sector block being returned. Oddly C2000 SYSCTRL registers don't seem to monitor Flash Bank block addresses in the same way.  

Hi GI,

I will review and get back to you in couple of days.

Thanks and regards,

Vamsi

Ok, below CCS debug firmware load may help to explain the blank check issue. Note the 0xE38 sector length is well above 2048 bytes.

C28xx_CPU1: Erasing Flash Bank 0, Sector 0
C28xx_CPU1: Data has been buffered at the end of the current data block for 64-bit aligned writes.
C28xx_CPU1: Writing Flash @ Address 0x00080004 of Length 0x000003fe (page 0)
C28xx_CPU1: Data has been buffered at the end of the current data block for 64-bit aligned writes.
C28xx_CPU1: --Verifying Flash @ Address 0x00080004 of Length 0x000003FC
C28xx_CPU1: Writing Flash @ Address 0x00080404 of Length 0x00003ff8 (page 0)
C28xx_CPU1: Erasing Flash Bank 0, Sector 1
C28xx_CPU1: Erasing Flash Bank 0, Sector 2
C28xx_CPU1: Erasing Flash Bank 0, Sector 3
C28xx_CPU1: Erasing Flash Bank 0, Sector 4
C28xx_CPU1: --Verifying Flash @ Address 0x00080404 of Length 0x00003FF8
C28xx_CPU1: Writing Flash @ Address 0x000843fc of Length 0x00000117 (page 0)
C28xx_CPU1: Data has been buffered at the end of the current data block for 64-bit aligned writes.
C28xx_CPU1: --Verifying Flash @ Address 0x000843FC of Length 0x00000114
C28xx_CPU1: Writing Flash @ Address 0x00084514 of Length 0x00000e38 (page 0)
C28xx_CPU1: Erasing Flash Bank 0, Sector 5
C28xx_CPU1: --Verifying Flash @ Address 0x00084514 of Length 0x00000E38

Hi GI,

I don't understand what is the issue here with the length 0xE38.  That address + length is still within the valid flash address range.

Thanks and regards,
Vamsi

Hi Vamsi,

Exactly, FAPI blank check needs to be configured >2048 bytes (0x800) as the flash sector length confirms >3640 bytes length. Notice 4 sectors are 0x3FF8 length 16,376 bytes or 4 sectors each 4094 bytes. FAPI has a bug in the sector length blank checking algorithm or cases CRC errors overshooting by a 16bit word. I also blank tested 0x00FFE on all 4 sectors, so overshoot issue seems a bit more complicated. 

Hi GI,

I feel we need a meeting to discuss this further so that we can understand the questions better.  Please let me know your time zone, and we can have a meeting accordingly.

Thanks and regards,

Vamsi

Hi Vamsi,

The x49c technical brief (SPRT727A–March 2017–Revised January 2018) page 3 shows 64k/16 Flash banks. I had simply assumed flash was 32 bit addressable but that really has nothing to do with FAPI incorrect 0x800 blank check length in x49c. I did not run any of the MCU class ID calls after FAPI initialization, wonder if it has something to do with the flash sector length error.

CCS memory allocation tool is flawless, also confirms flash banks are 64k/16. So FAPI limit of 0x800 range in a sector is physically wrong, even being 16-bit addressable memory! You can call same zone as TX but that won't change my mind about a bug in FAPI sector blank checking. There is no FAPI documentation to support logical addressing scheme, nor any formula shown to convert physical to logical flash block address range. That would certainly help if being the case here as I don't generally go deep dive without an illustration or other support aid.