TMS320F28377S: RAM application uploaded via serial interface (SCI)

Nicola Mazzacane

Part Number: TMS320F28377S
Other Parts Discussed in Thread: TMS320F28335, C2000WARE

We have an application that has been built to be executed in RAM for TMS320F28377S. Setting the boot mode GPIOs properly, we want to upload the application via serial interface and then immediately execute it, for example using the Texas Instruments C2000 Serial Flash Programmer application running on Windows 7.

We have met the following issues:

The upload process is very slow: we have tried to change the ‘-b’ option, but the application does not start
The last sent character the application always returns an error (for example, 00=0F)

I have the following questions:

In order to fix the former issues, Texas Instruments C2000 Serial Flash Programmer application should be recompiled?
Does another programming toll exist?
With a TMS320F28335, we have experienced the direct upload sending the firmware file using a terminal application: it is possible to do the same thing with TMS320F28377S?

over 7 years ago

0 Nicola Mazzacane over 7 years ago

Intellectual 380 points

>>>> UPDATE

Setting the TMS320F28377S in SCI Boot Mode, we have been able to upload a Blinky application (built to be executed in RAM) with a terminal application: we have seen the echo of all sent characters and at the end of transmission the application has started correctly.

But when we have switched to our nominal application (built to run in RAM and which takes up almost all the available RAM) the SCI Boot Mode fails. In this case the upload starts in the same way, but at about 70% of its transmission the character echo is lost and at the end of the upload the application does not start.
• Is there any limitation in the size of the application built to run in RAM that can be downloaded and executed using SCI Boot Mode?
• Is there any limitation on how the memory areas of the application must be organized?
• Is it true that if an application works correctly when downloaded via JTAG, then it can always be downloaded and executed using SCI Boot Mode?

Regards,
Nicola

0 Sal Pezzino over 7 years ago in reply to Nicola Mazzacane

TI__Mastermind 32995 points

Hi Nicola,

The SCI boot loader running from ROM echoes back every character. This, in combination with with Windows OS is the reason for the slow transfer.

I am not sure why you are experiencing an incorrect last byte.

If you were able to load code to RAM on the F2833x device running the SCI bootloader, the same procedure should work on F2837x. The SCI boot loader and protocol has not changed.

Hope this helps.
sal

0 Sal Pezzino over 7 years ago in reply to Nicola Mazzacane

TI__Mastermind 32995 points

Hi Nicola,

The only limitation should be not to load code to the stack which resides in RAMM0 block of memory. I cannot think of any other limitations.

Make you are not loading code to the reserved section of RAMM0 which is reserved for the boot ROM.

sal

0 Nicola Mazzacane over 7 years ago in reply to Sal Pezzino

Intellectual 380 points

Hi Sal,

as you suggested, we have reserved the RAMM0 for the boot ROM, but we have the same problem: at about 70% of firmware transmission the character echo is lost and at the end of the upload the application does not start.

Does any other contraint exist?

Here our linker file contents:

