RTOS/TMS320F28075: RAM content is lost after jump to _c_int00

Hi,

1. Can you give the exact steps you use when loading/running via JTAG.
2. How are you overwriting the reset vector?
3. Are you 100% sure your boot code is running on a power cycle (e.g. without JTAG)?
4. Why can't you put all of your boot code into MyStartup_resetFunction?
5. Can you confirm that MyStartup_resetFunction is configured properly? For example:
var Startup = xdc.useModule('xdc.runtime.Startup');
Startup.resetFxn = "&MyStartup_resetFunction";

There's not much code that runs between c_int00 and the call to your reset function. You can look at it in <bios_install_dir>\packages\ti\targets\rts2800\boot_cg.asm.

Todd

Thank you, Todd.
Your questions are very interesting. I'll make some tests and I'll reply in some days.

Thank you.

Regards,

Demis

Hi Todd,

ToddMullanix said:

Hi,

1. Can you give the exact steps you use when loading/running via JTAG.

I use Code Composer Studio 6.1.1 with XDS100v2 USB Debug Probe. I connect my PC to the target via JTAG, compile the project and press the icon with the green bug to download and debug my software (boot and firmware).
Upon doing this, I see that my boot is executed and after some initializations and checks the firmware is launched by jumping at _c_int00 address.

ToddMullanix said:

2. How are you overwriting the reset vector?

I've opened the window
Project -> Properties -> CCS Build -> C2000 Linker -> Advanced Options -> Symbol Management
then I've gone to the line
"Specify program entry point for the output module (--entry_point, -e)"
and I've written my label (_c_intBOOT) in the edit box.

In this way I find that code begins from _c_intBOOT line instead of _c_int00 line. But this happens only if I'm connected with debug probe. If I power off and on my target without reconnecting via JTAG I see that my boot code is not executed.

ToddMullanix said:

3. Are you 100% sure your boot code is running on a power cycle (e.g. without JTAG)?

I've made some tests and I've found you're right: if I'm not connected with JTAG my boot code isn't executed at all. This is the reason why I find boot RAM reset to 0.
Now the questions is: why my boot code is not executed only when I'm not connected with JTAG?

ToddMullanix said:

4. Why can't you put all of your boot code into MyStartup_resetFunction?

When I started this project I wasn't experienced with SYS/BIOS and I preferred to keep boot (without SYS/BIOS) and firmware (with SYS/BIOS) distinct.
Furthermore boot can erase firmware and update it with a more recent version stored in an external flash memory. So I found easier keeping boot and firmware completely distinct.

ToddMullanix said:

5. Can you confirm that MyStartup_resetFunction is configured properly? For example:
var Startup = xdc.useModule('xdc.runtime.Startup');
Startup.resetFxn = "&MyStartup_resetFunction";

Yes, I confirm. I've checked in my app.cfg file and I've seen those lines.

Thank you.

Regards,

Demis

Hi Demis,

Thanks for the answers. You can use the plugMeta function in ti.sysbios.family.c28.Hwi module to plug in boot code entry point. You'll plug in your function into intNum 0. I'll make up an example tomorrow and attach it. Basically I'll make a symbol in the sys/bios app's linker file that corresponds to the address of the boot function. Then use that symbol and call the plugMeta in the .cfg file.

Out of curiosity, how are you jumping to _c_int00 in you boot code?

Also, the reason you want the separate boot code makes total sense.

Todd

Hi Todd,

ToddMullanix said:

Hi Demis,

Thanks for the answers. You can use the plugMeta function in ti.sysbios.family.c28.Hwi module to plug in boot code entry point. You'll plug in your function into intNum 0. I'll make up an example tomorrow and attach it. Basically I'll make a symbol in the sys/bios app's linker file that corresponds to the address of the boot function. Then use that symbol and call the plugMeta in the .cfg file.

Thank you Todd, you're very kind. An example would be very useful to me.

ToddMullanix said:

