• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 80 subscribers
  • Views 583 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Motorware labs on launchXL-F2802x problems

Giannis Roussos
Expert 2290 points
Other Parts Discussed in Thread: MOTORWARE, CONTROLSUITE

Hi,

I am trying to use the Motorware examples (labs) using a F28027F launchpad but all of them cause the processor to get stuck when executin HAL_Init.

I have tried with and without the Boost-XL and external power supply and the result is always the same.

I have tried CCS v5.5 and c6.01, both with the latest Motorware.

Stepping the program in assembly, the problem seems to start at a LCR command is executed with an operand pointing to a memory mapped area or a location with FFFF (ITRAP) in it.

Please note that I have removed the optoisolators on the launchpad and connected directly the JTAG, power and UART signals. I cannot remember if I had tested the labs before that, but I do not see how this could affect the result, especially when providing all power from USB.

  • 0
    Expert 2290 points

    The specific point of assembly code that causes the problem is:

     624          obj->offsetHandle_I[cnt] = OFFSET_init(&obj->offset_I[cnt],sizeof(obj->offset_I[cnt]));
3f5683:   8AA3        MOVL         XAR4, @XAR3
3f5684:   0210        MOVB         ACC, #16
3f5685:   767FD8C3    LCR          0x3fd8c3

    When the LCR instruction is executed the PC jumps to 0x3fd8c3, which seems to be mapped to something and I cannot see its contents

    EDIT: Looking at the .map file, I see that 0x3fd8c3 is the address of _OFFSET_init(). Also, it seems that the cpu does not hang upon entry of this function, but it gets stuck at a SB instruction inside the FS$$TOFD function from rtslib. The code leading to the SB instruction is:

    3ff7db:   88A9        MOVZ         AR6, @AL
3ff7dc:   80A9        MOVZ         AR7, @AL
3ff7dd:   761F0000    MOVW         DP, #0x0
3ff7df:   2BBD        MOV          *SP++, #0
3ff7e0:   28BD0A0B    MOV          *SP++, #0x0a0b
3ff7e2:   7600        POP          ST1
3ff7e3:   7613        POP          ST0
3ff7e4:   0006        LRETR        
3ff7e5:   561F        SETC         OBJMODE
3ff7e6:   7622        EALLOW       
3ff7e7:   B9C0        MOVZ         DP, #0x1c0
3ff7e8:   28290028    MOV          @0x29, #0x0028
3ff7ea:   761A        EDIS         
3ff7eb:   6F00        SB           0, UNC

    EDIT 2: Looking at the C2000 instruction set reference, it seems that the "SB 0, UNC" instruction is an uncoditional branch with offset 0, i.e. to the same instruction, i.e. it keeps the cpu there forever.

    I also upgraded to C2000 compiler 6.2.9 and the results are the same

  • 0 in reply to Giannis Roussos
    Expert 2290 points

    Well, it turns out I have been given a F28027 ( NON F!) launchpad, while the motorware examples are set up for F28027F! I didn't know the distinction between "F" and non-F models, so that was my mistake.


    I am now trying to run lab01 on the F28027 to get used to the motorware API and develop the interface for a SPI device, which will then be integrated in a custom application with a "F" cpu. However, when I just changed linker command file from F28027F to F28027, I get linker errors about the code size not fitting in the available sections, since only FLASHA is set up for program code in F28027F.

    Maybe I will use a ControlSuite example to develop the SPI device library and migrate  this to MotorWare later when I have a "F" board to work with.