• State TI Thinks Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 2 answers
  • Subscribers 84 subscribers
  • Views 2056 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:

F28377S LaunchPad Serial(SCI) Programing

TMS320F28377S: F28377S LaunchPad Serial(SCI) Programing

Lukas Fiel
Prodigy 50 points
Part Number: TMS320F28377S

Hi guys.

I'm new to TI dev boards. Currently I am trying to flash a F28377S dev board using SCI.

Tried to follow this example implementation .

Short:

  1. imported blinky example into workspace + built it + processed  *.out file to *.txt using "hex2000.exe -boot -pdb -sci8 -a -o OUTfile.txt INfile.out"
  2. imported flash_programming into workspace+ built it + processed  *.out file to *.txt using "hex2000.exe -boot -pdb -sci8 -a -o OUTfile.txt INfile.out"
    1. as these are examples I suggested everything to be straight forward.
  3. prepared the board to boot to SCI (dipswitches)
  4. started the SCI flash using "serial_flash_programmer.exe -d f2837xS -k flash_programming.txt -a blinky.txt  -p COM4 -b 9600 -v

Sadly there seems to be something wrong. As you can see the Kernal seems to be loaded but does not autobaud any more.

Maybe there is someone out there with a good idea how to solve this.

Is there something to change in a .cmd or header file? Do I have to change some build options?

Thanks a lot.