MEMORY
{
PAGE 0 :
   /* BEGIN is used for the "boot to SARAM" bootloader mode   */

   BEGIN           : origin = 0x000000, length = 0x000002
   FPUTABLES        : origin = 0x3FEBDC, length = 0x0006A0
   RESET           : origin = 0x3FFFC0, length = 0x000002
/*
   RAMGS0           : origin = 0x00C000, length = 0x001000
   RAMGS1           : origin = 0x00D000, length = 0x001000
   RAMGS2           : origin = 0x00E000, length = 0x001000
   RAMGS3           : origin = 0x00F000, length = 0x001000
   RAMGS4           : origin = 0x010000, length = 0x001000
   RAMGS5           : origin = 0x011000, length = 0x001000
   RAMGS6           : origin = 0x012000, length = 0x001000
   RAMGS7           : origin = 0x013000, length = 0x001000
   RAMGS8           : origin = 0x014000, length = 0x001000
   RAMGS9           : origin = 0x015000, length = 0x001000
   RAMGS10          : origin = 0x016000, length = 0x001000
   RAMGS11          : origin = 0x017000, length = 0x001000
   RAMGS12          : origin = 0x018000, length = 0x001000
   RAMGS13          : origin = 0x019000, length = 0x001000
   RAMGS14          : origin = 0x01A000, length = 0x001000
   RAMGS15          : origin = 0x01B000, length = 0x001000
*/
   RAMGS            : origin = 0x00C000, length = 0x010000

PAGE 1 :

   BOOT_RSVD        : origin = 0x000002, length = 0x000120     /* Part of M0, BOOT rom will use this for stack */

/*
   RAMM0            : origin = 0x000122, length = 0x0002DE
   RAMM1            : origin = 0x000400, length = 0x000400
   RAMD0            : origin = 0x00B000, length = 0x000800
   RAMD1            : origin = 0x00B800, length = 0x000800
*/
   //RAMECCM            : origin = 0x000400, length = 0x000400
   RAMECCD              : origin = 0x00B000, length = 0x001000

/*
   RAMLS0          : origin = 0x008000, length = 0x000800
   RAMLS1          : origin = 0x008800, length = 0x000800
   RAMLS2                 : origin = 0x009000, length = 0x000800
   RAMLS3                 : origin = 0x009800, length = 0x000800
   RAMLS4                 : origin = 0x00A000, length = 0x000800
   RAMLS5                 : origin = 0x00A800, length = 0x000800
*/
   RAMLS          : origin = 0x008000, length = 0x003000

   CANA_MSG_RAM     : origin = 0x049000, length = 0x000800
   CANB_MSG_RAM     : origin = 0x04B000, length = 0x000800
}


SECTIONS
{
   codestart        : > BEGIN,     PAGE = 0
   ramfuncs         : > RAMLS,     PAGE = 1
   .text            : > RAMGS,     PAGE = 0
   .cinit           : crc_table(_link_gen_crc_table) > RAMGS,     PAGE = 0
   .pinit           : > RAMGS,     PAGE = 0
   .switch          : > RAMGS,     PAGE = 0
   .reset           : > RESET,     PAGE = 0, TYPE = DSECT /* not used, */

   .stack           : > RAMECCD,   PAGE = 1
   .ebss            : > RAMLS,     PAGE = 1
   .econst          : crc_table(_link_gen_crc_table) > RAMGS,     PAGE = 0

   FPUmathTables    : > FPUTABLES, PAGE = 0, TYPE = NOLOAD

   /* Section required by linker to put the automatically computed CRC table */
   .TI.crctab       : > RAMLS, PAGE = 1

   /* Section to redirect safety variable in ECC protected RAM */
   eccSection             : >  RAMECCD, PAGE = 1
}

/*
//===========================================================================
// End of file.
//===========================================================================
*/

Regards,

Nicola

0 Sal Pezzino over 7 years ago in reply to Nicola Mazzacane

TI__Mastermind 32995 points

I cannot think of any other constraints.

What baud rate are you using? If it is too high, then the device may be lossing characters, since after POR it is only running at 10MHz.

Can you determine which block of memory is being transfered when it fails? You can load the symbols of the boot ROM and debug it this way.

Regards,
sal

0 Nicola Mazzacane over 7 years ago in reply to Sal Pezzino

Intellectual 380 points

Hi Sal,

- we have set a transfer rate of 9600 with the terminal application but the same problem: at about 70% of firmware transmission the character echo is lost and at the end of the upload the application does not start
- where can I find the symbols of the boot ROM?

By the way, using the nominal TI Flash Programmer, we have been able to upload with success the entire our firmware, but the application does not start (when it starts, serial messages are periodically transmitted across the same serial line used for the firmware upload).
We have tried to connect the target with CCS 6.1.0.00104, but it seems that this action resets the RAM (we see all memory 0000). How can we connect the target without resetting RAM and debug the running RAM application?

Regards,
Nicola

0 Sal Pezzino over 7 years ago in reply to Nicola Mazzacane

TI__Mastermind 32995 points

1) To connect without resetting, you will need to modify the GEL file for the target configuration file you are using.

2) You can find the boot ROM symbols in the path below.

C:\ti\c2000\C2000Ware_1_00_05_00\libraries\boot_rom\f2837xd\revB\rom_sources\ccs_files\cpu01\Release