Out of curiosity, how are you jumping to _c_int00 in you boot code?

In our projects we usually reserve a small amount of memory in firmware flash to store some informations about firmware: firmware entry point, revision, product code, ecc.These informations are always store at the SAME address. This way boot functions can load these informations for whatever firmware revision.

Firmware entry point usually is the address of main() function. Thus, after initialization, boot loads that address into a C function pointer and then jumps to firmware by calling main() function through that pointer.

In this project I've declared (but not defined!) the _c_int00 label as a function

extern void _c_int00(void);

then I've stored _c_int00 in the memory address reserved for firmware entry point. So boot can jump to _c_int00 instead of main() function.

I've found online the hint to declare _c_int00 as a void function to use it properly in C language, but I don't remember in which site...

Thanks.

Regards,

Demis

Hi Demis,

I did not quite finish the write-up, but here is the draft along with two examples. Let me know if this works for you. Once I'm done with it, I'll add it to processors.wiki.ti.com and update this thread to point to it.

Todd

6036.C2000BootAndSYSBIOS.pdf

2046.C28BootExamples.zip

Hi Todd,
thank you for document and examples.
I'll make some tests as soon as possible and I'll give you a feedback.

Regards,

Demis

Hi Demis,

I made a few changes and reposted them above. The changes were just to add the LED management and a typo or two.

Todd

Ok, thank you Todd.
Yesterday I've tried to follow your hints but I've stumbled into some issues.
First I've got only one project that includes both boot and firmware, but this doesn't seem a real problem to me.

Thanks to your document I've found that I haven't put the right code in codestart section. However I couldn't correct the problem because in codestart section there was also "ti_catalog_c2800_initF2837x_begin" code. I supposed this has been put there by the Boot module I've included in my app.cfg:

var Boot = xdc.useModule('ti.catalog.c2800.initF2837x.Boot');
Boot.OSCCLKSRCSEL = Boot.OscClk_XTAL;
Boot.OSCCLK = 16;
Boot.SPLLIMULT = 15;
Boot.SYSCLKDIVSEL = 1;
Boot.loadSegment = "FLASH_FW PAGE = 0";
Boot.runSegment = "RAM_FW_PRG PAGE = 0";
Boot.SPLLFMULT = Boot.Fract_0;

So, I've removed all the lines above but I've found another problem: "BIOS.cpuFreq (120000000 Hz) does not match the actual CPU frequency (2500000 Hz). Please program the Boot module's PLL settings to ensure the actual CPU frequency matches BIOS.cpuFreq."

In my boot code (outside SYS/BIOS) I program PLL to ensure that CPU frequency is 120000000 Hz but SYS/BIOS seems to need to have the Boot module included and CPU frequency programmed through Boot module.

I've looked at your firmware example and I've seen you haven't included Boot module. Today I try to compile your examples and to understand how to solve my problem.

Thank you.

Regards,

Demis

My solution does not work over a power-cycle, I need to replace the sysbios boot function also. It appears to be rather cumbersome. I'm doing the following in the .cfg.

Program.sectMap[".ti_catalog_c2800_initF2837x_begin"] = "BEGIN";

Then I supply Boot_asm.s28 code in a new project .asm file. I change the branch to jump to the new boot code instead of _c_int00.

I had to disable the watchdog in the code_start asm also.

Todd

Hi Todd,
maybe I've fixed my issue. I try to explain you my workaround so you can report me your considerations.

First, some preliminary informations.

I'm developing my project on TMS320F28075 so all addresses, sectors, etc. refer to that DSP.

I use only ONE project for BOOT and FIRWMARE.

I store BOOT code in sectors A and B (address: 0x8002-0x81FFF) and FIRMWARE code in sectors G, H, I and J (address 0x98000-0xB7FFF);

Now let's see the software architecture.

In BootF2807x_CodeStartBranch.asm file I've defined _code_start label and codestart section as it follows.

