• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 80 subscribers
  • Views 2767 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.

MSP430G2433 Errata item USCI29 workaround (2)

Tiago Monte
Prodigy 90 points

Other Parts Discussed in Thread: MSP430G2433, MSP430G2230, MSP430F2330

Hi,


My MSP430G2433 seems to be resetting randomly when there is some more intense traffic in the I2C bus, I think it's related to the errata item USCI29. I have implemented the workaround (2) but it doesn't seem to get linked to the final .hex. My trap vector interrupts is as follows:

#pragma vector=TRAPINT_VECTOR
__interrupt void trapint_isr(void)
{
   trapCount++;
    __no_operation();
}

The variable trapCount is global in the i2c source file (where this trapint is also placed) and the reason why I say that the trap vector is not getting linked is because I can't find the trapCount symbol in the map file. I guess that is because it's seen as never used. If I use is elsewhere in the file (e.g. one of the i2c interrupts) then I see it in the map file. I have also tried to toggle a pin inside the trapint but I see no transitions and when I try to set breakpoints inside it I get a warning from CCS saying that it doesn't find the relevant line in the obj file.

One final note, I tried both with and without defining TRAPINT_VECTOR as instructed in the errata but the result is the same. However if I don't define it I get "warning #2580-D: pragma vector= accepts numeric arguments or "unused_interrupts" but not TRAPINT_VECTOR". I'm using latest tools, CCSv6 and MSP430 compiler v4.3.3 so the definition shouldn't be necessary according to the errata information.


Any ideas?

Thanks

  • 0
    TI__Guru 56650 points

    Hi,

    it seems you need to make modification on the linker command file also. Please refer to the following CCS v6 example:

    4505.usci29_workaround.zip

    if you compile this with CCS v6.0, you shall see TRAPINT_ISR symbol defined in the generated MAP file.

  • 0 in reply to Leo Hendrawan
    Prodigy 90 points

    Thank you, that solved my problem.

    I found that TRAPINT vector is in some of the linker command files in C:\ti\ccsv6\ccs_base\msp430 (e.g. lnk_msp430g2330). Why isn't it in all the files for products which suffer from this problem? Or at least it should be documented in the errata that a change to the linker command file is needed.

  • 0 in reply to Tiago Monte
    TI__Guru 56650 points

    Hi,

    lnk_msp430g2330.cmd seems to be not a valid file name, do you mean lnk_msp430g2230.cmd?

    I looked into it, but couldn't find any TRAPINT. Could you show me what you meant?

    Anyway, it seems that starting MSP430 Compiler version 4.x, the compiler/linker will assign a default trap ISR to unassigned vector. This is documented here: http://www.ti.com/lit/ug/slau131i/slau131i.pdf, section ".intvec" at page 109:

    If you do not specify an ISR routine for some interrupt vectors, an ISR routine will be provided for those vectors from the RTS library and the RTS library will automatically be linked with your application. The default ISR routine puts the device in low power mode. 

    If you look into the generated MAP file, you can find the symbol __TI_ISR_TRAP which refers to the default RTS library trap ISR function.

  • 0 in reply to Leo Hendrawan
    Prodigy 40 points

    Hi,

    Yes, if you browse with Windows Explorer to C:\ti\ccsv6\ccs_base\msp430 and then write "Content: *TRAPINT*" in the search bar at the top right corner you'll see all the files which have that. Here are the ones that I see.

    If you open for instances lnk_msp430g2330.cmd (it is a valid filename on my ccsv6 installation) and look for TRAPINT you'll find:

    /* MSP430 INTERRUPT VECTORS          */
        TRAPINT      : { * ( .int00 ) } > INT00 type = VECT_INIT
        .int01       : {}               > INT01
        PORT1        : { * ( .int02 ) } > INT02 type = VECT_INIT
        PORT2        : { * ( .int03 ) } > INT03 type = VECT_INIT

    I saw the __TI_ISR_TRAP in the map file but that seemed to be associated with the unused_interrupts vector (interrupt function name is user_trap_function) as they have the same address in the map file.

    GLOBAL SYMBOLS: SORTED BY Symbol Address

    address    name
    --------   ----

    0000fd12   __TI_ISR_TRAP
    0000fd12   user_trap_function

    Anyway, it would be good to extend the workaround description in the device errata to alert for the linker command file change. The information is scattered around different documents so sometimes it's a bit hard to figure out what is going wrong. It could also be my misconception as I wouldn't expect having to do changes to tools related files.

  • 0 in reply to Tiago Monte1
    Prodigy 40 points

    Oh sorry, you were right, it's lnk_msp430f2330, you were right, I didn't notice the one letter difference. Sorry about that.

  • 0 in reply to Tiago Monte1
    TI__Guru 56650 points

    Tiago,

    ok thanks for the hints. I will try to forward this to the team in charge for releasing the linker command files.

**Attention** This is a public forum