• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Subscribers 83 subscribers
  • Views 590 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

LAUNCHXL-F280049C: Flash Blocks are Sectors?

Genatco
Guru 56043 points
Part Number: LAUNCHXL-F280049C
Other Parts Discussed in Thread: C2000WARE

Hello,

The TRM mentions RAM Blocks but does not give any Flash block size and never mentions sectors as being a block of memory. Are the Flash block size 4096 bytes each and also a sector? I have not found any reference to a sector being a 4KB blocks. The confusion stems from ARM driverlib functions define a TM4C1294 Flash block 16KB. Yet C2000 driverlib has no flash.c module, relies on FAPI and sector writes of 4096 byte sectors with 0x001000 length. Yet the compiler linker CMD file assumes sector length include 0x1, not 0x0 as does FAPI seem to start from memory address 0x0. These two are not keeping consistent methods of flash sector lengths adding to confusion of block R/W manipulation. 

So It would require 4 sectors to make 16KB block if a sector is considered a C2000 flash block alignment (4)? 

3.12.9.1 Erase
When the target flash is erased, it reads as all 1's. This state is called 'blank.' The erase function must be
executed before programming. The user should NOT skip erase on sectors that read as 'blank' because these
sectors may require additional erasing due to marginally erased bits columns. The FSM provides an “Erase
Sector” command to erase the target sector. The erase function erases the data and the ECC together. This
command is implemented by the following Flash API function: Fapi_issueAsyncCommandWithAddress();
The Flash API provides the following function to determine if the flash bank is 'blank': Fapi_doBlankCheck();

  • 0
    TI__Guru 50611 points

    Hi,

    Flash expert is out of office this week. He will get back to you next week. Sincere apology for inconvenience.

    Regards, Santosh

  • 0
    TI__Guru* 87155 points

    Hi GI,

    Is this question related to your other post on the blank check error?  

    Do you need further help on this?

    Thanks and regards,
    Vamsi

  • 0 in reply to Vamsi Gudivada
    Guru 56043 points

    Partially but FAPI flash requires sector alignment 64 = align (16) in FAPI sectors defined in flash CMD file?

    BTW there was TI employee post kept getting illegal instruction initializing FAPI. I was getting them randomly with 4 flash wait states, even after adding 200ns delays 5 wait states seems to stop random illegal instruction errors. The cache is being disabled in Flash_InitModule() in the HAL object code and that FAPI note should be amended. I also remove Eallow, Edit might have caused some odd behavior being in there.

  • 0 in reply to Genatco
    TI__Guru* 87155 points

    Hi GI,

    As I mentioned, each 64-bit aligned flash data has 8-bit ECC.  Hence, it is important to align the sections on 64-bit boundary in the linker command file to be able to program all the 64-bits of data at the same time while streaming an image.  Please read below question and answer.

    Question: Why do you use align directive (ALIGN(x)) in the linker cmd files provided in the C2000Ware examples?

    Answer. Fapi_AutoEccGeneration mode (one of the Flash API programming modes) programs the supplied data portion in Flash along with automatically generated ECC. The ECC is calculated for 64-bit aligned address and the corresponding 64-bit data. Any data not supplied (within a given 64-bit aligned memory) is treated as 0xFFFF. Note that there are practical implications of this when writing a custom programming utility that streams in the output file of a code project and programs the individual sections one at a time into flash. If a 64-bit word spans more than one section (that is, contains the end of one section, and the start of another), values of 0xFFFF cannot be assumed for the missing data in the 64-bit word, when programming the first section. When you go to program the second section, you will not be able to program the ECC for the first 64-bit word since it was already (incorrectly) computed and programmed using assumed 0xFFFF for the missing values. One way to avoid this problem is to align all sections linked to flash on a 64-bit boundary (preferable is 128-bit alignment since most of the flash programmers program 128-bits at-a-time) in the linker command file for your code project.

    Regarding the illegal instruction, please discuss that in the corresponding post.

    Thanks and regards,

    Vamsi

  • 0 in reply to Vamsi Gudivada
    Guru 56043 points

    Hi Vamsi,

    Vamsi Gudivada said:
    Question: Why do you use align directive (ALIGN(x)) in the linker cmd files provided in the C2000Ware examples?

    That is where the c2000 compiler states to enter flash sector alignment values, other than #pragma CODE_ALIGN(abcd, 4) used for a function to start on a specific boundary. That has nothing to do with writes to a flash sector under constrained control of FAPI program mode. Just like CCS debug writes to flash memory on 64-bit alignment how exactly does it achieve that, e.g. FSM register bits? Flash writes are hardware so why does FAPI need a sections area to point to sectors in bank1 already have CMD alignment (16 or 64) to write as the API already knows where it can program flash data in previously erased sector/s prior to switching into program mode? The sections statement seems out of place the way it being described above.

    Vamsi Gudivada said:
    One way to avoid this problem is to align all sections linked to flash on a 64-bit boundary (preferable is 128-bit alignment since most of the flash programmers program 128-bits at-a-time) in the linker command file for your code project

    Sections are for program storage via CMD file areas mostly are all aligned (4), that is not 64-bit alignment, correct?

    Oddly C2000 compiler omits and syntax example how to achieve 64bit alignment across banks or sectors. 

    I'm guessing each sector align (64), I have added areas for Bank1 in CMD file. Bank 0 sectors set for firmware space by TI align(4). How is that possible if CCS debug writes require 64-bit alignment and states it does such? 

    My FAPI Bank 1 has 4 sectors align(16) could infer 64-bit alignment to me or 16*4=64. The FAPI program writes will all be 32-bit worlds or less mostly at any write time unless it's the first-time parameters are written to sectors. No OTP use so 128 bit alignment is not required.

    If each FAPI sector has to align(64) how does the firmware bank 0 flash be set in CMD file ever work with sector align(4)? 

    .text : > FLASHB1_SA, ALIGN(4) or should these all be (64),(16) or (4)?
    .cinit : > FLASHB1_SA, ALIGN(4)
    .switch : > FLASHB1_SA, ALIGN(4)
    .const : > FLASHB1_SA, ALIGN(4)

  • 0 in reply to Genatco
    TI__Guru* 87155 points

    Hi GI,

    I will be able to review and get back to you early next week.

    Thanks and regards,
    Vamsi

  • 0 in reply to Vamsi Gudivada
    Guru 56043 points

    Seemingly FAPI still needs (4 word) alignment, which is 64 bits. Whoever wrote above blue text left out (word) AKA 16-bit data length align 1. So the project CMD file flash sections were already 64-bit aligned, (4-word aligned) and 8-word aligned would be 128-bits.

    Question remains does FAPI need the program function handler to have #pragma CODE_ALIGN ( func , constant )

  • +1 in reply to Genatco
    TI__Guru* 87155 points

    Hi GI,

    16-bit is always aligned by 1 - Not sure if I am missing anything?  Please explain.

    Yes, 8-word alignment or 4-word alignment is good enough (8-word is preferred since 3rd party programmers program 128-bits at once) for flash programming.

    Pragma(): This is needed when you want a function or data variable to be at a particular address.  This is not a requirement for flash API. 

    Thanks and regards,

    Vamsi

  • 0 in reply to Vamsi Gudivada
    Guru 56043 points
    Vamsi Gudivada said:
    If a 64-bit word spans more than one section (that is, contains the end of one section, and the start of another)

    The correct word would be sectors, not sections! Sections are found in the flash CMD file that 0xFFFF is one-word.

  • 0 in reply to Genatco
    TI__Guru* 87155 points

    Hi GI,

    We are talking about the sections of the linker command file there and not the flash sectors.

    If you have any questions, let me know.

    Thanks and regards,
    Vamsi

  • 0 in reply to Vamsi Gudivada
    Guru 56043 points

    Hi Vamsi,

    The text seems to suggest the supporting FAPI program should also be aligned to 64/128-bit memory sections.

    The #pragma CODE_ALIGN(func, constant) would ensure flash read (data) not specifically FAPI flash sectors are aligned on the same sector boundary for FAPI program (read 16DataBuffer) access. Otherwise FAPI could truncate data between two read sectors if a word 0xFFFF crosses the boundary, seemingly another takeaway. So the FAPI write flash is dedicated to only storage in a specific grouping of sectors the application has no direct access to.

    I now get to use OTP memory FAPI flash (write) sectors must be set to align(8). Seemingly where CODE_ALIGN could be used rather than creating new Sections for FAPI to (read) dedicated aligned functions for his program write data.

    Do you know Is the OTP read access faster than Flash read access times? 

  • +1 in reply to Genatco
    TI__Guru* 87155 points

    Hi GI,

    If the supporting FAPI program is going to be embedded in the application flash image, then it should be aligned on 128-bit boundary.

    OTP accesses are slower than the flash reads (as long as you won't configure flash wait-states to a much higher number than required for the given frequency).

    Thanks and regards,
    Vamsi