Hope this helps.
sal

0 Nicola Mazzacane over 7 years ago in reply to Sal Pezzino

Intellectual 380 points

Hi Sal,

as you suggested, we have modified the gel file F28377D_CPU1.gel as reported, but the effect is the same: on connection, all RAM is 0000.

OnTargetConnect()
{

    *(int *)0x5F412 =0x000F;      /* RAM INIT FOR M0/M1/D0/D1 Memory  */
    *(int *)0x5F432 =0x003F;      /* RAM INIT FOR LS0..LS5  Memory    */
    *(int *)0x5F452 =0xFFFF;      /* RAM INIT FOR GS0..GS15 Memory    */

    if (GEL_IsInRealtimeMode())     /* If in real-time-mode */
    {
    }
    else                            /* Put device into C28x Mode */
    {
        C28x_Mode();   
    }

    F2837x_Memory_Map();        /* Initialize the CCS memory map */

/* Check to see if CCS has been started-up with the DSP already */
/* running in real-time mode.  The user can add whatever        */
/* custom initialization stuff they want to each case.          */

    if (GEL_IsInRealtimeMode())     /* Do real-time mode target initialization */
    {

    }
    else                            /* Do stop-mode target initialization */
    {
       /* GEL_Reset(); */              /* Reset DSP */
    }
}

We have also disabled all reset options in Target Configuration Properties panel as shown in the picture.

How can we achieve our goal?

Thank you,

Nicola

0 Sal Pezzino over 7 years ago in reply to Nicola Mazzacane

TI__Mastermind 32995 points

Please look at the first 3 lines of code that you posted. OnTargetConnect(). The first 3 lines of code perform a RAM initialization. If you do not want that, you can comment that out or delete it.

Thank you,
sal

0 Nicola Mazzacane over 7 years ago in reply to Sal Pezzino

Intellectual 380 points

Hi Sal,

we have been able to read memory modifying the gel file as you suggested.
We have discovered that:
• Sending the blinky firmware with the terminal application, the memory image is the same of what we have with a JTAG programming and the application works
• Sending our nominal firmware with the terminal application the application does not start. Connecting to the target (and using the same gel file…), the memory image is the same of what we have with a JTAG programming only at the first 70% (NOTE: the same the same percentage of interruption of the echo).
• Sending our nominal firmware with the Texas Instruments C2000 Serial Flash Programmer application, the upload is completed with success, but the application does not start. Connecting to the target (and using the same gel file…), the memory is completely filled with 0000: it seems that the DSP has been reset: is it possible that the boot ROM performs this reset in any circumstances?

We have tried to debug the boot ROM using the symbols using the path that you have suggested, but the load has failed with a message “Can't find a source file at "C:/work/grepos/bootrom/Boot_ROM/F2837x_bootROM-REVB/F2837x_bootROM_dev/F2837x_bootROM/cpu01-bootROM/source/c1brom_Init_Boot.asm" Locate the file or edit the source lookup path to include its location”

Best regards,
Nicola

0 Sal Pezzino over 7 years ago in reply to Nicola Mazzacane

TI__Mastermind 32995 points

Hi Nicola,

After loading the symbols, click on Locate File and point it to the /source directory. This will help you debug.

C:\ti\c2000\C2000Ware_1_00_05_00\libraries\boot_rom\f2837xd\revB\rom_sources\F2837x_bootROM\cpu01-bootROM\source

The only way for the device to reset after starting the SCI boot loader is for it to 1) get an incorrect header information (0x08AA), which causes it to branch to the flash entry point, and if it branches there with nothing programmed then the device would get an illegal instruction ISR and reset, or 2) perhaps it could get some incorrect block information and prematurely complete the transfer.

I have not witnessed something like this before, so it is hard to say what exactly is causing it. But you should be able to debug it and find the issue fairly quickly using the boot ROM symbols and point CCS to the source directory to debug and set breakpoints and single step, etc.

Regards,
sal

0 Nicola Mazzacane over 7 years ago in reply to Sal Pezzino

Intellectual 380 points

Hi Sal,

we have made progress.

Now we can verify that all our nominal firmware is downloaded correctly in RAM (we have verified comparing it with the image of the same application downloaded via JTAG) and, putting a breakpoint in the main, we can execute it step by step.