Suppose (for now...) that after a power cycle Program Counter is loaded with _code_start label, i.e. that the first instruction to be executed is the one placed at _code_start address.

;****************************************************************************
;* BootF2807x_CodeStartBranch.asm
;****************************************************************************

WD_DISABLE    .set    1        ;set to 1 to disable WD, else set to 0

    .ref _c_intBOOT
    .global _code_start

***********************************************************************
* Function: codestart section
*
* Description: Branch to code starting point
***********************************************************************

   .sect "codestart"

_code_start:
    .if WD_DISABLE == 1
        LB wd_disable       ;Branch to watchdog disable code
    .else
        LB _c_intBOOT       ;Branch to start of boot._asm in RTS library
    .endif

;end codestart section

***********************************************************************
* Function: wd_disable
*
* Description: Disables the watchdog timer
***********************************************************************
    .if WD_DISABLE == 1

    .text
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_intBOOT         ;Branch to start of boot._asm in RTS library

    .endif

;end wd_disable

    .end
    
;****************************************************************************
;* END BootF2807x_CodeStartBranch.asm
;****************************************************************************

You see that codestart section contains only one instruction:

LB wd_disable

which jumps to wd_disable routine that disables watchdog. wd_disable code is allocated somewhere in BOOT sectors (A or B).

wd_disable last instruction is

LB _c_intBOOT

which jumps to _c_intBOOT address.

This label is defined in Boot28.asm file:

;****************************************************************************
;* Boot28.asm
;****************************************************************************
CONST_COPY    .set 0

  .global  _c_intBOOT, _BootCinit, pinit
  .global  _exit
  .global  __stackBOOT
  .global  _Boot

****************************************************************************
* Declare the stack.  Size is determined by the linker option -stack.  The *
* default value is 1K words.                                               *
****************************************************************************
__stackBOOT:    .usect  ".stack",0

****************************************************************************
*  INITIALIZE RESET VECTOR TO POINT AT _c_int00                            *
****************************************************************************
    .sect .reset
  .long _c_intBOOT

    .text
****************************************************************************
* FUNCTION DEF : _c_intBOOT                                                *
*                                                                          *
****************************************************************************
_c_intBOOT:   .asmfunc

****************************************************************************
*  INITIALIZE STACK POINTER.                                               *
****************************************************************************
    MOV     SP,#__stackBOOT     ; set to beginning of stack space

****************************************************************************
* INITIALIZE STATUS BIT FIELDS *NOT* INITIALIZED AT RESET                  *
****************************************************************************
    SPM    0            ; set product shift to 0

****************************************************************************
* SET C28x MODES                                                           *
****************************************************************************
        C28OBJ                          ; select C28x object mode
        C28ADDR                         ; clear the addressing mode
        C28MAP                          ; set block M0 and M1 mode

        .if .TMS320C2800_FPU32
        SETFLG            RNDF32=1      ; Enable rounding in FPU32 mode.
        .endif

****************************************************************************
* DO SOME STUFF
****************************************************************************
- initializing .cinit in BOOT RAM section;
- doing some checks;
- etc.
****************************************************************************
* END SOME STUFF
****************************************************************************
                
****************************************************************************
*  CALL USER'S PROGRAM                                                     *
****************************************************************************
    LCR   _Boot            ; execute Boot() function
    LCR   _exit
    .endasmfunc

;****************************************************************************
;* END Boot28.asm
;****************************************************************************

You see that after "doing some stuff" the instruction

LCR    _Boot

jumps to Boot() function, that is the first function written in C language.

Boot() function is in Boot.c file

//****************************************************************************
//* Boot.c
//****************************************************************************

