• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 2 answers
  • Subscribers 78 subscribers
  • Views 1339 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.

MSP430FR59891: I2C bootloader

sla
Prodigy 40 points
Part Number: MSP430FR59891
Other Parts Discussed in Thread: MSP-FET

Hi,

I am using the I2C bootloader of MSP430FR59891 (BSL version 00.07.34.B2). With each protocol error (e.g. master reading too many or not enough bytes) the BSL pulls SCL low thus blocking the I2C bus forever (clock stretching).

E.g. when I send the command TX BSL VERSION and try to read 11 bytes, this will be fine if the BSL was unlocked before with the correct password. But if BSL is still locked, trying to read 11 bytes will end up in a blocked bus (correct response length is 8 bytes in this case).

Is this the intended behavior or is there something different going wrong??

Thanks for any help.

  • 0
    TI__Intellectual 2460 points

    Hi Sla,

    could you please inform me what tool you are using to program the BSL?

    PC programmer tool (is it BSL Scripter, and which version?), Communication bridge from PC to Target device (is it MSP-FET, MSP BSl Rocket?).

  • 0 in reply to Fatmawati_Santosa
    Prodigy 40 points
    Hi Fatmawati,

    we are using a proprietary solution, basically a USB to I2C bridge and custom software library.

    Our current workaround to cope with the blocked bus is to implement SCL as uni-directional push-pull signal. When the master drives SCL high, the MSP BSL stops pulling SCL low and we are able to use all BSL features successfully (even though there are some CRC errors once in a while). But this approach obviously violates the I2C specification and thus prohibits the use of other slaves on the same bus.

    Best regards.
  • 0 in reply to sla
    TI__Intellectual 2460 points
    Hi Sla,

    thank you for your input. One thing that come to my mind is about entering the BSL mode.
    When the BSL starts on your setup? After device reset?
    The BSL needs to be invoked. the invocation is done by applying the Invoke-Sequence on TST and RST pins. (www.ti.com/.../slau550m.pdf section 3.3.2)
    Could you send me the bytes reply from BSL here? Successful operation usually returns: 0x00 0x80 0x02 0x00 0x3B 0x00 0x60 0xC4
  • 0 in reply to Fatmawati_Santosa
    Prodigy 40 points
    Hi Fatmawati,

    thank you for your reply. The BSL is invoked by software (section 3.3.1.1 in the document you mentioned). To be more precise, our MSP application listens on the i2c bus for a proprietary command. After reception, our application hands over control to the BSL. The invokation works fine and the BSL responses are received correctly as specified in the BSL protocol (section 4).

    But again: The problem arises as soon as we violate the protocol, e.g. try to read more bytes than specified. The question was if an endless clock-stretching is the intended behavior in this scenario?

    background info:
    The implementation of our USB to I2C bridge does not allow to interpret the BSL response during transmission. Thus, we cannot use the length field in the BSL response to define the number of bytes to be read. Instead, we have to define the length in advance. What makes it difficult is that the length is not fixed for a specific command but may depend on the BSLs state, e.g. the response to the TX BSL VERSION command may have 8 or 11 bytes depending on whether it is locked or not. Now, what if the lock-state is not known? The easiest way to handle this would be to always read 11 bytes and after transmission use the length field for data interpretation. Unfortunately, using this approach the BSL seems to block the I2C bus forever.

    I hope this helps to clarify my question.

    Kind regards.
  • 0 in reply to sla
    TI__Intellectual 2460 points
    Hi Sla,

    thank you for detailed reply. In I2C is bit tricky compared to UART, because the master generates the clock. If the slave (at this point is the BSL) do not have the bytes to send, this caused the unintended behavior.
    Using MSP-FET and MSP BSL Rocket, we handle the number of bytes in the packet to receive the data.

    What come to my mind right now, could you only in the beginning send the RX_PASSWORD to unlock the BSL and your host validate if the BSL is locked / unlocked? The number of bytes of these two responses are the same:
    0x00 0x80 0x02 0x00 0x3B 0x00 0x60 0xC4 (8 bytes) for unlocked
    0x00 0x80 0x02 0x00 0x3B 0x05 0x60 0xC4 (8 bytes) for locked
  • 0 in reply to Fatmawati_Santosa
    TI__Mastermind 20025 points
    Hi Sla
    May I know if your question has been solved according to Fatma comment?
    if it is solved. I will close the question. Thanks
  • 0 in reply to Fatmawati_Santosa
    Prodigy 40 points

    Hi,

    apologies for my late reply! Starting the communication with RX_PASSWORD could in fact be a workaround - thanks for pointing to the equally long responses. Problems may arise with different versions: Is it guaranteed that the RX_PASSWORD command/response will not change with future BSL versions? Otherwise you will have to check the version first...

    In general, I'm still wondering if TI's implementation to stretch the clock forever (and thereby lock the bus) is a reasonable strategy to handle the situation when the BSL (slave) has less data available than the master trys to read. For all I know clock stretching is designed to provide an opportunity for the slave to throttle down the master's clock to an appropriate frequency. However, I cannot see the point in permanently locking the bus as a result of a single protocol failure (even though I know the I2C spec does not limit the maximum duration for pulling SCL low, i.e. stretching the ckock). Wouldn't it be better to simply ignore any odd read access?

  • 0 in reply to sla
    TI__Intellectual 2460 points

    Hi Sla,

    the bytes length in RX_PASSWORD is consistent in MSP430 device for BSL that is programmed from factory.

    This behaviour comes from the BSL that is programmed in ROM for FR59891, so we could not reprogram the BSL as well. The option left to fix this is if you plan to implement the custom BSL that has to be implemented in FRAM program memory.

    Let me know if you have any other concern.

**Attention** This is a public forum