• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 86 subscribers
  • Views 250 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.

TMS320F280039C: DCAN Bootloader Issue

Rupesh Yadav
Prodigy 150 points

Part Number: TMS320F280039C

Hi Team

The customer has implemented a flash based DCAN Bootloader kernel same as the SDK dcan_kernel example on a custom control card.

The main fw (bank0,bank1) switches to kernel(bank2,0xa8000) using LB for application update based on an particular CAN message.

The CAN bitrate is set to 500kbs and the flash_progammer has been modified to send out just the application.

The process runs successfully by switching from main fw to kernel, if switchToXTAL (inside kernel) is set to 1.But this requires min sleep_time of 75ms on proagmmer side. Otherwise CAN frame are corrupted or Missing.This results in overall time of 8 mins

If the switchtoXTAL is set to 0. The kernel is able to load the new application with very less sleep_time(10ms) but works only when the kernel is loaded directly from ccs.In this case if we switch from main fw to kernel, The kernel gets stuck on DCAN_ReadMessage().

The external crystal used in control card is 10MHz. The kernel project used INTSOC2 as defined in device.h.

Let me know if you need any other information

Looking forward to your inputs on the above two issues.

Regards,

Rupesh Yadav 

  • 0
    TI__Expert 4190 points

    Hi Rupesh,

    Changing clock sources and bitrates may affect your CAN bit timings. Can you confirm the CAN_CALC_BITRATE, CALC_CALC_CANCLK, and CALC_CALC_BITTIME values in bootloader_can_timing.h are correct?

    Also, a couple other clarifying questions:

    1. When is switchToXTAL set to 0?

    2. What do you mean kernel is loaded directly from CCS? What is the normal way you load it?

    Best,

    Alex

  • 0
    TI__Prodigy 150 points

    Hi Alex,

    Here are the timing parameters based on 10MHz crystal for 500Kbps

    #define CAN_CALC_BITRATE 500000U
    #define CAN_CALC_CANCLK 10000000U
    #define CAN_CALC_BITTIME 20U.

    1. When is switchToXTAL set to 0?

    It is passed to the  DCAN_Boot(CAN_BOOT_ALT3, 0, 1) as either 0 or 1.

    2. What do you mean kernel is loaded directly from CCS? What is the normal way you load it?

    The kernel is loaded into  FLASH_BANK2_SEC8_15  : origin = 0x0A8002, length = 0x007FED using CCS load feature.

    What I mean is if the kernel is loaded into the device ,the device directly runs the kernel without first running the main FW.

    The boot process is successful. In this case the main firmware did not jump to the stored kernel rather the device booted directly to kernel

    Let me rephrase the behaviors for these two versions of kernel for better clarity

    V1: XTAL as source for CAN: DCAN_Boot(CAN_BOOT_ALT3, 0, 1)

    • This successfully works by allowing the main FW to long branch to Kernel and then load the new image.
    • However requires, minimum frame delay (sleep_time) of 75ms from the programmer side, Significantly increasing the total time to around 8min.
    • The CAN fails to receive proper data if delay is reduced further, corrupted as well as incomplete data is received

    V2: Not Switching to XTAL: DCAN_Boot(CAN_BOOT_ALT3, 0, 0)

    • Long branching to this kernel from main FW: Kernel gets stuck on DCAN_readMessage()
    • However, If the device is directly put into debug/standalone mode with this kernel (that is not requiring the LB form main FW)
      • This is successfully able to load the new FW with minimal frame delay of 10ms

    All timing parameters as well other configurations are same in both the cases.

    Regards,

    Rupesh

  • 0 in reply to Rupesh Yadav
    TI__Mastermind 29823 points

    Hi Rupesh,

    Apologies for the delayed response here.

    Help me understand your V1 bullet 2 - requires minimum frame delay of 75ms from the programmer side.

    What defines this requirement?

    Also bullet 3 - CAN fails to receive proper data if delay is reduced further.

    How is this tested?

    I did a quick analysis using the attached CAN Bit Timing Calculator attached below for further analysis.

    /cfs-file/__key/communityserver-discussions-components-files/171/Copy-of-CAN-Bit-Timing-Calculator.xls

    This indicated a Bit Time (Tq) of 10 (vs the 20 shown in your response). Can you confirm your timing parameters are correct for the expected CAN Bus communications according to the calculator?

    Best Regards,

    Zackary Fleenor

  • 0 in reply to Fleenor
    TI__Prodigy 150 points

    Hi Zacakary,

    Thanks for the reply, would like to resolve this offline for quicker resolution.

    I have sent you a mail already for this.

    Thanks for understanding!