void Boot(void)
{
    /* pointer to the address that stores the address of the firs FIRMWARE function, i.e. _c_int00. */
    Uint32* pFirmwareEntryFunctionAddress;
    
    /* function pointer to jump to FIRMWARE */
    void (*pFirmwareEntryFunction)(void);


    /* DO SOME OTHER STUFF */
    - hardware peripheral initialization;
    - some checks;
    - verify if there's a new FIRMWARE version in external serial flash and eventually installing the new FIRMWARE
    - etc.
    /* END SOME OTHER STUFF */

    /* Now it's time to run FIRMWARE, that is to jump to _c_int00 function.
         ALL FIRMWARE versions put the address of _c_int00 at address 0xB7FE2
         in other words in FIRMWARE there's something like this:
        
        const Uint32 FirmwareEntryPointAddress = &_c_int00;
        
        and FirmwareEntryPointAddress is placed by linker at 0xB7FE2 address.

    */
    /* save 0xB7FE2 address */
    pFirmwareEntryFunctionAddress = 0xB7FE2;

    /* load the content of 0xB7FE2 address, i.e. load the address of _c_int00 function */
    pFirmwareEntryFunction = *pFirmwareEntryFunctionAddress;
    
    /* exectute _c_int00 function, i.e. JUMP TO FIRMWARE!!! */
    (*pFirmwareEntryFunction)();
    
}

//****************************************************************************
//* END Boot.c
//****************************************************************************

Now a short recap:
power cycle --[load in Program Counter 0x80000 address]--> _code_start --[jump to]--> wd_disable --[wd disable then jump to]--> _c_intBOOT --[some stuff then jump to]--> Boot() --[some stuff then jump to]-->_c_int00: FIRMWARE runs!!!!

So my goal is to allocate codestart section at address 0x80000 (first address of flash sector A), because, after a power cycle, bootloader loads 0x80000 address into Program Counter.

To do so, some days ago I've added the following lines in MyProject.cmd linker file

//****************************************************************************
//* MyProject.cmd
//****************************************************************************
MEMORY
{
...

    BEGIN   : origin = 0x080000, length = 0x000002

...
        
}

SECTIONS
{
...

   codestart                : > BEGIN                           PAGE = 0, ALIGN(4)

...
}
//****************************************************************************
//* END MyProject.cmd
//****************************************************************************

but the linking process failed because SYS/BIOS allocated its own section .ti_catalog_c2800_initF2837x_begin (which contained _ti_catalog_c2800_initF2837x_Boot_entry label) at the same address (0x80000) by default.

Therefore my issue was to allocate .ti_catalog_c2800_initF2837x_begin section at another address.

This morning I finally succeeded to move .ti_catalog_c2800_initF2837x_begin section to address 0xB0000 (in FIRMWARE sectors) adding these two lines to App.cfg file

//****************************************************************************
//* App.cfg
//****************************************************************************
...

Program.sectMap[".ti_catalog_c2800_initF2837x_begin"] = new Program.SectionSpec();
Program.sectMap[".ti_catalog_c2800_initF2837x_begin"].loadAddress = 0x000B0000;

...
//****************************************************************************
//* END App.cfg
//****************************************************************************

I've chosen 0xB0000 address because it is an address in FIRMWARE sectors, but I could choose any other address in that range.
In this way _ti_catalog_c2800_initF2837x_Boot_entry label remains unused because I run FIRMWARE by jumping directly to _c_int00 from Boot() function, as I've explained previously.

Now, if I do a power cycle (i.e. I switch my board off and on again) I see that BOOT is executed and THEN FIRMWARE is launched correctly.

Furthermore I've opened the CCS window
Project -> Properties -> CCS Build -> C2000 Linker -> Advanced Options -> Symbol Management
and I've written _code_start in the edit box
"Specify program entry point for the output module (--entry_point, -e)"
So BOOT is executed even if I connect to the target via JTAG.

I hope I have explained my workaround well.

Do you have any remarks about it? Do you think it's a correct way to do what I meant?

Thank you for your hints and for showing me the syntax "Program.sectMap"!

Regards,

Demis

Hi Demis,

I'm looking at this. I'll get back to you soon.

