• State TI Thinks Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 79 subscribers
  • Views 1533 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.

BSL loader strange behavious in MSP430F169

alexey nalimov
Prodigy 60 points
Other Parts Discussed in Thread: MSP430F169, MSPBSL

Hi everyone !

Sorry, this question is possibly a duplicate, but forum reports Access Denied for the original post by Dmitry Cholovsky...

Trying to program MSP430F169 with BSL serial interface according to slau319k specification.

TX BSL version reports v.1.61

Mass erase command reports ACK

But RX password with all 0xFF works strangely. It reports NACK code, but with some minor delay after it more bytes are following: 0x60 0xFF 0x80 0xFF

Have any ideas ? As this chip has different BSL spec, all existing solutions for MSP430F5xx are useless.

  • 0
    TI__Guru 68116 points
    Hi Alexey,

    Did you know that there is a program that supports MSP430F169 BSL host on the PC as well found in the same download as the BSL scripter: www.ti.com/.../slau319

    In the MSPBSL_Programmer_Package folder, look in BSL_Files/Deprecated/BSLDEMO/EXE. The BSLDEMO2.exe supports 1xx/2xx/4xx devices. There is an example demo.bat file that calls it that you can look at as an example or modify for your needs, or you can just call BSLDEMO2.exe from the command line and it will show you a list of the parameters that it expects. The source code is also included in the BSLDEMO/SOURCE folder if you want to see that as well. Note that because your part has version 1.61 you don't need to load patch.txt or anything and can skip those steps.

    Hope this helps point you in the right direction.

    Regards,
    Katie
  • 0
    Guru 58965 points

    alexey nalimov said:
    As this chip has different BSL spec, all existing solutions for MSP430F5xx are useless.

    Yes. MSP430F169 is a member of the 1xx family, thus Section 2 of slau319k applies to this chip whereas Section 3 (for 5xx etc.) does not apply.

    I think your problem could be cause by sending the commend bytes consecutively without a gap in time between the bytes. MSP430F169 needs some time to process each byte before it is ready to receive the next byte. Try send the bytes in each command with a gap in time between the bytes.

  • 0 in reply to Katie Pier
    Prodigy 60 points
    Dear Katie,

    I will try this tool, but in 2-3 days if not found standard solution - currently MSP430 is being programmed by other microcontroller, so too lazy to make new wires to the USB/UART adapter :)
  • 0 in reply to old_cow_yellow
    Prodigy 60 points
    Thank you, this seems a good idea - I found that timeouts were not correct. After I had adjusted delays between commands, and "strange" bytes after NACK reply stopped. But RX password still reports NACK.

    How this can happen after chip had been succesfully erased ?

    RX password bytes sent:
    0x80 0x10 0x24 0x24 0x00 0x00 0x00 0x00 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0x5B 0xCB
  • 0 in reply to alexey nalimov
    TI__Guru 68116 points
    Hi Alexey,

    I'm unsure if the mass erase command will send the ACK only after the erase is complete or not - if you add some delay before sending the password (after you send the mass erase) does that help (I can see in SLAU319 section on differences between bootloader versions it says that mass erase on this part for BSL will take 206.4ms on average so wait at least that long?)

    -Katie
  • 0 in reply to Katie Pier
    Prodigy 60 points
    Well, manual tells that it should ACK the mass erase only after erase completes, but I added now a delay before sending password - not helped.
    Also I removed the mass erase command at all (as the chip is expected to be clear already) - still password NACK.
  • 0 in reply to alexey nalimov
    Guru 58965 points
    The ROM BSL code inside MSP430 uses bit-banging (instead of real UART) to receive incoming bytes. And it tries to process the received byte in real time instead of buffering the byte to be processed later. While it is doing that, if the next byte starts coming in, it will screw up.

    In addition to a minimum delay of 1.2 msec before sending new characters after characters have been received from MSP430, you also need some delay between the bytes you send. Sending 2 stop bits might help (but may not be enough ;)
  • 0 in reply to old_cow_yellow
    Prodigy 60 points

    But it handled previous commands successfully - i.e. RX BSL Version and Mass erase, although they are 8 bytes instead of 42 bytes password command.

    2 stop bits are not working - MSP430 reports NACK even for version cmd. And it will take too much time rewriting my old serial stack for the master controller, so I will try to attach USB to serial adapter tomorrow.

  • 0 in reply to alexey nalimov
    Guru 58965 points
    I think the amount of time required for the MSP430 to process each byte of an incoming command varies depending on which command and which byte. You need to accommodate the worst case when you send bytes to it.
    May be the source code of the deprecated BSLDEMO can show us something. That code seem to work well.
  • 0 in reply to old_cow_yellow
    Prodigy 60 points
    Thank you for the idea. Finally I made it work (with java code tool and a usb/serial converter connected - it also controls the power supply for the controller), and also did several experiments before. But actually I have no idea how the result was reached, as I just changed the microcontroller based programmer to serial converter.

    Regarding the delays between bytes, these do not seem to be required. Original source for the programming tool offered by Katie has no delays, and finally the working combination of SW+HW has no delays also.

    So, thanks to everyone.

**Attention** This is a public forum