• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 1435 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.

TMS570LS3137: CAN Bootloader Implementation Issue

Oguzhan Guner
Prodigy 35 points
Part Number: TMS570LS3137
Other Parts Discussed in Thread: UNIFLASH

Hi everyone,

I've been trying to program my HDK over CAN Module for 2 two weeks but actually, I don't understand and know how to do this. I've seen an application note (spna187) about it and have found some example codes but that example was solved by using NICAN produced by National Instruments yet I only have PCAN-USB Module. Also, I couldn't succeed to implement the codes to my project for TMS570LS3137 HDK. Can I do the same thing with PCAN or does anyone have any example which is done by using PCAN? Could you tell me that what are tricks and important things about implementing the code to HDK side and creating a new project working between PCAN and HDK? 

Thank you,

Oguzhan.

  • 0
    TI__Guru 59540 points
    Hello Oguzhan,

    The application note has the code that can be placed on the device that will perform the bootloader function on the target side. It includes some example source using NICAN as you mentioned, but you should be able to use any third party tool to do the same. The important part is to undertand the packets and sequencing that needs to be followed to program the devices.

    The bootloader on the device supports a certain command+data protocol format that can be sent from any external tool connected to the same CAN bus. The trick would be to figure out how to do this with the PCAN tool. Since we do not have PCAN or any references to it, I cannot say what it would take for that tool to be used or even if it can be used. What it would take is some external SW running on a host machine that can support building the packets with the correct message IDs, programming commands, and data from the binary file to be programmed. I don't know if the PCAN tool has a Windows interface that can be accessed by a custom C++ program, pearl script, or some other tool on the host side or even perhaps a command line to do the same using similar PC programming or scripting tools.

    Out of curiosity, a boot loader is an absolute requirement for your application or are you looking for a production programming solution of some sort? Are you aware of the Uniflash tool for programming the Hercules devices outside of CCS?
  • 0 in reply to Chuck Davenport
    Prodigy 35 points
    Hello Chuck,

    I understood what you said and thank you to reply explanatorily. I think, I'll solve the PCAN side if I understand the HDK side. A boot loader is an absolute requirement for my application so I want to implement the source codes of Texas CAN Bootloader to my TMS570HDK but I haven't reached the knowledge of doing this app yet. I'm inexperienced about this topic and this is the first time I've been trying to code a bootloader so I don't know how to make it real and also which steps I have to follow to proceed step by step to reach the final. I've been reading the application note of TMS570 Bootloader (spna187) but I didn't understand all the steps there. It's a little bit complicated. What is the basic way to do the bootloader?

    Moreover, I'm aware of the Uniflash and it's installed on my pc.

    Best Regards,

    Oguzhan
  • 0 in reply to Oguzhan Guner
    TI__Guru 59540 points

    Hello Oguzhan,

    I apologize for the late response.

    The application note SPNA187 really is a fairly basic boot loader already. It has the boot code located at the beginning of flash occupying the first sector. At boot time, it checks for the conditions to update the flash and if the conditions are seen, then it executes the boot loader code.

    The boot loader code consists of two primary parts in the MCU. The first part is the low level flash programming API or drivers. This part has the function headers and such that you use to configure the flash for programming and that you use to initiate flash operations like bank or sector erase, program operation, blank checks, program verify, etc. These functions access the hidden registers in the flash wrapper module to perform these operations at the HW level. The second part of the boot loader is the management layer. This layer is used to control the flow of the program and data. This is the layer where the protocol decode lies that receives the commands to program, erase, verify, etc. If the command that is sent, is a program command, it will be followed by the binary code to be programmed and the manager will track that the full length of data is received and check in necessary CRCs, etc to validate the incoming date/binary. 

    On the PC side, you will need software that can send the commands and data to the MCU over whichever protocol you have chosen. For example, it will send the programming command which should have the command followed by the data or binary information. It is up to the system design to determine really how many bytes are sent and programmed at a time. This should be determined based on the ability of the PC to send the data and the MCU to receive and buffer the incoming data before programming.

    All of this is, generally, fairly straight forward. The complications come given you can't program the same bank from which you are executing. In some devices we have multiple banks so it is easy to execute from bank0 and program to bank1. However, on many of our Hercules devices we have only 1 bank so it becomes necessary to figure out how to program the bank in which the boot loader resides. This is accommodated by copying the code to RAM and executing the manager and Flash API from RAM.

    Another point of confusion/questions that we often get are with regard to the exceptions/interrupt vectors. Normally, these are located at the beginning of flash, but because of the separation of the boot loader and the application. The issue is the CPU expects the vectors to be located at the beginning of Flash which is good for boot loader operation but then there needs to be a second path for the application. To accommodate, the vectors at the beginning of flash need to branch to the beginning of the application which is located after the first sector (the boot loader resides in the first sector).

    Let me know if this overview helps. It is my hope that this high level overview will help making the application note make more since because it gives context to the things discussed in the application note.