Todd

Hi Demis,

It basically looks fine. I have two comments.

1. Why 0xB7FE2 for _c_int00. It seems like a rather random location.
2. Are you plugging a different intNum 0 function? If a reset occurs, the default is to go to _c_int00 instead of code_start.

Todd

Hi Todd,

ToddMullanix said:

Hi Demis,

It basically looks fine. I have two comments.

1. Why 0xB7FE2 for _c_int00. It seems like a rather random location.

No, it isn't a random location but I understand that it may seem to you. :)

I try to explain.

28075 DSP has 14 flash sectors. I've reserved

- A-B sectors for BOOT;

- G, H, I, J sectors for FIRMWARE;

- K, L, M, N sectors for application data;

- C, D, E, F sectors for future expansions of BOOT or FIRMWARE.

In the bottom area of FIRMWARE I've allocated a table (FwTable) with some data shared with BOOT. All FIRMWARE versions allocate FwTable table at the same address, so BOOT can always reach such data.

FwTable is allocated in the bottom area of J sector (0xB0000-0xB8000), specifically at 0xB7FE0 address and it is 0x20-word long. The first datum is a 2-words datum while the second data is _c_int00 address, so it is allocated at 0xB7FE2 address.

ToddMullanix said:

2. Are you plugging a different intNum 0 function? If a reset occurs, the default is to go to _c_int00 instead of code_start.

No, I haven't plugged a different intNum 0 function, because I tought it wasn't necessary.

You mean that if a reset occurs without a power cycle, code executions starts from _c_int00, right?

So I should add the following lines to my app.cfg file:

Hwi.nonDispatchedInterrupts[0] = new Hwi.NonDispatchedInterrupt();
Hwi.nonDispatchedInterrupts[0].fxn = "_code_start";
Hwi.nonDispatchedInterrupts[0].enableInt = false;
Hwi.nonDispatchedInterrupts[0].intNum = 0;

Is it correct?

Thank you very much, Todd.

Regards,

Demis

Hi Todd,
thank you.

I'll fix my code and make some tests next week probably.

Best regards,

Demis

Hi Todd,

I've made some tests but the results aren't those I (or maybe we...) expected.

1) RESET TESTS

I have NOT added the following lines to my app.cfg file:

Hwi.nonDispatchedInterrupts[0] = new Hwi.NonDispatchedInterrupt();
Hwi.nonDispatchedInterrupts[0].fxn = "_code_start";
Hwi.nonDispatchedInterrupts[0].enableInt = false;
Hwi.nonDispatchedInterrupts[0].intNum = 0;

because I wanted to check what happened if the DSP resets.

I've found the following results:

A) RESET CAUSE: WATCHDOG EXPIRES

If watchdog expires in BOOT (without SYS/BIOS) DSP resets and code execution restarts from _code_start, i.e. from BOOT (correct!).

This happens whether CCS is connected to the target via JTAG or CCS is not connected.

If watchdog expires in FIRMWARE (with SYS/BIOS) DSP resets and code execution restarts from _code_start, i.e. from BOOT (correct!) only if CCS is NOT connected to the target.

On the contrary if CCS is connected to the target and watchdog expires in FIRMWARE the code execution stops definitely and the program doesn't run again until I reset DSP through CCS or switch off and on power supply.

It seems like code execution jumps to a location not programmed, or something like this.

B) RESET CAUSE: FORCED RESET

I force a reset by writing 0 (zero) in WDCHK field of WDCR register.

If the reset is forced in BOOT (without SYS/BIOS) DSP resets and the code execution restarts from _code_start, i. e. from BOOT (correct!).

If the reset is forced in FIRMWARE (with SYS/BIOS) DSP resets and the code execution restarts from _code_start, i. e. from BOOT (correct!) only if CCS is NOT connected to the target.

On the contrary if CCS is connected to the target and the reset is forced in FIRMWARE code execution stops definitely and the program doesn't run again until I reset DSP through CCS or switch off and on power supply.

