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.

F28035 Experimenter's Kit getting started issue

Hi everyone!

I've just started to work with Piccolo F28035 Experimenter's Kit and faced with a problem. When I load an example project (for instance Example_2803xLEDBlink.pjt) and run it, the program sucks  on the point:

3FF8CD 6F00        SB         0,UNC

I tried to load the project both into RAM and Flash and got the same result - program stops there before entering main(). If I force the debugger to set program counter to cursor somewhere further in the program and run it from there, it just jumps to ILLEGAL_ISR() routine. I tried several different projects, which work well on this controller but on the other board (not experimenter's kit).

Do I need to configure Boot RAM in some special way or do I miss something simple? I hope for your help, because it's really frustrating that I'm not able even to blink a LED with a factory board...

 

Best regards,

Glib.

 

  • Glib,

    Yes, this does have to do with your boot options. the LEDBlink example runs out of RAM. My guess is that your Debug options are set such that the device resets when you load your code, and then when you run, the device is in the wrong boot mode - therefore it traps and jumps to an illegal isr routine.

    To remedy this, after you load your code:

    1. In CCSv4, from the Scripts menu -> Go to "EMU Boot Mode Select" -> Select "EMU_BOOT_SARAM()" (or EMU_BOOT_FLASH() for flash booting)

    2. Then Reset your device.

    3. Then Run.

    If you don't want to run the GEL script command, Step 1 can also be achieved by opening a memory window to address locations 0xD00, 0xD01. Write "0x55AA" to 0xD00, and write "0x000A" to 0xD01. This sets the device in SARAM boot mode. Then reset the device and run. Note that this only works in debug mode. In standalone mode, if you want to boot to SARAM, you will have to program the correct boot mode you want to use into OTP. For more information on the boot modes available on the 2803x and how to access them in DEBUG mode vs. STANDALONE mode, please see the 2803x boot ROM guide (SPRUG0)

  • Thank you for reply, Chrissy!

    I'm working in CCSv3.3 and I'm using usual project-files - not GEL-files. But I checked the memory address you mentioned and it is already set as you told.

    I tried also to load this example to the FLASH using F28035.cmd and changed 0xD01 location to 0x000B - for EMU_BOOT_FLASH mode, but I still get the same result - it stucks on

    3FF8CD 6F00        SB         0,UNC

    Any suggestions, what else can I do?

     

  • You will actually need to make a number of changes to your code and projects in order to load the example to FLASH beyond just switching out F28035.cmd. For example, the InitFlash routine must be moved to RAM, the MemCopy function must be called, etc.  You can look at the "flash" example as reference.

    The exact steps you will need to take are outlined in the DSP2803x_HeaderFiles_QuickStart_Readme document (in your header file download package, it should be in the \doc directory). See the section on "Executing the Examples From Flash".   

    The steps are also documented in the application note: Running an Application from Flash (spra958), but I believe the TI website is having some problems currently so I'm not sure when that will be available for you to look at.

  • I did use MemCopy and InitFlash functions but it still doesn't work. But thanks for your advices, I downloaded spra986 about an hour ago, but just didn't have time jet to read it. 

    So now I'm gonna learn the documentation, I'll write if I solve my problem.

    Glib

  • Well, I still haven't solved this problem, but I discovered a strange fact. According to the SPRA958 if I set a break-point at the start of _c_int00 (0x3F64EF) and at the beginning of main() and program reaches the first one but never comes to the second - it's a watchdog timer issue. And I have exactly this situation. I also set break-point at the address 0x3FF8A1, where program comes after reset, and I reach this break-point over and over again. So it really looks like a watchdog interrupt. But the strange thing is that WD is disabled in CodeStartBranch.asm:  

    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

    And I checked while single-stepping that this code is being executed.

    So how could it be? Can the WD be reenabled by some hardware or something, although it is EALLOW protected?

  • Another strange thing - now it's working :)

    Like there was no reason not to work, there was no reason to start working as well. I just reinstalled sprc892 and now everything is OK... I still wonder, how could the watchdog interrupt fire, but now, when it's working, I think it's impossible to find out the reason. 

  • Hi,

    i have 2 problems with Motor Control and Power Factor Correction Experimentier's Kit. It has F28035.

    First the USB-Interface dosen't function right. If i open the Device Manager

     

    7624.Device_Man..doc

     

    you see, that it isn't right.

    What can I do?

    Please help me.

    Thanks