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.

Compiler/TMS320F28379D: Problem with BINIT feature, possibly dependent on code size being copied

Part Number: TMS320F28379D
Other Parts Discussed in Thread: C2000WARE

Tool/software: TI C/C++ Compiler

I have come across a curious problem using the BINIT feature of the C2000 compiler while developing a Flash application for TMS320F28379D control card.

I have attached a stripped-down version of the project.  A lot of it comes from the C2000ware common header files.

I have been taking advantage of the binit copy-table feature to auto copy sections of flash into ram at boot time.  It has been working fine until now, where it seems to be dependent on the size of data being copied now that my code has grown.

Behavior observed (with C2000 codegen tools 18.1.1, 18.1.2)

When I program with debugger and hit run, everything works fine.  However, if I power down, then back up, the processor seems stuck in reset (I checked that boot mode pins are set to getmode), and the behavior is the same when powering up with/without the debugger connected.  It's hard to debug what state it is in, it could be an ITRAP or maybe it is stuck in the boot ROM, not sure.  I do have a reserved ISR assigned to all vectors in the PIE that would blink the LEDs if it arrives to an interrupt, but I have not observed this yet, so I don't think it's an ITRAP.

Apparent workarounds

If I reduce the CLA program code size enough, this behavior stops and I can power up and down several times, and every time it boots to the flash application (seen by blinking LEDs).  You can try this by editing ClaTasks.cla and removing all of the __mdebugstop() statements.  There seems to be some size at which perhaps the binit routine fails.  The size at which this happens is not large at all compared to the 0x3000 available for CLA code in this processor.  I am also not sure this is only related to the CLA code section, this may happen with other sections like ramfuncs.

If I use 15.12.7 compiler, this behavior also stops (only seen in 18.1.1 and 18.1.2).  I have only tested these 3 versions of compiler.

If I don't use BINIT feature, and just use load/run variables along with memcpy, this behavior also stops.  In the project, I have two different build configurations.  "DebugBINIT" uses the BINIT feature.  While "Debug" just uses load/run variables along with memcpy.

Observations

It's curious that when using 18.1.x compiler and using the BINIT feature, and programming with XDS100v2 debugger, it runs fine after hitting start.  Even if I do a suspend, then reset the CPU,and restart, it runs fine every time.  However, if I power down, then back up (with or without debugger connected), it won't boot the flash application.

The only things I have found to work are not using BINIT, using 15.x.y compiler, or reducing the CLA code size.  All of this seems unrelated and peculiar, hope you guys can shed some light.

0334.test.zip

  • not sure why was this moved? this seems to be a compiler issue

  • Hi Fulano,

    TABLE initialization takes place in startup routine, before PLL is setup and watchdog disabled. Watchdog may kick if initialization takes too long. You may define somewhere _system_pre_init() routine with watchdog disable inside. It's called prior to initialization.

    int _system_pre_init(void)
    {
    DisableDog();

        return 1;
    }

    Edward

  • You were right!
    I did have DisableDog() as the first thing in my InitSysCtrl() but that didn't matter because watchdog is being tripped before it even gets to the first line of main(). I had to disable watchdog as the first thing in codestart section.

    I guess the routines in boot.asm in the RTS library include the BINIT table copies and if this those take too long because the code is too big, then WD will kick in. Thanks Edward!!!!!!!