It seems like code execution jumps to a location not programmed, or something like this.

Summing up, I've seen that if CCS is not connected code execution starts correctly in all the following situations:

- after a power cycle (i.e. after switching off and on power supply);
- after a reset due to watchdog expiring;
- after a reset forced via WDCHK field.

So why should I add the lines to change Hwi.nonDispatchedInterrupts[0] configuration?

2) CHANGING Hwi.nonDispatchedInterrupts[0] CONFIGURATION

However, I've attempted to change the Hwi.nonDispatchedInterrupts[0] configuration adding the following lines to my app.cfg file

Hwi.nonDispatchedInterrupts[0] = new Hwi.NonDispatchedInterrupt();
Hwi.nonDispatchedInterrupts[0].fxn = "_code_start";
Hwi.nonDispatchedInterrupts[0].enableInt = false;
Hwi.nonDispatchedInterrupts[0].intNum = 0;

but the compilation fails with the following errors:

- ti.sysbios.family.c28.Hwi/nonDispatchedInterrupts/'ti_sysbios_family_c28_Hwi0': incompatible assignment to fxn : "_code_start"

- XDC runtime error: ti.sysbios.family.c28.Hwi/nonDispatchedInterrupts/'ti_sysbios_family_c28_Hwi0': incompatible assignment to fxn : "_code_start"

Why is "_code_start" assignment incompatible?

Regards,

Demis

Hi Demis,

I'm traveling today. I'll look at this tomorrow.

Todd

Demis,

I'm checking with the CCS team to see what they do on a device initiated reset.

Regarding the build error, do you have
_code_start=0x080000;
in the SYS/BIOS based application's linker file?

You need to have int 0 plugged for NMI interrupts. You've been testing out reset events. I'll throw together an example.

Todd

ToddMullanix said:

Demis,

I'm checking with the CCS team to see what they do on a device initiated reset.

Ok, thank you.

ToddMullanix said:

Regarding the build error, do you have
_code_start=0x080000;
in the SYS/BIOS based application's linker file?

No, I don't have that statement in my cmd linker file.

However I've got the same result in another way:

MEMORY
{
PAGE 0 :  /* Program Memory */

...

    /* Flash boot address */
    /* BEGIN is used for the "boot to FLASH" bootloader mode   */

    BEGIN   : origin = 0x080000, length = 0x000002

...

}

SECTIONS
{

...

   /* Allocate program areas:
             _code_start is the label at the beginning of codestart section */

   codestart                : > BEGIN                           PAGE = 0, ALIGN(4)

...
}

Then if I check my map file I find

ENTRY POINT SYMBOL: "_code_start"  address: 00080000

So I think I don't need _code_start=0x80000 assignment.

ToddMullanix said:

You need to have int 0 plugged for NMI interrupts. You've been testing out reset events. I'll throw together an example.

Ok, thank you.

Regards,

Demis

Hi Todd,
any news about this issue?

Thanks.

Regards,

Demis

Hi Todd,

any news about this topic?

I'm going on developing my project but I still experience the same problem, i.e. if the system is reset when CCS is connected via JTAG, the reset fails and the code execution is stucked at line 0x3FE2ED, that is in Boot ROM code.

The same problem happens if I call BIOS_exit(): the instruction following BIOS_start() call is never executed and the code is stucked at line 0x3FE2ED.

I don't know how to get around this issue, do you have any hints?

Thank you.

Regards,

Demis

Hi Todd,
I've made some more tests.
In particular I've forced a reset through watchdog registers when CCS is connected to my target via JTAG and BEFORE launching sysbios. However I've found the same undesired behaviour: the code execution is stucked at line 0x3FE2ED.

Therefore I think this behaviour doesn't involve sysbios but it depends only on CCS. Right?

Thanks.

Regards,

Demis

Ok, thank you.

Regards,

Demis