• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 83 subscribers
  • Views 210 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TMS320F28388D: F28388D CPU1/CPU2 working mode

mik brigante
Prodigy 120 points
Part Number: TMS320F28388D
Other Parts Discussed in Thread: TMDSCNCD28388D, C2000WARE

Dear experts,

for my work I am dealing with the porting from TMS320F2807x (Piccolo) to TMS320F28388D. I bought the TMDSCNCD28388D.

 

Currently I am able to upload the code in flash by means of XDS200v2 on-board USB debugger and execute the code on CPU1.

 

I want improve the performance of my application by exploiting the potential of the dual core.

Because I am a beginner, I took a cue from the TI examples.

 

Within the pdk C2000Ware_3_04_00_00 there are several project examples.

I noticed that there are always two  files to be compiled, each for a specific core.

Specifically each project contains:

  • two C-code files (e.g. dma_ex1_shared_periph_cpu1.c and dma_ex1_shared_periph_cpu2.c);
  • two linker files (e.g. 2838x_FLASH_lnk_cpu1.cmd and 2838x_FLASH_lnk_cpu2.cmd);

and so on…

 

So I imagine that, in order to work with both cores, I should compile the files for CPU1 and upload them in core CPU1; then I should do the same on CPU2.

 

Is there an example in which there is a unique project for dual core application?

  • g. a single C-code file in which I decide where to execute the instructions by means of “ifdef CPU1”  and “ifdefCPU2”;
  • g. a single linker in which I decide where to store the data by means of “ifdef CPU1”  and “ifdefCPU2”.

 

Waiting for a your feedback.

Best regards.

Mik Brigante Sanseverino

  • 0
    TI__Mastermind 31525 points

    Hi,

    All the dual core examples in C2000ware are provided as 2 separate projects - 1 for each core. The only difference between these projects is the predefined symbol CPU1/CPU2 and the linker command file being used. If required, you combine them to a single project - have separate build configurations for each core. We do not have an example projectspec which showcases this. But you can use an existing single core example and add a new build configuration with CPU2 predefined symbol and updated linker command file.

    Regards,

    Veena

  • 0 in reply to Veena Kamath
    Prodigy 120 points

    I'm sorry, but this answer doesn't help us.

    We have created two distinct and separate projects, with their own linkers, their own peripherals, their own temporal interrupts, using the predefined symbols CPU1 and CPU2 when creating the applications.

    Our next step must be to put all the files under a single Code Composer project, use common linkers and manage, in parallel mode, peripherals, interrupts and source code destined for each CPU.

    Our question arose from this need and consequently we asked you for a specific application example. But if you have never addressed the question in detail, the answer is too general and not very consistent.

    We have already arrived at these abstract theoretical indications by ourselves, we sincerely would have expected a much more significant added value from the TI experts.

    We thank you, however, for the quick reply.

  • 0 in reply to mik brigante
    TI__Mastermind 31525 points

    Hi,

    Unfortunately, we don't have a dual core example using a single CCS project in C200ware.

    I would also like to add that all the dual core examples, even though we have separate projects, we use the exact same drivelib.lib, or other source files. The difference is mainly taken care by the CPU1/CPU2 predefine. (Except linker cmd file and main.c, which we provide as separate files). Whether it is built as 2 different CCS projects or 2 different build configs in a single project, finally we have 2 separate .outs - 1 for each core, and I believe the generated .outs should ideally be the same in both cases.

    Can you help me understand the advantage of having both in a single project? Is it for better code maintenance? We can definitely raise a requirement to C2000ware team to add such an example if there is a gap.

    Regards,

    Veena

  • 0 in reply to Veena Kamath
    Prodigy 120 points

    Dear Veena Kamath,

    Currently we work on the TMS320F28388D control card and we manage the code uploading in flash by means of XDS200v2 on-board USB debugger.

    This is only  a preliminary step in our work.

    Once the code works well on the evaluation board, we will migrating to our custom electronic board that is based on the microcontroller F28388D.

    Therefore, we will not have the debugger.

    We will “write” the flash memory  by means of a unique custom bootloader.

    It would obviously be useful if the C2000ware group also provided different examples of work and development, more complex and more structured, because, in practice, these are the real conditions in which companies find themselves operating.

    I honestly believe that the examples currently provided are too simple, more suitable for a high school student than for real software designers.

  • 0 in reply to mik brigante
    TI__Expert 5630 points

    Hi Mik, 

    The F2838x SCI Flash Kernels are available in C2000Ware_4_00_00_00 and can be used to write firmware to Flash without using JTAG. 

    This is the path in C2000Ware to the kernels: C2000Ware_4_00_00_00\driverlib\f2838x\examples\c28x_dual\flash_kernel

    Path to the host side programmer needed for the kernels: C2000Ware_4_00_00_00\utilities\flash_programmers\serial_flash_programmer

    There is an Application Note that explains the functionality of the Flash kernels and includes a section on the F2838x kernels and usage instructions: https://www.ti.com/lit/an/sprabv4e/sprabv4e.pdf

    The CPU1 kernel is streamed in via the SCI Bootloader in ROM and can be used to write in the firmware for CPU1 into Flash. The CPU1 kernel can then be used to stream in the CPU2 kernel. The CPU1 kernel transfers control of SCI to the CPU2 kernel once it is written into RAM. After this, the CPU2 kernel will be able to write in the firmware for CPU2 into Flash.

    Thanks, 

    Anu