• State Resolved
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 9 replies
  • Subscribers 82 subscribers
  • Views 578 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:

TMS320F28379D: c_int00 after a customized bootloader program

TMS320F28379D: PIE after a custom bootloader

Lucas Munaretto
Intellectual 270 points

Part Number: TMS320F28379D
Other Parts Discussed in Thread: C2000WARE

Hello!

We have built a secondary bootloader that runs after the boot and then jumps to the application.

This is successfully done synchronously on both cores.

The problem: the app runs, but none interrupt seem to work on both applications.

--------------------

More info:

--------------------

I'm out of ideas so i hope you guys can help me out.

Thanks,

Lucas

  • 0
    TI__Guru 62975 points

    Lucas,

    Are you only using interrupts in the SYS/BIOS application or are you using them in your secondary bootloader as well? Can you help me understand what the secondary bootloader is doing in general?

    When you load the application symbols, do you have a GEL file loaded?  If so, remove the GEL file from your target configuration so that there is no background automated background activity that may be changing your run environment.

    -Tommy

  • 0 in reply to tlee
    Intellectual 270 points

    Hi Tommy,

    Both bootloader and application are using interrupts.

    The secondary bootloader can receive commands from our "head" processor (such as version, start, update and others) before jumping into application (start command).

    The GEL file was loaded. Removing it didn't work.

    I think that i'm missing something that the initialization (reset/restart) does before jumping into the application code. Does it make sense?

    BR,

    Lucas

  • 0 in reply to Lucas Munaretto
    TI__Guru 62975 points

    Lucas,

    The GEL file will perform a handful of initialization sequences in the background that may not be obvious to the user. When a program works when loaded through CCS, but doesn't work standalone, it is sometimes because the program is missing an initialization sequence that was performed in the GEL. In such a case, the expectation would be that loading the program without the GEL file would produce a similar failure.

    If you would like more visibility into what the Boot ROM is doing, you can find the source code in C2000Ware:  ~\C2000Ware_XXXX\libraries\boot_rom\f2837xd\revB\rom_sources\F2837x_bootROM\cpu01-bootROM\source

    Since you are having trouble with interrupts in both your secondary bootloader and main application, I would recommend debugging using a simplified program derived from the secondary bootloader and leaving out the main application for now.

    -Tommy

  • 0 in reply to tlee
    Intellectual 270 points

    Tommy,

    I think we missunderstood each other. Both bootloader and the main application individually works as expected (connected or not to the CCS).

    In fact, the bootloader always work and answer my commands to store a new image and to jump into the application (using interrupts).

    The application interrupts don't run only after the bootloader jump.

    I'll take a look in the source code you mentioned to see if i can find anything.

    Lucas

  • +1 in reply to Lucas Munaretto
    TI__Guru 62975 points

    Lucas,

    Thanks for clarifying. Are you disabling all of the global, group, and peripheral interrupts prior to making the branch?

    If not, it is possible that an interrupt may be triggered during the time when the CPU execution is transitioning from secondary bootloader to application. Clearing the phantom interrupts can be tricky if there are multiple sources pending within a group, or if a module is left running in the background where it can trigger additional interrupts.

    -Tommy

  • 0 in reply to tlee
    Intellectual 270 points

    Yes, that may be the issue.

    I'm trying to disable global and PIE interrupts "enables" and to clear some PIE flags before jumping using the below code. Is it right?

    DINT;
IER = 0x0000;
IFR = 0x0000;
PieCtrlRegs.PIEACK.all = 0xFFFF;

    You also gave me the idea to disable the bootloader peripheral interrupts before jumping. It should prevent phantom interrupts.

    I'll try it and then reply with news.

    Regards

  • 0 in reply to Lucas Munaretto
    TI__Guru 62975 points

    Lucas,

    It looks like there could still be PIEIER bits that carry over after the disable sequence. I recommend using the sequence from the C2000Ware examples.

    Header example (lines 85-114): ~\C2000Ware_XXXX\device_support\f2837xd\examples\cpu1\cpu_timers\cpu01\cpu_timers_cpu01.c

    Driverlib example (lines 99-109): ~\C2000Ware_XXXX\driverlib\f2837xd\examples\cpu1\timer\timer_ex1_cputimers.c

    -Tommy

  • +1 in reply to tlee
    Intellectual 270 points

    Tommy,

    Problem solved!

    From our conversation:

    • Now the bootloader disables all used peripherals interrupts and clocks before jumping to the application. So no more phantom interrupts.
    • The application now does initialize the PIE_Ctrl, enable and acknowledge PIE interrupts. It doesn't initialize the PIE_Vect because it is an SYS/BIOS application.

    Additionally i had to reconfigure some LSRAM master configuration. The application memcpy for CLA funcs and consts into the LSRAM wasn't working because the bootloader had already changed the memory configuration.

    Here are the bootloader code snippets before jumping:

    # CPU1 - Bootloader