Lukas

  • 0
    TI__Mastermind 32995 points
    The flash_programming example is not the kernel. You need to use the sci_flash_kernel. This is why it is not achieving the second autobaud lock.

    Regards,
    sal
  • 0 in reply to Sal Pezzino
    Prodigy 50 points

    Hi.

    Thank you for your quick reply. I just tried it yesterday and it worked like expected. Now the flash kernel is showing its options. Great! 

    But at this point I am stuck on the next step:

    Selecting DFU results in showing "calling f021_SendPacket" but doing nothing. Am I missing something?

    There is another question driving me crazy:

    Why does uploading code take only some seconds using CodeComposerStudio, but flashing the Kernel takes up to 4 minutes? In a scenario where we need to upgrade the code of 3 Chips this would take 12 minutes. As this time measurement only covers the kernel, I have to assume that upgradinig the code on the flash wil take some additional time. Mesasurements were taken with 38400 baud rate. Is this the maximum?

    Example command:

    serial_flash_programmer.exe -d f2837xS -k F2837xS_sci_flash_kernel_cpu01.txt -a example.txt  -p COM4 -b 38400

    Thanks a lot for the quick help.

  • 0 in reply to Lukas Fiel
    Prodigy 210 points

    Hi Lukas,

    I am currently also trying to configure F28377S LaunchPad and seem to be having very similar issues as you are,

    this is my thread:

    https://e2e.ti.com/support/microcontrollers/c2000/f/171/t/701073

    i would suggest you to try the following:

    1. add -v (verbose) to enable additional detail printing to your serial_flash_programmer.exe  command, like this

    serial_flash_programmer.exe -d f2837xS -k F2837xS_sci_flash_kernel_cpu01.txt -a example.txt  -p COM4 -b 38400 -v

    2. Open sci_flash_kernel project in CCS and change the argument to "SCI_GetFunction" call from "SCI_BOOT_ALTERNATE" to "SCI_BOOT",

    This changes the GPIO's that are used by the flash kernel to yours (our) specific model.

    Regards,

    Peter

  • 0 in reply to Lukas Fiel
    TI__Mastermind 32995 points
    Loading the flash application takes less time than loading the kernel because the communication has been optimized to use checksums instead of echo-back. However, it will take some additional time.

    Also, to optimize the loading, you can cut down the kernel. It has a lot of additional functionality in it. For example, unlock DCSM, verify, erase. You can remove the code that isn't needed and this will shrink the flash kernel image and thus shrink the data being communicated.

    You may be able to use a higher baud rate as long as you have not done a power on reset and the SYSCLK is at a higher frequency. You may be able to achieve 115200 if you are running at 200MHz.

    Regards,
    sal
  • 0 in reply to Sal Pezzino
    Prodigy 50 points

    Hi.

    So I was testing yesterday. Tied to get it working, but I am stuck at uploading my application. I tried evers kernel command and made a littele table with the corresponding error messages. As I successfully run 7-Reset and 8-Done i thing the kernel is working great. Running 1-DFU I am gettingfollowing message:

    "calling f021_SendPacket

    Finished sending Packet... Received ACK to Packet... Downloading C:\Users\Lukas\Documents\work\C2000Flash\SerialComm\CPU1_FLASH\SerialComm.txt to device...

    Checksum does not match... Please press Ctrl-C to abort."

    2-Erase or 3-Verify as well show outputs with some Checksum Error. Sadly I am stuck at this point. Please help.

    As mentioned by Sal, I am thinking about shortening kernel to gain speed in a later state of the project. But as I am just beginning I will stick to the default settings for now.

    : Hi. Nice meeting someone with similar state of success. Would be nice if you could post your experience if succeed. Thank you for the hint with the "-v" option. Sadly it did not help that much. BTW: my example was set to "SCI_BOOT" by default.

    Thank you all for the help :)

    Lukas

  • 0 in reply to Lukas Fiel
    TI__Mastermind 32995 points
    Hi Lukas,

    You can begin to debug by using the CCS project and the Visual Studio project. You can single step and set breakpoints with both of these projects in there respective IDEs. This should help you debug.

    Can try rebuilding the flash application, and then pointing the serial flash programmer to it? But make sure you don't open the .txt file in any way before calling the serial flash programmer. We have seen some people having issues with Windows operating system adding some characters at the beginning of the file if it gets opened in some editor or something.

    Try this.

    Regards,
    sal
  • 0 in reply to Sal Pezzino
    Prodigy 50 points

    Hi.

    We are achieving out goal step by step.

    I found a new version of http://www.ti.com/tool/C2000Ware and used the provided serial_flash_programmer. Lucky me, i was successfull. After kernel showed his options I was able to select DFU without any error. There were bytes scrolling over my screen, so I was very happy.

    Sadly there is another error at the end of these bytes:

    Searching for "BLANK_ERROR" in the Serial Flash Programming Doku I found nothing but a short table.

    I am very thankful for all your support as I am stepping from error to error and most of the time can not find any solution.

    Thanks a lot

    Lukas

  • 0 in reply to Lukas Fiel
    TI__Mastermind 32995 points
    Hi,

    Glad it is working much better.

    The BLANK_ERROR should only be sent when you using an ERASE command. I am not sure why this is being received if you are only doing a DFU.

    Have you tried doing a DFU and then a RUN to see if the flash application is working properly?

    Regards,
    sal
  • 0 in reply to Sal Pezzino
    Prodigy 50 points

    Hi Sal.

    Yes I have tried DFU and RUN the flash application. Sadly no success. So I tried to flash some code (blinky) to the board using CodeComposerStudio. As this code was linked and built for FLASH I assume it to even run after pressing the RESET button on board. Even this was not successfull as the LED does not blink any more after pressing RESET.

    I then did some debugging and luckily got my hand on another board. The steps mentioned above are working great on the other board. So I think there is a problem with my current board. Maybe a wrong startAdress?!

    So I think I did something very bad with my current board. Maybe changed the startAdress to some invalid state. But in my understanding, this is not permanent and will be changed if flashing another code using CodeComposerStudio.

    Tomorrow I maybe will have the chance to try the whole FLASH flashing process using another board. But I do not want to risk bricking another board without knowing what went wrong in the first place.

    Any suggestions?

    Is there a way to just reset the board to a initial state (factory reset) ?

    Thanks

    Lukas

  • 0 in reply to Lukas Fiel
    TI__Mastermind 32995 points
    There is no way to reset the board to an initial state. As long as you have not programmed OTP (one time programmable) memory, then the device itself should be in good shape.

    Make sure you have not programmed OTP and the image you are flashing is not programming OTP.

    Regards,
    sal