infineon4engi@twitter infineon@linkedin infineon4engineers infineon@youtube
twitter Facebook Linkedin Youtube

Banner_Aurix_Competition Banner_AURIX_Security-Solution Banner_AURIX_Safety_Products ShieldBuddy TC275 Banner_AURIX_OnzerOS Banner_AURIX_DevelopmentStudio


+ Reply to Thread
Page 3 of 3 FirstFirst 1 2 3
Results 21 to 28 of 28

Thread: TC399 Flash sequence for write pflash & dflash

  1. #21
    Beginner Beginner kfir is on a distinguished road
    Join Date
    Mar 2020
    Posts
    27
    Points
    190
    Quote Originally Posted by cwunder View Post
    If you are referring to the delay for the BUSY bit to be set during the command sequence then there is no difference.

    This is defined as;
    I have the code written as follows:
    Code:
    	uint32 N_sectors = 1;
    	uint16 password = al_IfxScuWdt_getSafetyWatchdogPassword();
    	volatile uint32 timeout;
    	uint8 error = 0;
    	uint8 flash_bank = get_flash_bank((uint64*) start_address);
    
    	if (((uint32)start_address & 0xff000000) == 0xa0000000)    // program flash
        {
            N_sectors = size / 0x4000 +1; // size of 1 sector 16k for pflash
        }
        else if (((uint32)start_address & 0xff000000) == 0xaf000000)       // data flash
        {
            N_sectors = size / 0x1000+1; // size of 1 sector 4 kb for dflash
        }
    	
        IfxFlash_clearStatus(flash_bank);
    	
        IfxScuWdt_clearSafetyEndinitInline(password);
        IfxFlash_eraseMultipleSectors((uint32)start_address, N_sectors);
        IfxScuWdt_setSafetyEndinitInline(password);
    
    	
    	timeout = FLASH_EVENT_DELAY;
       while (--timeout && !DMU_HF_OPERATION.B.ERASE)
       {
           if ((1 == DMU_HF_ERRSR.B.SQER) || (1 == DMU_HF_ERRSR.B.PROER))
           {
             error = E_NOT_OK;
             continue;
           }
       }
       
       /* no need to wait on a failure or timeout */
         if ((E_OK == error) && timeout)
         {
           for (timeout=FLASH_BUSY_DELAY; timeout--; )
           {
             ;
             /* Wait for 2*1/fFSI ns (DFlash) or 3*1/fFSI + 8*1/fSRI ns (PFlash)
              * fFSI = 100MHz, fSRI =300MHz
              * then DFlash needs 6 cpu cycles, PFlash needs 17 cpu cycles)
              * delay before checking the busy bit
              */
           }
    
    
           /* wait until HF_STATUSx.BUSY = 0*/
           timeout = FLASH_PAGE_DELAY;
           while (--timeout && (DMU_HF_STATUS.U & (1 << flash_bank)))
           {
             if (1 == DMU_HF_ERRSR.B.OPER)
             {
               error = E_NOT_OK;
               continue;
             }
           }
         }
    	     
    	_dsync();
    
         if ((1 == DMU_HF_ERRSR.B.PVER) || (0 == timeout))
         {
           error = E_NOT_OK;
         }
    	 
        return E_OK;
    }
    where the delays are:
    #define FLASH_PAGE_DELAY 34500
    #define FLASH_EVENT_DELAY 100
    #define FLASH_BUSY_DELAY 10


    after checking the following:
    Code:
       while (--timeout && !DMU_HF_OPERATION.B.ERASE)

  2. #22
    Advanced Advanced UC_wrangler will become famous soon enough
    Join Date
    Jun 2019
    Posts
    258
    Points
    5380
    Code:
    N_sectors = size / 0x4000 +1; // size of 1 sector 16k for pflash
    If size is 0x4000, your number of sectors will be 2. Consider this instead:
    Code:
    N_sectors = (size + 0x3FFF) / 0x4000; // size of 1 sector 16k for pflash

  3. #23
    Advanced Advanced cwunder will become famous soon enough
    Join Date
    Feb 2015
    Location
    USA
    Posts
    198
    Points
    3927.5
    The code snippet that I provided is not verified for a production environment that is up to you!

    The maximum erase and program times are listed in the device datasheet under the "Flash Target Parameters"

    Program Flash Erase Time per Multi-Sector Command can take a maximum of 0.5 seconds. You have to take into account the system behaviors (like checking the supply voltage and servicing watchdogs).

    If you assume 300MHz CPU clock then a cycle takes 3.3nsec. To get a timeout of a 0.5s then you can 500ms/3.3ns = 150e6. However using this for a timeout will greatly exceed 0.5s as you also need to account for all of the instructions in the wait loop.

  4. #24
    Advanced Advanced
    Infineon Employee
    Infineon Employee
    teoBits is on a distinguished road
    Join Date
    Nov 2019
    Posts
    53
    Points
    890
    Hello,

    did you try porting the example Flash_Programming_1?

    It is a very nice detailed example for the TC297, which can be easily ported to the TC399. It also comes with a detailed tutorial: Flash_Programming_1 tutorial.


    If you are interested in other modules and you want to develop for AURIX™, you can get the new AURIX™ Development Studio and get inspired by numerous trainings from here: AURIX™ Trainings.
    If you are not familiar with Eclipse based IDE’s checkout the Getting Started guide!

    Hope it helps,
    teoBits
    The views expressed here are my personal opinions, have not been reviewed or authorized by Infineon and do not necessarily represent the views of Infineon.

  5. #25
    Beginner Beginner kfir is on a distinguished road
    Join Date
    Mar 2020
    Posts
    27
    Points
    190
    Quote Originally Posted by teoBits View Post
    Hello,

    did you try porting the example Flash_Programming_1?

    It is a very nice detailed example for the TC297, which can be easily ported to the TC399. It also comes with a detailed tutorial: Flash_Programming_1 tutorial.


    If you are interested in other modules and you want to develop for AURIX™, you can get the new AURIX™ Development Studio and get inspired by numerous trainings from here: AURIX™ Trainings.
    If you are not familiar with Eclipse based IDE’s checkout the Getting Started guide!

    Hope it helps,
    teoBits
    It's interesting that the code example is different from the manual...
    While the manual states that the first thing is clear status, the example enters page mode 1st thing!

    Also, n the example there are no delays as mentioned in the manual, why are there differences between the 2?

  6. #26
    Advanced Advanced
    Infineon Employee
    Infineon Employee
    teoBits is on a distinguished road
    Join Date
    Nov 2019
    Posts
    53
    Points
    890
    Quote Originally Posted by kfir View Post
    It's interesting that the code example is different from the manual...
    While the manual states that the first thing is clear status, the example enters page mode 1st thing!

    Also, n the example there are no delays as mentioned in the manual, why are there differences between the 2?

    Since the only operations carried out in the example are writing dummy data in the DFLASH and PFLASH, it is assumed that the status is already cleared, you can add the clear status operation on your code if you need to.

    About the delays, the function waitUnbusy() waits for the needed time between the operations.

    Best Regards,
    teoBits
    The views expressed here are my personal opinions, have not been reviewed or authorized by Infineon and do not necessarily represent the views of Infineon.

  7. #27
    Beginner Beginner kfir is on a distinguished road
    Join Date
    Mar 2020
    Posts
    27
    Points
    190
    Quote Originally Posted by teoBits View Post
    Since the only operations carried out in the example are writing dummy data in the DFLASH and PFLASH, it is assumed that the status is already cleared, you can add the clear status operation on your code if you need to.

    About the delays, the function waitUnbusy() waits for the needed time between the operations.

    Best Regards,
    teoBits
    Te function waitUnbusy waits only for flash_busy bit on DMU_HF_STATUS, where the algorithm asks to wait on more bits than that.

  8. #28
    Advanced Advanced
    Infineon Employee
    Infineon Employee
    teoBits is on a distinguished road
    Join Date
    Nov 2019
    Posts
    53
    Points
    890
    Quote Originally Posted by kfir View Post
    Te function waitUnbusy waits only for flash_busy bit on DMU_HF_STATUS, where the algorithm asks to wait on more bits than that.
    Hello,

    the waitUnbusy() function checks the Flash Status Register (FSR), which reflects the overall status of the Flash module after Reset and after reception of the different commands.
    In particular, it checks the PxBUSY and DxBUSY bits, which are HW-controlled status flags and indicate the busy state of PFx/DFx because of active execution of an operation.
    The other bits waited on the manual are for making sure that the procedure is correctly executed, e.g. after entering in page mode you check if the xFPAGE bit is set and the SQER and PROER bits are not.
    About the PROG bit instead, if one BUSY flag is coincidently set, PROG indicates the type of busy state.

    For simplicity, in the example these bits are not checked but, if you need to, you can add the instructions to check them in your code.

    From the timing point of view, when the BUSY flags are reset, the flash memory is not subjected to operations, thus another operation can be started.

    BR,
    teoBits
    The views expressed here are my personal opinions, have not been reviewed or authorized by Infineon and do not necessarily represent the views of Infineon.

+ Reply to Thread
Disclaimer

All content and materials on this site are provided “as is“. Infineon makes no warranties or representations with regard to this content and these materials of any kind, whether express or implied, including without limitation, warranties or representations of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, whether express or implied, is granted by Infineon. Use of the information on this site may require a license from a third party, or a license from Infineon.


Infineon accepts no liability for the content and materials on this site being accurate, complete or up- to-date or for the contents of external links. Infineon distances itself expressly from the contents of the linked pages, over the structure of which Infineon has no control.


Content on this site may contain or be subject to specific guidelines or limitations on use. All postings and use of the content on this site are subject to the Usage Terms of the site; third parties using this content agree to abide by any limitations or guidelines and to comply with the Usage Terms of this site. Infineon reserves the right to make corrections, deletions, modifications, enhancements, improvements and other changes to the content and materials, its products, programs and services at any time or to move or discontinue any content, products, programs, or services without notice.