• State
  • Locked Locked
  • Replies 8 replies
  • Subscribers 82 subscribers
  • Views 322 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: longer SCI flash update times?

Emma Williams
Prodigy 80 points
Part Number: TMS320F28379D
Other Parts Discussed in Thread: C2000WARE

Hello, 

I have gotten the C2000Ware SCI flash programmer examples working for both the F2837xD and F280039C processors. 

I timed the programming of the blink LED program in the C2000Ware SDK.

For both I am setting the baud rate when calling the serial_flash_programmer to 115200. If I try to go higher than that it does not work. And looking at the times below I am not sure why the download rate is so much less than the 115200 I pass in as a parameter to the serial_flash_programmer?

F280039C 

  • Kernel download time - 16 sec
  • Blink LED download time - 2 sec
  • Total time - 18 seconds
  • Kernel bit rate - 9600 bps
  • Blink LED bit rate - ~42000 bps

F2837xD 

  • Kernel download time - 4:35 min
  • Blink LED download time - 3 seconds
  • Total time - 4:38 min
  • Kernel bit rate - 500 bps
  • Blink LED bit rate - ~28000 bps
  1. Since these processors are from the same family I would think they would perform somewhat similar?
  2. Could someone explain the discrepancy?
  3. Why is the download bit rate for the flash kernel so slow in the F2837xD case (4:35 min)?
  4. And if there is a way to close the gap so the download times resemble each other (i.e. increase baud rate, etc.)?

Also note for the F2837xD case I am using the SCI Boot 1 and C:\ti\c2000\C2000Ware_4_02_00_00\utilities\flash_programmers\serial_flash_programmer\f2837xD_fw_upgrade_example\F2837xD_sci_flash_kernels_cpu01_alt.txt

Thanks for any input!

-Emma

  • 0
    TI__Genius 15080 points

    Hi Emma,

    1) The F28003x device is a single core 32-bit DSP operating at max 120Mhz system clock. The F2837xD device is a dual-core architecture operating at 200Mhz. 

    2) The F2837xD is a dual-core example and uses a different connector.

    3) Both devices use the same download function within the host programmer for the kernel. The speed of the cable used also plays a role. The F28003x launchpad uses the XDS110 usb connector and the F2837xD uses an XDS100v2 connector. (Correction from device manager)

    4) This is something that I'll have to look into and get back to you.

    Thanks and regards,

    Charles

  • 0 in reply to Charles Roberson
    Prodigy 80 points

    Hi Charles, 

    Thank you for the response. 

    To clarify, the type of serial connection to the processor plays a larger role in download speed, regardless of what the bit rate is set to?

    I found in the F2837xD User Guide that the connector is a XDS100v2 and for the F28003x it is a XDS110. Is that the same thing you were referring to in #3 above? You state XDS100 for F2837xD and 100v2 for F28003x?

    Many thanks,

    Emma

  • 0 in reply to Emma Williams
    TI__Genius 15080 points

    Hi Emma,

    Yes, 

    Was mistaken on the connectors, had them swapped around. But yes, should be XDS100v2 for F2837xD and XDS110 for F28003x.

    Going back to item #4, this may be related to higher baud rates and the autobaud-lock feature. Taken from the TRM for F2837xD.

    The slew rate of incoming data could be affected.

    Thanks and regards,

    Charles

  • 0 in reply to Charles Roberson
    Prodigy 80 points

    Hi Charles, 

    I was recently able to try this out.

    Unfortunately, decreasing the baud rate didn't have an effect on the download time of the kernel.

    Is 500 baud what you'd expect it to be? (It's just really slow) 

    My understanding is that autobaud is mainly used so the user doesn't have to pre-set a baud rate before communication (helpful for when devices are running at different speeds). 

    If this is the case why does the flash programmer prompt the user for a bit rate that it doesn't use?

    Thank you for the response and info as always,

    Emma

  • 0 in reply to Emma Williams
    TI__Genius 15080 points

    Hi Emma,

    The bitrate is set in the flash programmer and the autobaud lock feature of SCI is used to lock the baudrate with the host. 

  • 0 in reply to Charles Roberson
    Prodigy 80 points

    Hi Charles,

    Ah, so altering the flash programmer wouldn't do anything to change the bit rate because autobaud is taken care of by the SCI module itself? 

    If the SCI module autobauds for both the kernel and the blinky application, why does the SCI module choose 500 baud for the kernel and 28000 baud for the application?

    Regards,

    Emma

  • 0 in reply to Emma Williams
    TI__Genius 15080 points

    Hi Emma,

    If the flash programmer is altered, it should still see a change with the SCI module.

    The SCI module should follow the baudrate set by the host, I'll have to discuss this with my team to see what can be done.

    Thanks and regards,

    Charles

  • 0
    TI__Genius 15080 points

    Hi Emma,

    In relation to the long programming time, do you have the devices connected directly to the machine or to a dock station?

    This could be affecting the download time as well.

    Thanks and regards,

    Charles