• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 3 answers
  • Subscribers 82 subscribers
  • Views 1636 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TMS320F280049: Serial Flash programming issues

Bharath Balakrishnan
Prodigy 85 points
Part Number: TMS320F280049
Other Parts Discussed in Thread: C2000WARE

I am using a serial flash programmer to program (using UART)  a TMS320F280049 controller on a custom PCB board. But there seems to be an error while loading the kernel.There seems to be an error called "error

with autobaud lock echoback".

The error screenshot is attached here.

I set the microcontroller in the SCI bootload mode.

  •  GPIO 32- set as high using a 10Kohm resistor to 3.3V. 
  • GPIO 24- set as low by grounding.
       A  USB-to-UART TTL converter (Silabs CP2102) is used.
  •  GPIO 16 (SCIA_TX) connected to RX pin of the converter. The line is pulled up to 3.3V using a 10Kohm resistor.
  •  GPIO 17(SCIA_RX) connected to TX of the converter. The line is pulled up to 3.3V  using a 10Kohm resistor
I have used the serial flash programmer provided in C2000ware to flash the kernel "flashapi_ex2_sci_kernel" to the device. The program to be loaded is the example program provided as "led_ex1_blinky".
The command used in the command prompt is:
serial_flash_programmer.exe -d f28004x -k flashapi_ex2_sci_kernel.txt -a led_ex1_blinky.txt  -b 2400 -p COM5 -v -w
The error produced is shown in the attachment.
 I would really appreciate if you could help resolve the issue and flashing the controller.
  • 0
    TI__Mastermind 32995 points
    Hi Bharath,

    Since it seems like the autobaud lock is not working, I suggest opening a COM port and performing the autobaud lock manually. By this I mean, set the device to SCI boot mode and send an 'A' or 'a' manually by typing it into an open COM port terminal. See if this works first. If you can get this to work, then the serial flash programmer should be able to work.

    Also, make sure the GPIO pins you are using for SCI communication are the correct pins for the boot mode you have selected.

    Hope this helps.

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

    Hey Sal,

    Thanks for the prompt reply. I tried the technique suggested by you. When I send a character "A" or "a", the microcontroller seems to be responding with "ff". Is there a specific setting required to enter autobaud?.

    I tried it using

    - Baud rate = 9600 (tried 2400 as well. Received the same erroneous output.)

    -Parity = none

    - Stop bit = 1

    Please let me know if the connections I have mentioned in the first post is correct or not.

  • 0 in reply to Bharath Balakrishnan
    TI__Mastermind 32995 points
    Sending an 'A' or 'a' will allow the device to perform an autobaud lock. Which means it should determine which baud rate is being used and lock to that baud rate.

    9600 is a good baud rate to use. You should be seeing an 'A' or 'a' sent back.

    It appears your connections may not be set up properly if you are not getting the 'A' back. Please ensure you have the SCI Rx and Tx pins used by the boot loader properly connected to your PC.

    Regards,
    sal
  • 0 in reply to Sal Pezzino
    Prodigy 85 points
    The connections done are:
    - GPIO 32- set as high using a 10Kohm resistor to 3.3V.
    - GPIO 24- set as low by grounding.
    A USB-to-UART TTL converter (Silabs CP2102) is used.
    - GPIO 16 (SCIA_TX) connected to RX pin of the converter. The line is pulled up to 3.3V using a 4.7Kohm resistor.
    - GPIO 17(SCIA_RX) connected to TX of the converter. The line is pulled up to 3.3V using a 4.7Kohm resistor.
    Is it correct?
  • 0 in reply to Bharath Balakrishnan
    TI__Mastermind 32995 points

    Hi,

    You should not be pulling up the Tx and Rx pins. This is likely why you are seeing 0xFF and not 'A'.

    sal

  • 0 in reply to Sal Pezzino
    Prodigy 85 points

    Hi Sal,

    I removed the pull-ups on Tx and Rx, tested it. Now the kernel file loading gets stuck at this point. Shown in the screenshot.

  • 0 in reply to Bharath Balakrishnan
    TI__Mastermind 32995 points
    You can begin to debugg the problem by using emulation mode to boot to SCI with the emulator connected. You can see if the device is receiving the proper characters, by connecting to the device and loading the boot ROM symbols and using emulation boot to boot the device to the SCI boot loader.

    Regards,
    sal