• State
  • Locked Locked
  • Replies 11 replies
  • Subscribers 82 subscribers
  • Views 410 views
  • Users 0 members are here
Support feedback
Options
Options

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.

TMS320F28377D-EP: SPI external Flash memory boot for CPU1 and CPU2

Jaejun Lee
Prodigy 10 points
Part Number: TMS320F28377D-EP
Other Parts Discussed in Thread: TMS320C28346, C2000WARE

Tool/software:

I am trying to make standalone mode of module by using TMS320F28377D-EP and this module have to use dual core(CPU1 and CPU2) at this project.

But, I can't get understand how to make this project.

I've developed standalone mode of module by using TMS320C28346 with external SPI Flash boot.

When I used TMS320C28346,

I got the 'hex conversion file' from example, 

so,

I could change project.out file to project.hex file.

By using this project.hex, I could write external SPI Flash boot.

And then I could boot load from SPI Flash boot.

But,

When I trying to make standalone mode of module by using TMS320F28377D-EP and this module have to use dual core(CPU1 and CPU2) at this project.

I don't know how to make stand alone  of module by using TMS320F28377D-EP with dual core,

because, I can't find the example for dual core external SPI flash boot loader.

If you have, please could you provide me?

And,

If not, I have some additional qusitions.

1. When I use TMS320F28377D-EP with dual core with external SPI flash boot loader, do i have to make each hex file for each CPU? [CPU1.out --> CPU1.hex , CPU2.out-->CPU2.hex] 

or is there other hex conversion file to make one hex file about both CPU1.out and CPU2.out ?

2. if i have to make each hex file for each CPU [CPU1.out --> CPU1.hex , CPU2.out-->CPU2.hex], then can I use same hex conversion file that i have used before in TMS320C28346 project about each CPU1.out and CPU2.out file.

3.  if i have to make each hex file for each CPU [CPU1.out --> CPU1.hex , CPU2.out-->CPU2.hex], and If I use only one SPI flash memory for two hex files, do I have to store them(two hex files) in different memory addresses?

4. And then, make CPU1 boot load same as method When I used TMS320C28346, and then, CPU2 can be boot loaded by command in CPU1(master)? 

5. I must load each CPU1 and CPU2 boot loader from each memory address, that was fixed during storing in Flashe memory.

About above 5 sequence, is it correct or not?

