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.

TMDSPREX28335: Experimenter kit stuck in limp mode

Part Number: TMDSPREX28335
Other Parts Discussed in Thread: CONTROLSUITE, C2000WARE,

Ran code from control suite and trapped at estop limp mode.  Wrote my own code per data sheet to clear clock circuit (see below) and still traps at estop stuck in limp mode.  I checked w/ scope and do have 30 MHz on crystal and 1.9 Volts for the core.  This is the exact experimenter kit that didn't have the FTDI EEPROM programmed.  When checking SW2 it still had the tape over it.  I suspect I have bad hardware that needs to be returned.  Please advise.

int main(void)

{

 

unsigned int i;

 

DisableDog();

//

// Make sure the PLL is not running in limp mode

//

if (SysCtrlRegs.PLLSTS.bit.MCLKSTS != 0) // If clock is limping

{

SysCtrlRegs.PLLSTS.bit.MCLKCLR = 1; // Then clear the missing clock detection circuits

if (SysCtrlRegs.PLLSTS.bit.MCLKSTS != 0) // If clock is limping

{

SysCtrlRegs.PLLSTS.bit.MCLKCLR = 1; // Then clear again

for(i = 0; i < 0xff; i++); // Wait awhile

if (SysCtrlRegs.PLLSTS.bit.MCLKSTS != 0) // If clock is limping

//

// Missing external clock has been detected

// Replace this line with a call to an appropriate

// SystemShutdown(); function.

//

asm(" ESTOP0");

}

  • Hi Tim,

    I'm sorry to hear you're having this problem. The CPU should switch to INTOSC1 if the current source you are using (external XTAL, XCLKIN or INTOSC2) goes missing. This being the case your INTOSC1 may also be missing which will keep it in limp mode.

    I think the 2nd page of the following previous forum post explains this well and might help you solve this:

    Hope this helps,

    Kevin

  • Returned that experimenter kit to Digikey and ordered another one.  The next one also had the FTDI eprom blank just like the other one that didn't work.  I programmed it according to another thread and got it to connect and got around that issue.  This one does not trap on limp but it will not execute while(1) with out going out into the weeds. (It eventually gets to 0x3ff9fa). Someone might recognize the address its going to and have an idea but its obvious these are not being tested at all before shipment and I suspect I have bad hardware again.  Here's the code execution that is derived from control suite or  just bulding an empty project with main ends up with the same result.  Maybe the watchdog is causing issues but it should be disabled.  Here is the code that contains the while (1);

    int main(void)

    {

    unsigned int i; 

    DisableDog();

    while(1);

    }

     

    And here is the disassembly showing the Program counter ending up at 3ff9fa

     

    3ff9e6:   5AA9        MOVZ         AR2, @AL
    3ff9e7:   5BA9        MOVZ         AR3, @AL
    3ff9e8:   5CA9        MOVZ         AR4, @AL
    3ff9e9:   5DA9        MOVZ         AR5, @AL
    3ff9ea:   88A9        MOVZ         AR6, @AL
    3ff9eb:   80A9        MOVZ         AR7, @AL
    3ff9ec:   761F0000    MOVW         DP, #0x0
    3ff9ee:   2BBD        MOV          *SP++, #0
    3ff9ef:   28BD0A0B    MOV          *SP++, #0x0a0b
    3ff9f1:   7600        POP          ST1
    3ff9f2:   7613        POP          ST0
    3ff9f3:   0006        LRETR       
    3ff9f4:   561F        SETC         OBJMODE
    3ff9f5:   7622        EALLOW      
    3ff9f6:   B9C0        MOVZ         DP, #0x1c0
    3ff9f7:   28290028    MOV          @0x29, #0x0028
    3ff9f9:   761A        EDIS        
    3ff9fa:   6F00        SB           0, UNC
    3ff9fb:   FFFF        ITRAP1      
    3ff9fc:   FFFF        ITRAP1      
    3ff9fd:   FFFF        ITRAP1      
    3ff9fe:   FFFF        ITRAP1      
    3ff9ff:   FFFF        ITRAP1      
    3ffa00:   FFFF        ITRAP1      
    3ffa01:   FFFF        ITRAP1      
    3ffa02:   FFFF        ITRAP1      
    3ffa03:   FFFF        ITRAP1      
    3ffa04:   FFFF        ITRAP1      
    3ffa05:   FFFF        ITRAP1      
    3ffa06:   FFFF        ITRAP1      
    3ffa07:   FFFF        ITRAP1      
    3ffa08:   FFFF        ITRAP1      
    3ffa09:   FFFF        ITRAP1      
    3ffa0a:   FFFF        ITRAP1      
    3ffa0b:   FFFF        ITRAP1      
    3ffa0c:   FFFF        ITRAP1      
    3ffa0d:   FFFF        ITRAP1      

     

    Where can I get known good hardware that was tested before shipment?

     

     

  • Update:  Changed cmd file to run program out of flash instead of ram and now this second unit won't come out of limp mode just like the first one.  The crystal has a 30 MHz signal on it though.  Read above but this is the second one that also appears to be bad.  I hoping someone at TI can assist and get something to me that is tested before shipped like a used one or something. 

  • For some reason I either thought that DSP2833xHeaders_nonBIOS.cmd was ethier -l (linked in)  or that I wouldn't need it for just a go main project with one or two lines of code.  In either case I linked it in and now the processor is no longer going out in the weeds.  Guess:  Maybe the watchdog was enabled even though it was disabled?  As far as the limp mode situation again seems odd that this command file would be needed for just a few lines of code.  It is still odd that both EVM's did not have the FTDI EEPROMS programmed and the Mylar tape is over the switch packs.  Leads a person to believe that maybe the experimenter kits are not being tested?  

  • Hi Tim,

    Have you tried running a clean example program from ControlSuite / C2000Ware? That is example programs that have not been altered after being imported. You could try running something simple like Example_2803xLEDBlink just to see if it works.

    Are you able to connect to your device when running a "Test Connection" in the Target Configuration setup. View --> Target Configurations --> Double click the correct .ccxml --> Test Connection (Will test the connection and tell you whether it failed/succeeded).

    Do you have SW1 set to the "off" position? I believe you receive it in the "on" position per www.ti.com/.../sprugm2a.pdf

    When running the program from flash instead of ram did you set the Build Configuration to FLASH? Right Click your project --> Properties --> click Build --> Select configuration.

    Hope this helps,
    Kevin

    Edit: Happy you figured it out!

  • Hi Tim,

    First off I apologize for the issue with the FTDI chip and needing to reprogram it to get the kit to work.

    Please note that this kit, the TMDSPREX28335, is tested at the place where it is manufactured.  It has been awhile since this kit was designed, but from memory, nearly all of the key components are tested on the baseboard.  Full test coverage wasn't a requirement, but I'd guess about 90% coverage.  The main portion of the testing didn't utilize the FTDI chip's JTAG (or UART) connection, but was added as a standalone step - and it is feasible that this got missed in a recent batch.  Can you provide a picture of your kit's label/barcode or provide the LOT# on said sticker?


    Thank you,
    Brett

  • Yes thanks for getting back.  Just to be clear the experimenter kit is working now after I linked in the additional second cmd file described above (marked as answer).  It is very strange though that it would be necessary just to run a few lines of code. 

    I'm glad to hear that it might have been mostly tested but just not a final usability test the way the customer would use it.  If the photo comes through its right below this text containing the info you may have been asking about.

  • Date Code 1652 Also not programmed, multiple units.

    Please check stock and advise.

  • Following up on this. Kindly advise.

  • Hi Kristof,

    We have identified the root cause and are working on a plan to fix the current inventory.

    I will contact you offline.


    Thank you,
    Brett