• State
  • Locked Locked
  • Replies 8 replies
  • Subscribers 32 subscribers
  • Views 374 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.

MSPM0L1304: BSL start application command doesn't work

Michael Walle
Prodigy 130 points
Part Number: MSPM0L1304
Other Parts Discussed in Thread: MSPM0C1106,

Tool/software:

Hi,

The start application command doesn't seem to work. Here is what I am doing:

  1. asserting the INVOKE_BSL pin and reset the uC
  2. the BSL is accessiable via I2C
  3. send BSL_CONNECT command
  4. send BSL_START_APPLICATION command

I'd expect that the application will be started. But that is not the case. Please note, that the INVOKE_BSL pin is still asserted. It seems to work fine if INVOKE_BSL is not set, though. But that is something we *cannot* do. For a little bit of background: This uC is used on a SoM which has also linux running and there we have a recovery mode. If the recovery mode is active, the INVOKE_BSL pin is asserted the whole time. Thus on a reset, it shall boot into the BSL to bootstrap the uC regardless of what binary was flashed there. After the reset, the bootloader of the SoC will then either (re)flash the uC or start the flashed application. Unfortunately, the latter doesn't work.

Best regards,
-michael

  • 0
    TI__Guru 71216 points

    Hi Michael,

    I believe the issue is keeping the BSL invoke pin asserted the whole time.  Based on the timing diagram in the TRM, section 3.2.3, you must de-assert this pin no sooner than the t_start time specified in the datasheet, section 7.8.

  • 0 in reply to Dennis Lehman
    Prodigy 130 points

    Hi Dennis,

    I disagree, the TRM states (Section 3.2.3):

    GPIO should be asserted before the POR, and the state should be maintained for at-least T_start ms after POR.
    Then the GPIO pin state can be de-asserted.

    Thus T_start is only to make sure the pin is sampled correctly after POR. There is no requirement to release it again. Also, according to Figure 3-2. t_start is the time until the exit of the bootcode Thinking

    Best regards,
    -michael

  • 0 in reply to Michael Walle
    TI__Guru 71216 points

    Hi Michael,

    I have reached out to our design team to check on the specific behavior required on the BSL INVOKE pin.

  • 0 in reply to Dennis Lehman
    TI__Guru 71216 points

    Hi Michael,

    I have a response from the designers.

    Yes, the pin should be de-asserted. Whenever Boot re-runs the pins are checked. Section 2.4.1.6 Reset Cause mentions, BCR Execution happens after BSL Entry / BSL Exit resets. Hence BSL Invoke check happens again.

  • 0 in reply to Dennis Lehman
    Prodigy 130 points

    Hi Dennis,

    that is pretty unfortunate and it is not mentioned in any of the datasheet/BSL doc/TRM.

    What is then the difference between "Start Application" command and a reset of the MCU? To me this looks like a bug in the boot ROM, can you confirm this? Also, I fail to see the correlation between "Section 2.4.1.6 Reset Cause" and the "Start Application" command. Could you please elaborate a bit more?

    Thanks,
    -michael

  • 0 in reply to Michael Walle
    TI__Guru 71216 points

    Hi Michael,

    Yes, I agree the docs do not explicitly state this, so I'm working with our systems team to get an update to our docs.

    I'm looking at the code (below) where the BSL pin is checked (blInvocation_checkPinCondition)  on line #98.  The pin state is checked starting on line #144 and from what I can tell it simple returns a TRUE if the pin state matches the expected state, else false.  In your case it will because the keep the BSL invoke pin high.

    So after the pin check returns TRUE, I would expect the code to return TRUE on line #101,  exiting the Do..While() loop.  Else the code remains in this loop calling blInvocation_checkPinCondition() over and over, until the 10 sec BSL timeout expires and the BSL is locked and the CPU enters a sleep mode.  See section 3 " BSL Architecture" in the  MSPM0 Bootloader guide.  So let me present this to our BSL team for comment.

    BTW, if you haven't already discovered the FLASH BSL source code, it is in the SDK under:

    C:\ti\mspm0_sdk_2_05_00_00_internal\examples\nortos\LP_MSPM0C1106\bsl\flash_bsl

  • 0 in reply to Dennis Lehman
    Prodigy 130 points

    Hi Dennis,

    thanks for the pointer. From what I can see from the code (which isn't for the MSPM0L1304 btw, but I doubt that matters here), is that a "start application" is just a reset. If that is really the case, that command has a *really* bad name honestly. Because I'd assume that it is common sense that if a bootloader has a "start application" command it will do something like "jump to the application entry point" and not just a reset  and let the bootloader figure out the next steps (again). So if it was named just "reset" it would make far more sense.

    Thanks,
    -michael

  • 0 in reply to Michael Walle
    TI__Guru 71216 points

    Hi Michael,

    I won't disagree with you that the "start application" may be a bit misleading and would mean just that.