• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 84 subscribers
  • Views 773 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.

LAUNCHXL-F28P65X: Getting the CAN Flash programming example work

Luciano Vittori
Prodigy 100 points
Part Number: LAUNCHXL-F28P65X
Other Parts Discussed in Thread: C2000WARE, SYSCONFIG

Tool/software:

Hello TI Team,

I have successfully tested SCI serial flash programming, and I am now working on CAN flash programming. However, something may be missing in my procedure.

Steps Followed:

  1. Set the boot mode to CAN: S3 with GPIO72 high and GPIO84 low.
  2. Set S4 to XCRV position to route the CAN signals to the microcontroller.
  3. Connected two wires to the CANTX and CANRX test points for logic analyzer tracing.
  4. Imported the DCAN project and compiled it.
  5. Modified Byte 3 and Byte 4 in the output file as follows: AA 08 C0 7A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 00 00 00 00 41 00 48 16
  6. Executed the DCAN host program using the command: ./dcan_flash_programmer.exe -d f28p65x -k dcan_flash_kernel_c28x_dual_ex5.txt -a led_ex1_c28x_dual_blinky_cpu1.txt -v

Issue Observed:

According to my CAN captures, the host is sending frames, but the MCU never responds.

To debug, I recompiled the DCAN host program, commenting out the hex byte printing to focus on critical outputs. I noticed that the host application behaves identically whether the CAN interface is connected or not.

Questions:

  1. Should the BOOT ROM respond over CAN when the host sends the application?
  2. Are there any missing steps in my test procedure?

Any guidance would be greatly appreciated.

Thank you in advance,
Luciano

  • 0
    TI__Genius 15080 points

    Hi Luciano,

    1) Yes the BOOT ROM should respond when sending the application. Are you using both the Kernel and Host application provided for DCAN from C2000Ware? Also which C2000ware version?

    2) Are you using the PEAK systems CAN adapter with this project? Second, can you share what are the contents for the can_timing.h file in the project? 

    Thanks and regards,

    Charles

  • 0 in reply to Charles Roberson
    Prodigy 100 points

    Hi Charles,

    Yes, I am using the DCAN example and utility provided by TI in C2000Ware_5_04_00_00.

    I am also using a PEAK CAN interface, but it is not the PEAK CAN PRO.

    After several iterations, I would like to update you on my findings:

    • The first frame sent by the host application is the first word of the program file, but only when I connect the USB for the first time. After that, it never sends "0xAA, 0x08" again. Furthermore, the frame sent is always the same. I suspect the host application is waiting for an ACK before continuing with additional bytes.
    • I compiled the dcan_flash_programmer with the #define kernel line commented out, allowing me to upload the kernel into RAM via CCS in a debug session. At this point, I observed that when the flash kernel sends test frames, the baud rate is exactly 1.25 times the value defined in #define CAN_CALC_BITRATE 1000000UL.
    • To investigate further, I switched to Linux and created a Python script using SocketCAN to send messages at 125K, while setting CAN_CALC_BITRATE to 100K, and tested the setup again. However, the application failed after arround 10 CAN frames. I can see that a unique value is being written to memory at address 0x80000.
    • Previously, I tested a simple CAN application using the SysConfig tool, and it worked quickly. Now, I am considering creating an empty project and integrating the code from flash_kernel_ex5_can_flash_kernel. However, before proceeding, I need to fully understand how the output file is generated and why it might be failing.

    Any suggestions would be greatly appreciated.

    Thanks,
    Luciano.

  • +1 in reply to Luciano Vittori
    TI__Expert 6545 points

    Hi Luciano,

    Can you double-check the GPIOs being configured as CAN-TX and CAN-RX by the kernel running in RAM? Are you using INTOSC2 (can set this in device.h)?

    Kind regards,

    Skyler

  • 0 in reply to Skyler Baumer
    Prodigy 100 points

    Hi Skyler,

    I changed the INTOSC2, and now the bitrate is as expected. Thank you for that!

    // #define USE_PLL_SRC_XTAL
#define USE_PLL_SRC_INTOSC

    I believe the GPIO pins are correctly configured because I soldered two wires to the CANTX and CANRX test points on the LaunchPad near switch S4, which correspond to GPIO4 and GPIO5, and I am having communication when the microcontroller is running from a debug session.

    Since I don't see an ACK from the microcontroller side when the microcontroller is reset and the selected boot pins are in a CAN configuration, the default pins might be changed.

    After that, I solved the writing issue. It was a padding error in my Python script when the row was not a multiple of eight. Now I can program the application with the DCAN flash kernel loaded into RAM using CCS.

    Could the Boot ROM code be using different CAN pins than GPIO4 and GPIO5? I don't change this intentionally, but I think it may be the only way to not receive an ACK if CAN messages are arriving at 100K. How can I read/change the OTP values?

    Regards,
    Luciano.

  • +1 in reply to Luciano Vittori
    TI__Genius 14210 points

    Hi Luciano,

    Luciano Vittori said:
    Set the boot mode to CAN: S3 with GPIO72 high and GPIO84 low.

    Your suspicions are correct. Since you're using the default boot mode table, CAN boot option 0 will be used with GPIO59/GPIO58 for Tx/Rx. You'll need to configure BOOTDEF 0x22 in emulation boot or program the OTP to use the correct GPIO assignments for the on-board CAN transceiver.

    Best,

    Matt

  • 0 in reply to Matt Kukucka
    Prodigy 100 points

    Hi Matt, wow, that makes sense. Sorry for my mistake. I guess I got confused with other documentation.

    Thank you all for the support.

    Kind regards,
    Luciano.