• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 82 subscribers
  • Views 369 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.

TMS320F280039C: Flash programming via SCI on custom boards

Conor
Guru 10680 points
Part Number: TMS320F280039C

Hi, 

Using a custom board, the application program is written from GPIO8 and GPIO9 via SCI. I was able to expand the kernel software to RAM, but it stopped in the following state while transferring the application code.


I tried 19200bps and 9600bps baud rate, but it stops at the same point. At that time, on the CCS screen, a part of the CLA interrupt processing breaks and stops.

The kernel may be misconfigured because it hangs when transferring the application program.

By the way, I succeeded in transferring the txt file of the same kernel and application code using the evaluation board. Our application code uses CLA. The linker command file is also attached just in case. The CLA program is expanded to RAM in the linker command file. Will this have any impact?

F280039_flash_lnk .txt
Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
/*
//###########################################################################
//
// FILE: F280039_flash_lnk.cmd
//
// TITLE: Linker Command File For F280039 Device
//
//###########################################################################
*/
MEMORY
{
BOOT_RSVD : origin = 0x00000002, length = 0x00000126
RAMM0 : origin = 0x00000128, length = 0x000002D8
RAMM1 : origin = 0x00000400, length = 0x000003F8 /* on-chip RAM block M1 */
// RAMM1_RSVD : origin = 0x000007F8, length = 0x00000008 /* Reserve and do not use for code as per the errata advisory "Memory: Prefetching Beyond Valid Memory" */
// RAMLS0 : origin = 0x00008000, length = 0x00000800
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

We will change the extension of the linker command file to txt and send it to you.

Can you give me some advice?

Thanks,

Eevee

  • 0
    TI__Genius 11525 points

    Hi Eevee,

    Thanks for your question. Will get back to you within the next day.

    Thanks and regards,

    Charles

  • 0 in reply to Charles Roberson
    Guru 10680 points

    Hi, Charles

    I would greatly appreciate it if you could reply as soon as possible.

    Thanks,

    Eevee

  • 0 in reply to Conor
    TI__Genius 11525 points

    Hi Eevee,

    When you say "transferring the txt file of the same kernel and application code using the evaluation board", you mean by using the command prompt correct?

    So you are able to get past the download of the kernel, but when performing the DFU CPU1 command got the image it gets stuck?

    Also, have you tried to send the file to the device with CCS closed?

    Thanks,

    Charles

  • 0 in reply to Charles Roberson
    Guru 10680 points

    Hi, Charles

    Charles Roberson said:
    When you say "transferring the txt file of the same kernel and application code using the evaluation board", you mean by using the command prompt correct?

    With no differences other than the evaluation board and the custom board (the kernel and application code are the same), I wrote via the command prompt. As a result, this phenomenon did not occur on the evaluation board, but only on the custom board.

    Charles Roberson said:
    So you are able to get past the download of the kernel, but when performing the DFU CPU1 command got the image it gets stuck?

    Since it stops before the DFU CPU1 command selection screen is displayed, it seems that the DFU CPU1 command has not been executed. My guess is that the baud rate is adjusted before the DFU CPU1 command, and the program stops here. Please let me know if you find out what the cause is.

    The CLA program is expanded into RAM in the linker script file, does this have any effect?

    Charles Roberson said:
    have you tried to send the file to the device with CCS closed?

    Even if CCS is closed, the communication will stop in the middle and the same phenomenon will occur.

    Thanks,

    Eevee

  • 0 in reply to Conor
    TI__Genius 11525 points

    Hi Eevee,

    Have you tried to expand the CLA code to flash memory? This could be affecting it. Also, have you tried to reset the custom board before sending the kernel and application file?

    Will run some tests on the host programmer and get back to you on what I find. 

    Thanks,

    Charles

  • 0 in reply to Charles Roberson
    Guru 10680 points

    Hi, Charles

    　>Have you tried to expand the CLA code to flash memory?This could be affecting it.
    What does "expand the CLA code to flash memory" mean? I believe the CLA's code can only run in RAM because the CLA and Flash are not bused together. How exactly should I verify?

    　>Also, have you tried to reset the custom board before sending the kernel and application file?
    Even if transfer is performed after resetting, the same result is obtained. The screen freezes before the DFU CPU1 command selection screen appears. The internal clock of the microcomputer is used, and it has been confirmed that the data can be transferred normally on the evaluation board.

    We are waiting for your verification results.

    Thanks,

    Eevee

  • 0 in reply to Conor
    TI__Genius 11525 points

    Hi Eevee,

    I have noticed nothing irregular with the way the F28003 downloads the kernel file (stepping through the source with the device connected). Are you able to view the TX/RX buffers for the custom device when the transfer is occuring? If you would like to have a call over this that can be arranged. Have sent you a chat message as well.

    Thanks,

    Charles