TMS320F28P551SG: Sysconfig and runtime code example for flash write protection

Part Number: TMS320F28P551SG
Other Parts Discussed in Thread: SYSCONFIG, C2000WARE, UNIFLASH

Hi champs,

 

I am asking this for our customer.

The user wants to implement 4.7.1.1 Flash Write Protection of TRM for both F28P550x and F28P551x.

Questions:

  1. Is it avaiable on Sysconfig DCSM? Would you please show us how to do this by Sysconfig DCSM explicitly?
  2. By Sysconfig DCSM, how does the user ensure the code to be placed on the protected flash is programmed first before Z1 GPREG2 register in OTP is programmed?
  3. During runtime, the user should use flash API to program Z1 GPREG2 register in OTP. Is it right?  Would you please show us a simple code example to do this during runtime? 
  4. Is it possible to set DCSM Z1 GPREG2 bits in different times during runtime? For example, to set bit 9 first, then set bit 10 at a later time, and then set bit 11 at a later time. That is, enable flash write protection gradually during runtime? The user is asking this and wonders if minimum 128-bit data programming for OTP is required for one time because flash API is 128-bit aligned?

You may use F28P551x as the example.

  • Hello,

    Please allow me more time to look this over, I will get back to you tomorrow.

    Best,
    Matt

  • Hello,

    Apologies, but I will be OoO for the next few weeks so I routed this thread to another expert to handle this thread. Please expect a slight delay in assistance.

    Best,
    Matt

  • Is it avaiable on Sysconfig DCSM? Would you please show us how to do this by Sysconfig DCSM explicitly?

    Yes, I would ask the customer to import the DCSM example as it has the module added C:\ti\c2000\C2000Ware_26_01_00_00\driverlib\f28p65x\examples\c28x\dcsm 

    The customer will need to check the box next to "Configure Boot Setting"(screenshot below) in the Zone 1 header and then they will see drop downs for WP for each of the documented Sectors.   

    Please keep in mind that these are in GPREG2, which share ECC with GPREG1, which contains the boot mode pins.  These need to be configured at the same time, since we can only do one write to OTP.

    By Sysconfig DCSM, how does the user ensure the code to be placed on the protected flash is programmed first before Z1 GPREG2 register in OTP is programmed?

    I'm checking on this, a very valid concern.  Since this is in the same region as other DCSM bits, I'm assuming that the CCS/Uniflash have directives to program the main arrays first before they activate the DCSM/OTP.  But please let me confirm this point before we proceed.

    During runtime, the user should use flash API to program Z1 GPREG2 register in OTP. Is it right?  Would you please show us a simple code example to do this during runtime? 

    I think the importance of this depends on my answer to the above, i.e. if we can't use the SYSCONFIG/code to handle this as part of the main .out file load; then we need to use the flash API to program this ourselves as part of code execution.  I'll look into this along with the previous question.  

    Does the customer intend to program devices through JTAG in production or with a bootloader for 1st flash load?

    Is it possible to set DCSM Z1 GPREG2 bits in different times during runtime? For example, to set bit 9 first, then set bit 10 at a later time, and then set bit 11 at a later time. That is, enable flash write protection gradually during runtime? The user is asking this and wonders if minimum 128-bit data programming for OTP is required for one time because flash API is 128-bit aligned?

    No, because this region has ECC protection and that will change when new bits are cleared the ECC is also impacted by the OTP restriction, so we can only write to this address 1 time.

    Best,

    Matthew

  • Wayne,

    Regarding

    By Sysconfig DCSM, how does the user ensure the code to be placed on the protected flash is programmed first before Z1 GPREG2 register in OTP is programmed?

    If using CCS/Uniflash there is a procedure we must follow to ensure the correct order.

    The customer would want to program their main array first, just using their standard .out that has the code itself, just the main array.

    Then customer can use the DCSM project I referenced above to configure the settings for the OTP regions(including the write protection) and compile that project.  That specific project is a "RAM" build, that is the main.c has no flash code, but the sysconfig creates the dcsm regions by making a dcsm.asm file as well as an additional dcsm.cmd file that has the addresses.

    Before loading this dcsm.out, however, the customer needs to configure the CCS flash plug in so that it does not erase the main arrays automatically, which is the default action when it is invoked.

    Below is from CCS v20, in order to bring up this configuration the customer would need to right click on the C28x core, and select properties.  This will bring up the dialogue box you see.  Then from the bottom of the 2 dropdowns in this new box, select flash settings.

    You will want to scroll down and find find "Erase settings" and click the radio button for "Necessary Sectors Only(for program load)" and Save the changes.  This will prevent the main array erase when the dcsm.out is loaded, preserving content of main array.

    I still have this open question:

    Does the customer intend to program devices through JTAG in production or with a bootloader for 1st flash load?

    Best,
    Matthew

  • Hi Matt,

    Their original intention was to program device for part of the flash protection by Sysconfig in production, and THEN, update it by user's own bootloader in some firmware update conditions.

    But since you said Z1 GPREG2 register can only be programmed once, they are thinking how to do this in production once.