IPCLtoRFlagSet(IPC_FLAG21);
while(IPCRtoLFlagBusy(IPC_FLAG21));
            
EALLOW;

DINT;

CpuTimer0.RegsAddr->TCR.bit.TIE = 0;

SpibRegs.SPICTL.bit.SPIINTENA = 0;
SpibRegs.SPIFFRX.bit.RXFFIENA = 0;
SpibRegs.SPIFFTX.bit.TXFFIENA = 0;

Cla1Regs.MIER.all = 0;

CpuSysRegs.PCLKCR0.bit.CPUTIMER0 = 0;
CpuSysRegs.PCLKCR8.bit.SPI_B = 0;
CpuSysRegs.PCLKCR0.bit.CLA1 = 0;

MemCfgRegs.LSxMSEL.bit.MSEL_LS0 = 0;
MemCfgRegs.LSxCLAPGM.bit.CLAPGM_LS0 = 0;
MemCfgRegs.LSxMSEL.bit.MSEL_LS1 = 0;
MemCfgRegs.LSxCLAPGM.bit.CLAPGM_LS1 = 0;
MemCfgRegs.LSxMSEL.bit.MSEL_LS2 = 0;
MemCfgRegs.LSxCLAPGM.bit.CLAPGM_LS2 = 0;
MemCfgRegs.LSxMSEL.bit.MSEL_LS3 = 0;
MemCfgRegs.LSxCLAPGM.bit.CLAPGM_LS3 = 0;
MemCfgRegs.LSxMSEL.bit.MSEL_LS4 = 0;
MemCfgRegs.LSxCLAPGM.bit.CLAPGM_LS4 = 0;
MemCfgRegs.LSxMSEL.bit.MSEL_LS5 = 0;
MemCfgRegs.LSxCLAPGM.bit.CLAPGM_LS5 = 0;

EDIS;

asm(" LB 0x084000");

    # CPU2 - Bootloader

IPCRtoLFlagAcknowledge(IPC_FLAG21);

EALLOW;

DINT;

CpuTimer0.RegsAddr->TCR.bit.TIE = 0;
Cla1Regs.MIER.all = 0;

CpuSysRegs.PCLKCR0.bit.CPUTIMER0 = 0;
CpuSysRegs.PCLKCR0.bit.CLA1 = 0;

MemCfgRegs.LSxMSEL.bit.MSEL_LS0 = 0;
MemCfgRegs.LSxCLAPGM.bit.CLAPGM_LS0 = 0;
MemCfgRegs.LSxMSEL.bit.MSEL_LS1 = 0;
MemCfgRegs.LSxCLAPGM.bit.CLAPGM_LS1 = 0;
MemCfgRegs.LSxMSEL.bit.MSEL_LS2 = 0;
MemCfgRegs.LSxCLAPGM.bit.CLAPGM_LS2 = 0;
MemCfgRegs.LSxMSEL.bit.MSEL_LS3 = 0;
MemCfgRegs.LSxCLAPGM.bit.CLAPGM_LS3 = 0;
MemCfgRegs.LSxMSEL.bit.MSEL_LS4 = 0;
MemCfgRegs.LSxCLAPGM.bit.CLAPGM_LS4 = 0;
MemCfgRegs.LSxMSEL.bit.MSEL_LS5 = 0;
MemCfgRegs.LSxCLAPGM.bit.CLAPGM_LS5 = 0;

EDIS;

asm(" LB 0x084000");

    Here are the application initialization code snippets:

    # Both CPUs

InitSysCtrl();

InitPieCtrl();

EnableInterrupts();

ERTM;

# Some code before SYSBIOS ...

BIOS_start();

    Thanks for the help!

    BR,

    Lucas

  • 0 in reply to Lucas Munaretto
    TI__Guru 62975 points

    Lucas,

    I'm happy to hear that you have resolved the issue. Thanks for sharing your solution for the benefit of others!

    -Tommy