Thank you

  • 0
    TI__Expert 4125 points

    Hi Jaejun,

    We don't have a dual-core SPI boot loading example for F2837xD, but you can reference the device's SPI boot loader source in the boot ROM.  (libraries\boot_rom\f2837xd\revB\rom_sources\F2837x_bootROM\cpu01-bootROM\source).

    The F2837xD TRM (see Section 4.10.4.3) provides additional resources on how to configure the device for SPI boot mode as well. 

    You can also look at the SCI boot example (device_support\f2837xd\examples\dual\F2837xD_sci_flash_kernels) with an associated user guide for reference on how to develop dual-core boot loaders. 

    As for your questions:

    1. Yes, you'll have to make hex files for each CPU core.
    2. You can use the C2000 Hex Utility built into CCS to generate the hex files. You can find it in the Project Properties > Build > C2000 Hex Utility. Chapter 12 of the Assembly Language Tools User Guide details the Hex Utility options.
    3. Yes, each core "owns" a flash bank that the other core cannot read/write in. 
    4. I recommend you refer to the boot flow diagrams in the TRM (page 621) for how the boot flow executes in a dual-core context. 
    5. Yes, you must load each core's hex file from their respective memory addresses.  

    Best,

    Matt

  • 0 in reply to Matt Kukucka
    Prodigy 10 points

    Thank you for your reply.

    But, 

    When I checked your reference, i think that it not same as that i think.

    I think My question is wrong that explain what i want.

    So, I ask to you again what I want to do.

    1. Do you know? C28346 DSP, this dsp don't have flash, so, user must use external flash.  And I am one of C28346 user.

    2. At that time I've used, C28346 external SPI flash memory by refering example.

    3. When i used C28346 example, cpu can run our firmware by booting from SPI flash. My firmware just set the boot mode.  My firmware don't have SPI SW to load by using SPI.  I can load my firmware from just setting SPI booting.

    4. Simialar as C28346 SPI Flash booting, I want to make CPU1 and CPU2 make boot from extenal SPI flash.  I think your resource  (libraries\boot_rom\f2837xd\revB\rom_sources\F2837x_bootROM\cpu01-bootROM\source), it's different method that i expected.

    5. To be honest, I've used CPU1 SPI flahs booting with TMS320F28377D-EP same as method of C28346, it works well. But, I want to make CPU2 work same as this method.  But, I don't know how to boot CPU2 from extenal SPI flash. 

    Thank you.

  • 0 in reply to Jaejun Lee
    TI__Expert 4125 points

    Hi Jaejun,

    From my understanding, you're trying to make a SPI bootloader that loads from external SPI flash and uses both CPU1/CPU2 on F2837xD. You want to use the CPU2 SPI bootloader but don't know how to configure to CPU2 boot.

    Below is from Chapter 7.10 in the F2837xD TRM:

    Essentially, CPU2 is put into WAIT boot mode until CPU1 is done booting. Then, the CPU1 application instructs the CPU2 boot ROM on how to boot further using boot mode IPC commands supported by CPU2 boot ROM. The IPC user guide for F2837xD details the API functions to accomplish this.

    Some examples:

    • CPU1 to CPU2 IPC drivers at: <C2000Ware Root>\device_support\f2837xd\examples\dual\cpu01_to_cpu02_ipcdrivers
    • CPU2 to CPU1 IPC drivers at: <C2000Ware Root>\device_support\f2837xd\examples\dual\cpu02_to_cpu01_ipcdrivers"

    Please let me know if this does not fit your requirements.

    Best,

    Matt

  • 0 in reply to Matt Kukucka
    Prodigy 10 points

    Thank you for your kind Reply.

    I checked that you refered examples, 

    And I got the information CPU1 can make CPU 2 boot by using some resistor setting in CPU1 firmware.

    But,

    I have some more question.

    When I checked, SPI boot with CPU1 and CPU2,

    We can use SPI-A, It's mean we have to use one SPI flash memory that was connect to SPI-A.

    In this case,

    I don't know how to store each cpu's firmware at flash memory.

    Do we have to make Cpu1 and cpu2 each out file and make cpu1.hex and cpu2.hex each hex file?

    And store other address about cpu1.hex and cpu2.hex?

    if we make cpu1.hex and cpu2.hex and then we can store cpu1.hex and cpu2.hex at diffrent address in flash memory.

    Then, during bootload, how we can set start(entry) adress of external flash memory?

    When we set SPI flash boot, we can't set the external(SPI) flash boot memory, we just set the resistor, and bootloader make boot MCU automatically.

    So, I confused above situation.

    Do we have to make each cpu1.out and cpu2.out file and cpu1.hex and cpu2.hex file.

    And Dowe have to store cpu1.hex and cpu2.hex file at different external(SPI) flash memory?

    And, during CPU1 bootloading and CPU2 bootloading, how to set external(SPI) flash memory start address?

    Thank you.

  • 0 in reply to Jaejun Lee
    TI__Expert 4125 points

    Hi Jaejun,

    Jaejun Lee said:
    Do we have to make each cpu1.out and cpu2.out file and cpu1.hex and cpu2.hex file.

    Yes, each CPU needs it's own .out and .hex file.

    Jaejun Lee said:
    And Dowe have to store cpu1.hex and cpu2.hex file at different external(SPI) flash memory?

    Yes, you will need to do that. 

    Jaejun Lee said:
    And, during CPU1 bootloading and CPU2 bootloading, how to set external(SPI) flash memory start address?

    Based on my understanding of your use-case, you will need to implement an SPI Flash Kernel to copy the external (SPI) flash code into on-chip flash memory. The SPI bootloader loads the external flash code into RAM, not flash. The entry address returned by SPI_Boot is determined by the linker command file (.cmd) in the project that builds the external flash code. 

    In order to implement the desired behavior, a flash kernel will have to be used. The flash kernel is responsible for erasing the previous controller code, receiving the external flash application code, and programming the external flash code to flash memory by using the Flash API. The general flow of this process is as follows:

    1. Reset the device and use SPI Boot mode
    2. Transfer the flash kernel from external flash to the controller via SPI
    3. Flash kernel will take control after SPI Boot is complete
      1. Make sure that the .cmd file corresponding to the flash kernel is configured to be stored and run from RAM
    4. The kernel will erase the old application code from flash memory on the controller
    5. Kernel will configure an SPI connection with external flash and receive the new application code
    6. Kernel will write the newly received application code to flash memory and transfer control to it
    7. Newly received code from external flash will execute
    Matt Kukucka said:
    You can also look at the SCI boot example (device_support\f2837xd\examples\dual\F2837xD_sci_flash_kernels) with an associated user guide for reference on how to develop dual-core boot loaders. 

    This application note discusses the implementation of the SCI flash kernel for a few other devices, but the main ideas will be useful for understanding/implementing the SPI flash kernel for dual-core devices. 

    Best,

    Matt

  • 0 in reply to Matt Kukucka
    Prodigy 10 points

    Thank you for your meeting.

    From you answer,

    Based on my understanding,

    We have to belowe implementation.

    -->implement an SPI Flash Kernel to copy the external (SPI) flash code into on-chip flash memory.

    Is it mean do we have to transfer our firmware from external (SPI)flash to on-chip flash memory?

    And,

    if we make SPI flash kernel SW in our firmware, then can we set entry(start)adress about each CPU1.hex and CPU2.hex?

    To be honest,

    I confused one thing,

    becuase, in case of C28346, which has not internal flash, only can use external flash,

    when i used C28346, we can our firmware boot load from external(SPI) flash to RAM directrly without internal flash load as you anwered above.

    And,

    We tried successfully firmware boot load(SPI bootload) from external(SPI) flash to RAM directrly at F28377 when we use only CPU1. 

    It's mean we can SPI bootloader from external(SPI) flash to  F28377 RAM directrly without loading F28377 intenal Flash.

    At this case, we just add SPI bootloader from external(SPI) flash to  F28377 RAM at CPU2.

    if we want to make SPI boot load at CPU2, do we have to implement an SPI Flash Kernel to copy the external (SPI) flash code into on-chip flash memory?

    is it unavailalbe SPI boot loading at CPU2, without  loading F28377 intenal Flash? I want to load  SPI bootloader from external(SPI) flash to  F28377 RAM at CPU2 directrly.  Becuase we already have some SW in case of CPU1 SPI bootload.

     

    Just we don't know SPI boot load at CPU2. 

    Thank you.

  • 0 in reply to Jaejun Lee
    TI__Expert 4125 points

    Hi Jaejun,

    I understand now, you still want to execute the program from RAM and not from the F28377 on-chip flash. That is feasible, my previous reply still holds.

    Matt Kukucka said:
    The entry address returned by SPI_Boot is determined by the linker command file (.cmd) in the project that builds the external flash code. 

    Like CPU1, the address set by the linker command file (.cmd) for the CPU2 application will specify its location in memory. You will need two linker command files -- one for the .out/.hex for CPU1 and the .out/.hex for CPU2 -- to specify where they will be executed in RAM. 

    GSRAM can be split between CPUs. Please refer to the following examples of shared RAM linker command files in C2000Ware, which you can adapt for your specific application. 

    • device_support\f2837xd\common\cmd\2837xD_RAM_lnk_shared_cpu1.cmd
    • device_support\f2837xd\common\cmd\2837xD_RAM_lnk_shared_cpu2.cmd

    Best,

    Matt

  • 0 in reply to Matt Kukucka
    Prodigy 10 points

    Thank you for your reply.

    I want to check that my understanding is correct or not.

    We have to make each cpu1.out and cpu2.out and cpu1.hex and cpu2.hex.

    And then.

    We have to store cpu1.hex file at external(SPI) Flash memory at AxxxxA(address)

    And we have to store cpu2.hex file at external(SPI) Flash memory at BxxxxB(address), 

    cpu1.hex and cpu2.hex must store in external(SPI) Flash memory at different address.

     

    And then,

    CPU1 will search CPU1.hex file in external(SPI) Flash memory and bootloading, CPU1 SPI boot loader could be run by automatically, if we set the resistor properly.

    CPU2 will search CPU1.hex file in external(SPI) Flash memory and bootloading, CPU2 SPI boot loader could be run by automatically, if we set the resistor properly.

    if there is error about above concept, please let me know.

    Assuming above concept is correct,

    I have some questions.

    We have to store cpu1.hex file at external(SPI) Flash memory and store cpu2.hex file at external(SPI) Flash memory,

    To store these cpu1.hex and cpu2.hex at external(SPI) Flash memory,

     Can we use below example and function?

    In example 'BOOT_V500' project DSP2834x_M25P40.lib, or F2837xd_M25P40.c,

    I can see function 'ProgramExFlash(Uint32 Address, Uint16 Data)',

    By using function, Can I store cpu1.hex file at external(SPI) Flash memory at specific memory address and store cpu2.hex file at external(SPI) Flash memory at specific memory address which is different with CPU1.hex file address.

    Thank you.

  • 0 in reply to Jaejun Lee
    TI__Expert 4125 points

    Hi Jaejun,

    What external memory (model number) are you using and how were you able to do it previously on C28346?

    Apologies, it’s taking me more time to get input from the flash experts due to the holidays.

    Best,

    Matt

  • 0 in reply to Matt Kukucka
    Prodigy 10 points

    Thank you for your reply

    please could you let me know you e-mail address,

    I can't upload our HW part number in community.

    Thank you

  • 0 in reply to Jaejun Lee
    TI__Expert 4125 points

    Hi Jaejun,

    I sent you a friendship request, after you accept I can then send you my email over E2E direct messages. 

    Best,
    Matt