• State Resolved
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 5 replies
  • Subscribers 85 subscribers
  • Views 823 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.

Original question:

TMS320F280039C: Question about MCAN

TMS320F280039C: Firmware update with MCAN vs DCAN

Emma Williams
Prodigy 80 points

Part Number: TMS320F280039C
Other Parts Discussed in Thread: C2000WARE

Hello, 

I've been testing the time it takes to boot to flash for different sized programs (by adding nop functions to the LED program to make it bigger) using the can flash programmer example in the C2000Ware. For a large program (918KB for the out file) it takes roughly 10-11 minutes to download to and run from flash. I was initially confused why it took so long because according to PCAN view I was running at 1MBit/s. 

Is what's taking most of the time the transmission of the kernel and firmware or is it the writing of the firmware into flash?

Or in other words, is the limiting factor the bit rate/payload size (something I can change) or instead the time it takes to write to flash (something I'm not sure I can change)?

I wanted to ask because I wanted to know if using the MCAN/CAN FD instead of the DCAN/regular CAN would decrease the time of a firmware update?

Thanks, 

Emma

  • 0
    TI__Genius 15080 points

    Hi Emma,

    > Is what's taking most of the time the transmission of the kernel and firmware or is it the writing of the firmware into flash?

    After the sending of the kernel, the host will sleep for 5 seconds as kernel re-initializes the MCAN. Then, as the application is being downloaded by the host, each 64 bytes per frame is being written to device, with a wait time of 100ms for the Flash API to write each block in. 

    >Or in other words, is the limiting factor the bit rate/payload size (something I can change) or instead the time it takes to write to flash (something I'm not sure I can change)?

    Limiting factor would be time to write to flash. We can increase the bitrate, but the flash will still need the appropriate amount of time to write in the block.

    > I wanted to ask because I wanted to know if using the MCAN/CAN FD instead of the DCAN/regular CAN would decrease the time of a firmware update?

    By definition, MCAN will offer better length and speed for the transmission of your data. Speed for nominal rate can vary between 500kbps to 1Mbps, data rate from 1Mbps to 5Mbps. Another advantage for the MCAN is the bit-rate switching capability and increased payload size. The firmware update is limited by the time needed for the Flash API to write blocks in. It's possible to experiment with the amount of time needed to write each Flash API block by modifying the host source with Visual Studio, this way you could see if it would decrease the overall transfer speed. 

    Thanks and regards,

    Charles

  • 0 in reply to Charles Roberson
    Prodigy 80 points

    Hi Charles,

    Thank you for the response and information.

    Just to make certain I understand, the host side program has a 100 msec wait time before sending each 64-byte frame down to the processor to get programmed into flash and you are suggesting reducing this 100 msec wait time in the Visual Studios project to see if we can get the overall programming time down?

    Do you know why this time is set for 100 msec? Just an arbitrary value?

    If you look at JTAG, programming the same program is a lot faster. I am wondering why in the case of the CAN flash programmer, if programming the FLASH block is the limiting factor, why is it so much slower in the CAN flash programmer case than with JTAG?

    Thanks again for the help!

    Emma

  • +1 in reply to Emma Williams
    TI__Genius 15080 points

    Hi Emma,

    Yes, suggesting that to reduce time. I have tested bringing the wait time down to 50 msec and it still is operational with the LED blinky example. The time is set as 100 msec generally to ensure stability for the transfer. The timing for the Flash API can be found in the Section 6.12.4.1 of the device datasheet, where 100 msec is listed as the max time for program of 8KB sector.

    In comparison to JTAG, this is something I'll have to look into and see what optimizations can be made for the host. 

    Will update you on what I find.

    Thanks and regards,

    Charles

  • 0 in reply to Charles Roberson
    Prodigy 80 points

    Hi Charles

    I was able to rebuild after modifying it to 50ms.

    Thankyou for the reference and the help!

    -Emma

  • 0 in reply to Emma Williams
    TI__Genius 15080 points

    Hi Emma,

    Glad to hear you could rebuild the project. Closing this thread for now.

    Thanks and regards,

    Charles