• State TI Thinks Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 78 subscribers
  • Views 1058 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.

Bootloader Interrupt Proxy Vector causes latency for main application (I2C interrupt operation)?

Vern Yip
Intellectual 810 points

Hello

I have a program that is fully functional in with I2C.  The TI MSP430 F5310 is a slave device.  When using a bootloader, I remapped the interrupts to a proxy vector.  I noticed that when the main application which uses interrupt-driven I2C operation (slave), the I2C MSp430 will clock stretch due to increased latency delay due to the interrupt re-routing.

Is there any way I can solve this latency problem?  I know I can increase the clock.  But what about methods of vector interrupt or using polling I2C methods?

  • 0
    TI__Genius 16840 points
    Hi Vern,

    I think you already answered your question. The clock stretch will depend on how fast you can read/write the registers, so you can: increase the CPU clock, use polling (assuming that no other interrupt is enabled while you are polling, or, reduce the latency of your interrupt.

    Since you are using F5xx, have you considered HW vector redirection instead of a SW-based proxy? It will use some of your RAM, but the latency will be the same as a HW interrupt. Check SYSCTL.SYSRIVECT for more detais.

    Regards,
    Luis R
  • 0 in reply to Luis RC
    Intellectual 810 points

    If I put the interrupts in RAM for the application program, then could the BSL continue to use the default interrupt table in flash?  Would I still need a proxy vector?

  • 0 in reply to Luis RC
    Intellectual 810 points
    So I took a look at the sample interrupt re-allocate to RAM code and was able to reallocate my interrupts to RAM. I was able to get the version of re-mapping during run-time to work.

    But I'm not sure if this improved my performance at all. The reason I question this, is because my raspberry pi is my test device. It does *not* support clock stretching, so any smbus I/O error, I know is a result of clock stretching done by the slave(MSP430). I ran through some regression testing scripts(python) and it failed immediately when certain operations took a long time to respond for the MSP.

    So is re-mapping the interrupts to RAM faster than the default vector interrupt stored in flash at 0xFF80 ?? When I re-map to the RAM, does the CPU still have to jump twice? Once to 0xFF80 vector table, and second to RAM? or does the CPU jump directly to the RAM to look for the ISR address?
  • 0 in reply to Vern Yip
    TI__Genius 16840 points

    Hi Vern,

    Re-mapping the interrupts has the same latency as the flash vectors, the device gets the address directly from RAM.

    But I'm thinking that something else is probably causing the latency in your system, is this the only interrupt enabled?

    Even if you are using the proxy method, it should only add a few cycles (maybe ~5) to your latency. How much clock stretch do you see in your system?

    It's important to mention that the most critical latency is for the first byte when the MSP430 works as a Slave Transmitter since you need to write the TXBUF quickly in order to avoid clock stretching:

    The situation is different for the rest of the bytes and for reception due to the double-buffered mechanism of USCI.

    Regarding your previous question, the default BSL doesn't use interrupts, but I'm not sure if you have a custom BSL or something.

    In any case, the device will always have the interrupts in Flash after Reset, but if your application redirects to RAM and then you need to use them in Flash again (in your bootloader or somewhere else), then you need to clear the  SYSRIVECT bit.

    Regards,

    Luis R

  • 0 in reply to Luis RC
    Intellectual 810 points

    It looks like small operations (1 byte/2 byte) writes or reads work. But doing a block write/read will fail immediately. The CPU jumps to address 0x4 (no symbols) and hangs there. The only three interrupts I have are:

    watchdog, usci_b1_isr (pretty sure no interrupts are happening here), usci_b0_isr (this is the i2c slave)

    all 3 have their addresses properly re-mapped to RAM.


    also, I am using timerA0 , but I am not using it with an ISR function. I'm just using it as a flag checking. I wonder if I also need to re-route the address for this? But it shouldn't be, since there isn't an ISR to call right?


    oh, i'm not using a bootloader yet.  Just making sure the main application works first.

  • 0 in reply to Vern Yip
    Intellectual 810 points
    Luis - I figured out the problem, but I'm not entirely sure why it's happening.

    It turns out that, when doing a large transfer (32 bytes) of i2c data, somehow that data (TXBUF) which is supposed to end up in flash?? is possibly overwriting the ISR address in RAM. How this is possible, I'm not sure as according to CSS, my ram usage is only 3,606(58%) of 6,144 bytes and the ISR is at the top of the memory address at 0x3400.

    So, in my main function, if I continuously copy the ISR address to the vector table in RAM, then it works:
    ram_int_vector_p->usci_b0_rx_tx = (isr_type_T) &USCI_B0_ISR

    then my program functions normally. Why do I have to do this? I'm pretty sure the device is not BOR and it's just processing 32bytes of data per I2C transaction. After doing this, the device seems to function and can continuously receive 32 bytes of data with no hiccups.
  • 0 in reply to Vern Yip
    Intellectual 810 points
    Ok, it turns out I had a small bug in my code where the vector was not mapped correctly. I went back to using a constant variable defined for the interrupt vector and that seems to work great now. But if I use the method of copying the interrupt ISR address during run-time, that's when I run into trouble as I see my interrupt addresses getting over-ridden and then it crashes. So I guess I'll just use a const defined variable before run-time.

    Thanks
  • 0 in reply to Vern Yip
    Intellectual 810 points

    Question - is it best to have the bootloader use the default interrupt vector in flash, and the main application use the interrupt vector in RAM?  or vice versa, bootloader uses the interrupt vector in RAM, and application uses interrupt vector in flash?

  • 0 in reply to Vern Yip
    TI__Genius 16840 points

    Hi Vern,

    It depends on your application, but I would usually protect the bootloader area and the interrupt vectors, leaving the interrupt vectors fixed to be used by the bootloader.

    Regards,

    Luis R

    Please click the Verify Answer button on this post if it answers your question

**Attention** This is a public forum