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: SCI-A Communication - Boot Mode Configuration

Part Number: TMS320F28388D
Other Parts Discussed in Thread: TMDSCNCD28388D

Hi all!

I have some questions regarding the SCI Boot mode with the serial flash programmer. 

My aim

Using the serial flash programmer, I want to program the DSP with SCI boot mode through different pins than default ones.

Question and Context

I want to change boot configuration for using different pins for SCI Boot configuration. As setup I'm using:
- f28388d Evaluation Board (TMDSCNCD28388D)
- HSEC180 Control Card Baseboard Docking Station
- USB to serial converter card custom

To perform tests, I decided to write the EMUBOOTPINCONFIG and EMUBOOTDEF registers as follows:

0x00000D00 -> FF0F
0x00000D01 -> 5AFF
0x00000D02 -> not useful/nothing written
0x00000D03 -> not useful/nothing written

0x00000D04 -> 4103
0x00000D05 -> FFFF
0x00000D06 -> FFFF
0x00000D07 -> FFFF

In this way, I'm going to use for SCI Boot the GPIOs 35 and 36, specifically the first for SCIRXDA and the second for SCITXDA. 

What happens, is that, after a chip reset, I communicate with the DSP through these GPIOs through the serial flash programmer with the following bash command: 
serial_flash_programmer.exe -d f2838x -k flash_kernel_c28x_dual_ex1_c28x1.txt -a led_ex1_c28x_dual_blinky_cpu1.txt -m flash_kernel_c28x_dual_ex1_c28x2.txt -n led_ex1_c28x_dual_blinky_cpu2.txt -b 9600 -p COM12 -v


The problem is that the program remains stuck in autobaud after loading the kernel in CPU1 as shown in the picture, I would expect that it shows the serial flash programmer menu with the different alternatives. Which is strange as an autobaud was performed correctly before loading the kernel.  The communication seems to work, but I cannot do anything after the kernel is loaded.

I'm in doubt on how to continue and I'm really wondering how to solve this problem.

Best Regards,
Luca Predieri

 

  • Hi Luca,

    Have you adjusted the Boot Mode being passed to the sciGetFunction() within flash_kernel_c28x_dual_ex1_sci_flash_kernel_cpu1.c? By default, the SCI_BOOT mode is passed to this function and uses GPIO 28 and 29. If you are using GPIO 35 and 36, SCI_BOOT_ALT2 should be passed as the boot mode. I believe that after the kernel is downloaded to the device via GPIO 35 and 36 (due to the configuration you have described above) it begins running the kernel code and GPIO 28 and 29 are being re-configured as the SCI communication pins. 

    Kind regards,

    Skyler

  • Hi Skyler,

    First, thank's for the fast answer.
    I did what you said about the SCI_BOOT_ALT_2 in the sciGetFunction() in the code. I rebuilt the project (flash_kernel_c28x_dual_ex1_c28x1) and converted the flash_kernel_c28x_dual_ex1_c28x1.out file with:

    hex2000.exe -boot -sci8 -a -o flash_kernel_c28x_dual_ex1_c28x1_3536pins.txt flash_kernel_c28x_dual_ex1_c28x1.out

    in order to pass it as a sci8 file to the dsp. Then, i called:

    serial_flash_programmer.exe -d f2838x -k flash_kernel_c28x_dual_ex1_c28x1_3536pins.txt -a led_ex1_c28x_dual_blinky_cpu1.txt -m flash_kernel_c28x_dual_ex1_c28x2.txt -n led_ex1_c28x_dual_blinky_cpu2.txt -b 9600 -p COM12 -v

    again, after loading the kernel the dsp is stuck. Am I missing something converting the file using hex2000.exe? 

    Best Regards,
    Luca

  • Hi Luca,

    After the kernel is loaded and autobaud fails, can you try pausing the execution of the DSP and loading the symbols associated with flash_kernel_c28x_dual_ex1_c28x1.out? I want to see if the device is running the kernel code and fails the autobaud lock, or if the device fails to branch to the kernel for some other reason.

    Kind regards,

    Skyler

  • Hi Skyler, here's the screen capture with the symbols loaded. Seems that the code is stuck in the sciGetFunction().

    Thank's again for the patience,

    Luca

  • Hi Luca,

    Can you try setting the EMU_BOOTPINCONFIG and EMU_BOOTDEF registers as seen below:

    0x00000D00 -> FFFF
    0x00000D01 -> 5AFF
    0x00000D02 -> not useful/nothing written
    0x00000D03 -> not useful/nothing written

    0x00000D04 -> 0041

    Kind regards,

    Skyler

  • Hi Skyler,

    I tried many things and loss myself between some different projects, I was debugging the wrong serial flash programmer.

    Anyway, the real issue was that was missing the SCI_BOOT_ALT2 macro inside the function.

    thank's for you time and solution!