• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 82 subscribers
  • Views 103 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.

TMS320F28379D: Remote programming of f28379d -Directly to RAM via SCI boot every power cycle without flash kernel

ABHAY VASHISTHA
Prodigy 10 points

Part Number: TMS320F28379D
Other Parts Discussed in Thread: C2000WARE

Hello TI Community,

We have a custom board with the following architecture:
- NXP LPC4088 ARM Cortex-M4 as master controller (running RT-Thread RTOS)
- TMS320F28379D as DSP
- FPGA on the same board

Boot sequence every power cycle:
1. LPC4088 boots first
2. LPC4088 programs the FPGA via  serial 
3. LPC4088 then needs to load and run the DSP application

DSP connections to LPC4088:
- GPIO42 (SCITXDA) → LPC4088 UART RX
- GPIO43 (SCIRXDA) → LPC4088 UART TX

Boot pins are fixed as:
- TRST=0, GPIO72=0, GPIO84=1 (SCI-A Boot Mode)

Our requirement:
- DSP firmware will change frequently
- We want LPC4088 to load the latest DSP application every boot cycle via SCI
- We want to avoid Flash programming every boot to prevent flash wear.

Our Question:
Can LPC4088 send the DSP application DIRECTLY into DSP RAM using the SCI bootloader protocol (same format as hex2000 -boot -a -sci8 output) WITHOUT using the flash kernel (F2837xD_sci_flash_kernels_cpu01.txt) at all?

Our understanding from the TRM and boot ROM documentation:
1. DSP powers up in SCI boot mode
2. DSP BootROM automatically configures GPIO42/43 as SCITXDA/SCIRXDA
3. DSP sends 0xAA for autobaud detection
4. Host responds with 0xAA 0x08 key value
5. Host sends 16 reserved bytes
6. Host sends entry point address
7. Host sends data blocks (block size + start address + data)
8. Host sends 0x0000 end marker
9. BootROM branches to entry point and DSP starts executing from RAM

If this is correct, the flash kernel is only needed when we want to PROGRAM FLASH — and for our use case of loading to RAM every boot, we can skip the kernel entirely and just implement the SCI boot protocol directly on LPC4088?

Additional questions:
1. Is there any timing requirement between DSP power up and receiving the 0xAA — how long does the BootROM wait before timing out?
2. Does the DSP application need any special linker configuration to run from RAM vs Flash?
3. Is there any limitation on RAM size for the application — which RAM regions are safe to use for application loading via SCI boot?
4. Any gotchas or known issues with this approach on F28379D specifically?

We have already verified:
- COM port communication working (loopback test passed)
- Right now i am trying to flash using this command but stuck at Line : Downloading ....

C:\ti\c2000\C2000Ware_1_00_02_00\utilities\flash_programmers\serial_flash_programmer>serial_flash_programmer.exe -d f2837xD -k F2837xD_sci_flash_kernels_cpu01.txt  -a blinky_cpu01.txt -p COM8 -b 9600

C2000 Serial Firmware Upgrader
Copyright (c) 2013 Texas Instruments Incorporated.  All rights reserved.

getting comm state
building comm DCB
adjusting port settings

calling f021_DownloadKernel CPU1 Kernel
Downloading F2837xD_sci_flash_kernels_cpu01.txt to device...

41==0^C

Thank you in advance for your help!

  • 0
    TI__Mastermind 20380 points
    ABHAY VASHISTHA said:
    If this is correct, the flash kernel is only needed when we want to PROGRAM FLASH — and for our use case of loading to RAM every boot, we can skip the kernel entirely and just implement the SCI boot protocol directly on LPC4088?

    Yes, that is correct. A flash kernel is only necessary when the on-chip flash is needed to be programmed.

    ABHAY VASHISTHA said:
    1. Is there any timing requirement between DSP power up and receiving the 0xAA — how long does the BootROM wait before timing out?

    There is no timeout for SCI boot on the F2837xD. It will wait in autobaud lock until the correct key value is sent.

    ABHAY VASHISTHA said:
    2. Does the DSP application need any special linker configuration to run from RAM vs Flash?

    I would refer to the example RAM linker command files in C2000Ware, specifically: C2000Ware_26_00_00_00\device_support\f2837xd\common\cmd\2837xD_RAM_lnk_cpu1.cmd

    ABHAY VASHISTHA said:
    3. Is there any limitation on RAM size for the application — which RAM regions are safe to use for application loading via SCI boot?

    The only limitation is to not load code to the stack which resides in RAMM0 block of memory. I cannot think of any other limitations.

    ABHAY VASHISTHA said:
    4. Any gotchas or known issues with this approach on F28379D specifically?

    Sometimes other users attempt to use an incompatible baud rate that is too high, but that doesn't seem to be the case here (you configured 9600 bps).

    I would double check your data stream structure. Specifically, for your step (3), you state that the DSP (F2837xD) sends 0xAA. The Host should be sending 0x08AA to the DSP. This is the autobaud character / key value.

    Best,
    Matt