• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 84 subscribers
  • Views 343 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.

Original question:

TMS320F28379D: Programming EMU_BOOTCTRL directly in code

TMS320F28379S: Issues with programming BMODE in X1_BOOTCTRL using DCSM project or using EMU_BOOTCTRL to kick off a SPI boot

Jeremy Harbaugh
Prodigy 10 points
Part Number: TMS320F28379S
Other Parts Discussed in Thread: C2000WARE, SYSCONFIG

I've been running into issues with writing to the X1_BOOTCTRL via DCSM. After piecing together documentation on the issue, the approach that seemed the most likely to work was to:

1. Import the "blinky_with_DCSM" example project for f2837xs in the c2000Ware support

2. Add the following above the main() in the "blinky_with_DCSM_cpu01.c" file

#pragma RETAIN(otp_z1_bootctrl)
#pragma DATA_SECTION(otp_z1_bootctrl,"dcsm_otp_z1_bootctrl");
const long otp_z1_bootctrl = 0xFFFF045A;

3. Compile and deploy the project via JTAG debug session. 

I can see the value being retained in the memory map, but I'm not seeing the result get stored in the Z1_BOOTCTRL register in the memory map (over various methods for running and resetting the application).

dcsm_otp_z1_bootctrl
*          0    0007801c    00000002     DSECT
                  0007801c    00000002     blinky_cpu01.obj (dcsm_otp_z1_bootctrl:retain)

The value at 0x0005F004 remained 0xFFFFFFFF while viewing with the Memory Browser. I was also unable to directly edit this value in the memory browser, which was recommended in some forum postings.

After failing to write to the Z1_BOOTCTRL register, I decided to try to work around the issue using EMU_BOOTCTRL. I was able to edit the 0x0D00 location with 0x045A, however I ran into a breakpoint each time I tried to kick off a CPU reset from CCS. I did not notice any effect from a System Reset or a Restart command - the blinky application continued to execute as if there was no interruption.

The message upon reset was:

(Suspended - SW Breakpoint - A Reset Occurred On The Target)

I couldn't get the application to run past this point.

I should note that we configured the BOOTPIN0 and BOOTPIN1 pins for Get Mode (both high), using the default GPIO Pin 84 and Pin 72, respectively.

Is there any guidance or support on trying to enable SPI boot on the F28379S that could shed some light on this issue?

  • 0
    Prodigy 10 points

    Hi! Any update on this issue?

  • 0 in reply to Jeremy Harbaugh
    TI__Guru** 115271 points

    Hi,

    Jeremy Harbaugh said:
    The value at 0x0005F004 remained 0xFFFFFFFF while viewing with the Memory Browser. I was also unable to directly edit this value in the memory browser, which was recommended in some forum postings.

    You need to remove the DSECT attribute from this else it'll not be programmed. We also have security tool to generate the required configuration to avoid such issues. You can refer this application report for using this tool. 

    Jeremy Harbaugh said:
    After failing to write to the Z1_BOOTCTRL register, I decided to try to work around the issue using EMU_BOOTCTRL. I was able to edit the 0x0D00 location with 0x045A, however I ran into a breakpoint each time I tried to kick off a CPU reset from CCS. I did not notice any effect from a System Reset or a Restart command - the blinky application continued to execute as if there was no interruption.

    Please confirm that you clicking on the run after issuing the reset from CCS. If you are using the restart then it'll not work.

    Regards,

    Vivek Singh 

  • 0
    Prodigy 10 points

    I attempted to use the DCSM Tool from the application report, but it does not appear to support our device. I get the following error message when trying to open the dcsm_security_tool.syscfg associated with the blinky project example for the processor:

    Octagonal sign Device not found: F28X7X. This device may be available in a newer version of SysConfig

    Our device is the F28379S.

    If we proceed past the error, the normal SysConfig tool opens, not the special GUI interface described in the application note. I can't proceed with the DCSM Tool workflow past this point.

    In the application note, it mentioned that there are prerequisites:

    • For F2838x devices, C2000WARE version 3.04.00.00 and later is required (we have 4.03.00.00)
    • The C2000 DCSM Security Tool is a SysConfig-based tool that requires CCS version 9.2 or higher (we have 12.1.0)

    So, we should be compliant per the application note.

    In the alternative, you mentioned that removing the DSECT attribute should allow the registers to be programmed. I now understand what the blinky project is trying to do and removed the attribute from the linker file for the Z1 registers (in 2837xS_dcsm_lnk_cpu1.cmd) and uncommented the values in DCSM_Z1_ZoneSelectBlock.asm. Unfortunately, the registers still didn't take on the value I was trying to program:

    .sect "dcsm_otp_z1_bootctrl"
    .long 0xFFFFFFFF ;Reserved
    .long 0xFFFF045A ;Z1-BOOTCTRL

    Any ideas on what to do next? I'd prefer to use the tool, but I can't work around the error mentioned above.

  • 0 in reply to Jeremy Harbaugh
    TI__Mastermind 27600 points

    Hey Jeremy,

    Adding a .syscfg file to a bitfield example such as blinky_with_DCSM won't work, since SysConfig is built on top of driverlib. Could you try the following steps instead?

    • import the emtpy_bitfield_driverlib_project from the device_support/f2837xs/examples/cpu1/empty_project folder
    • Right click on your project to add a new file. Call it anything you wish but make sure it has the .syscfg file extension.
    • CCS should ask you if you want to enable sysconfig support, click yes
    • In Project Properties -> Build -> SysConfig -> Basic Options, input "F2837xS" in the --device field
    • Double click on your .syscfg file. Scroll down on the left tab until you see DCSM and add an instance of the DCSM module

    From here you should see a very similar GUI to that seen in the application note Vivek provided. New DCSM features are added from device to device so the GUI won't be exactly the same, but the same concepts still apply.

    The approach you tried without using the DCSM tool seems correct. Could you check 0x7801C - 0x7801F in the memory browser? Is it still all Fs? The boot-ROM should load the values programmed at this field into the Z1_BOOTCTRL register.

    Does programming using the DCSM tool resolve this issue?

    Thank you,

    Luke