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.

MSP430F5359: Is the TI MSP430 "Boot Code" documented or accessible?

Part Number: MSP430F5359

We're trying to document in some detail the exact start-up behavior of our system. The documentation makes it clear that the MSP430F5359 has a small ROM that contains the "Boot Code" that actually is given control of the processor at POR/BOR (Power-On Reset/Brown-Out Reset) time and that code performs certain very low level initialization activities and then decides such things as 1) Activate or leave deactivated the JTAG/SBW interface and 2) transfer to TI's BSL or through the RESET_VECTOR to the user's program.

Is this code documented anywhere in any detail? Is this ROM accessible to ordinary MSP430 application code? Is it accessible to the BSL code?

In a related question, we find that our MSP430F5359 is clocking at about 300 KHz when it first exits the Boot Code. Is this documented somewhere? (Is this what I would calculate out if I simply took the default register states of the UCS after POR/BOR?)

Atlant

  • You can't find detailed information about  boot code as it belongs to TI internal material. It can't be accessed by any software, as it is not in memory map.

     Which clock you are talking about? DCODIV? Yes, you can calculate out to take the default register states of the UCS after POR/BOR. Sorry, my computer is broken, I can check the DCODIV default clock for you next week.

    Eason

  • Eason:

    Eason Zhou said:

    You can't find detailed information about  boot code as it belongs to TI internal material. It can't be accessed by any software, as it is not in memory map.

     

    Thanks; that's what I figured.

    Eason Zhou said:

    Which clock you are talking about? DCODIV? Yes, you can calculate out to take the default register states of the UCS after POR/BOR. Sorry, my computer is broken, I can check the DCODIV default clock for you next week.

    I'm speaking of ACLK. When I was doing my timing test, immediately after CSTART() got control, set the stack, and had called into __low_level_init()), I set P3.4 to echo out SMCLK (which at init time is a 1:1 representation of ACLK). Using toggles on another GPIO, I also watched the rate of instruction execution and that matched what I was seeing via SMCLK.

    Thanks for your help so far!

    Atlant

  • Hi Atlant,

    Does your problem solved?

    Eason

**Attention** This is a public forum