However, when we play, it seems that the DSP is actually reset (that's why we saw the 0000 memory) and the execution is back in the boot ROM, but still in an infinite loop of the WaitBoot() procedure of the c1brom_boot.c file.

What may have reset the DSP, since the application, if loaded via JTAG, always works correctly?

Thank you,
Nicola

0 Sal Pezzino over 7 years ago in reply to Nicola Mazzacane

TI__Mastermind 32995 points

It is hard to tell what would cause the reset. You should be able to step through the application after loading to see. You can set a breakpoint at the entry address to begin to debug this after it is loaded successfully.

Are you sure your entire application is linked to RAM? And there is nothing going to flash?

Regards,
sal

0 Nicola Mazzacane over 7 years ago in reply to Sal Pezzino

Intellectual 380 points

Hi Sal,

as you can see from the linker file, nothing goes in flash.

We have probably identified the problem. To achieve this, we have removed any doubt changing our application: after having disabled the watchdog by code, we perform an infinite loop as soon as the application enter in the main. In such a way, no other piece of code of our application is executed, but the result was the same: the application starts, performs a number of iterations (thousands), but at the end we jump in the boot ROM.

We have then discovered that actually the Watchdog is newer disabled when the application is uploaded via serial with the boot ROM because the hex file of our application, it does not start at address 00000000, but at address 00016837. Here the beginning of our hex file.

[1]
AA 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 37 68 02 00 
00 00 00 00 41 00 EF 6C 
04 00 00 00 E0 9C 01 19 C3 56 FF FF 06 00

Looking inside our map file, we find the object linked to this address, that is the linked rts2800_fpu32.lib

00016837 00000046 rts2800_fpu32.lib : boot.obj (.text)

Proving that the problem is this, if we modify the jump address with the debug after the program uploading in RAM (for example, by putting 00000000 the returned variable EntryAddr = GetLongData ()), our application starts correctly.

Now:

what is wrong in our building process? How can we make to start our application at 00000000?
why the disabling of watchdog via code seems to have no effects? In fact, this operation in boor ROM code is performed via a dedicated assembler function wd_disable?

wd_disable:
    SETC OBJMODE        ;Set OBJMODE for 28x object code
    EALLOW              ;Enable EALLOW protected register access
    MOVZ DP, #7029h>>6  ;Set data page for WDCR register
    MOV @7029h, #0068h  ;Set WDDIS bit in WDCR to disable WD
    EDIS                ;Disable EALLOW protected register access
    LB _c_int00         ;Branch to start of boot._asm in RTS library

    .endif

Best regards,

Nicola

0 Sal Pezzino over 7 years ago in reply to Nicola Mazzacane

TI__Mastermind 32995 points

Hi Nicola,

You should make sure to include codeStartBranch.asm file in your application and place the codestart memory section at 0x00000, or the BEGIN memory region.

This should change the entry point of the hex file to 0x00000. If it doesn't, you can change it in the CCS project properties.

Hope this helps.
sal

0 Nicola Mazzacane over 7 years ago in reply to Sal Pezzino

Intellectual 380 points

Hi Sal,

we have fixed the problem.
We have discovered that CCS for new projects does not set in Build->C2000 Linker->Advanced Options -> Symbol Management the specification of --entry_point, -e to 'code_start' even if the symbol is declared in the linker file and all code is available.

I think that this is a bit misleading since that this kind of behaviour is not obvious or intuitive (you have in your code a legacy procedure called code_start, but this is not actually the application entry point due to an IDE option ...)

By the way, how can we would be able to avoid this kind of error? What whe should have read and where?

Best regards,
Nicola

0 Sal Pezzino over 7 years ago in reply to Nicola Mazzacane

TI__Mastermind 32995 points

Nicola,

Glad you got it working. The command line option/flag should work. It should be passing that option to the Code Generation Tools.

If there is an issue there, you may be able to find the reason in the Code Generation Tools forum.

Thanks,
sal

C2000™︎ microcontrollers

C2000 microcontrollers forum

TMS320F28377S: RAM application uploaded via serial interface (SCI)