1
\$\begingroup\$

I have an MSP430F169 that I'm trying to program using the BSL protocol. I don't have a JTAG programmer. Unfortunately, the MSP430F169 responds with NAK (A0) even to the unprotected commands (except the sync):

Get version:

(sync)
DATA WRITE: 80
DATA READ: 90 (OK)

(get version)
DATA WRITE: 80 1E 04 04 00 00 00 00 7B E5
DATA READ: A0 (NAK)

Mass erase:

(sync)
DATA WRITE: 80
DATA READ: 90 (OK)

(mass erase)
DATA WRITE: 80 18 04 04 FE FF 06 A5 83 B9
DATA READ: A0 (NAK)

The MSP430F169 is supposed to come with BSL version 1.61 (according to SLAU319N, page 37), so the version command is supposed to work. In the web page https://e2e.ti.com/support/microcontrollers/msp430/f/166/t/468602 the author discusses a different issue but reports that his MSP430F169 responds to the version commands.

Regarding the mass erase, I saw in another page that despite the AL AH bytes being documented as don't care, they actually needed to be a valid flash address in some devices/BSL versions. So I've tried sending all of the 0x10000 AL AH combinations, but to no avail.

As far as I understand, the JTAG fuse doesn't affect the BSL, but I'm not sure about that. In any case, I don't expect that the two MSP430F169 boards I have to both have come with their JTAG fuses blown, as supposedly this isn't second hand equipment. Is there any other protection mechanism that could be affecting the BSL?

Any ideas on how to solve this issue?

Edit:

Here's a 'scope capture of the sync and mass erase command (no delay between bytes, to fit in the 'scope window). Everything looks fine to me and to the UART decoder:

Sync Mass erase command

\$\endgroup\$
  • \$\begingroup\$ If the BSL were disabled, it would not even reply with DATA_ACK/NAK. There is no obvious problem in what you've shown. Are you sure that you are sending the data frame correctly? \$\endgroup\$ – CL. Jul 17 '17 at 17:58
  • \$\begingroup\$ @CL. I'm using mspdebug and the bytes match what I've seen on some pages so I can't see how it could even be wrong :( \$\endgroup\$ – Luís Marques Jul 17 '17 at 18:01
  • \$\begingroup\$ A few things to check: is your baud rate 9600? Have you ensured that there is a minimum 1.2ms delay from sync to the actual command? \$\endgroup\$ – Tony K Jul 17 '17 at 18:06
  • \$\begingroup\$ Yes. I've even tried different delays \$\endgroup\$ – Luís Marques Jul 17 '17 at 18:07
  • \$\begingroup\$ Apparently you may need to delay between each byte rather than between commands, per e2e.ti.com/support/microcontrollers/msp430/f/166/t/468602 \$\endgroup\$ – Tony K Jul 17 '17 at 18:53
0
\$\begingroup\$

I recommend modifying your serial driver to add at least a 50 ms delay between transmitted bytes - longer is fine. These things do not have a real UART so they can be quite finicky.

Your format should be 1 stop bit, even parity.

The particular commands you show in your examples are password protected. Have you prefaced them with a 32x 0FFh RX password cmd?

\$\endgroup\$
  • \$\begingroup\$ I tried even longer delays, to no avail. According to SLAU319N, page 8, both Transmit BSL version and Mass erase are unprotected commands. (but I have tried also sending the RX password with 32 FFs, no difference) \$\endgroup\$ – Luís Marques Jul 20 '17 at 0:40
  • \$\begingroup\$ Did you get an ACK from your RX password command? \$\endgroup\$ – Glenn W9IQ Jul 20 '17 at 1:36
  • \$\begingroup\$ I got a NAK (A0) for the RX pwd command \$\endgroup\$ – Luís Marques Jul 20 '17 at 1:39
  • \$\begingroup\$ Have you tried a different header character? \$\endgroup\$ – Glenn W9IQ Jul 20 '17 at 1:48
  • \$\begingroup\$ Same result with a different header character \$\endgroup\$ – Luís Marques Jul 20 '17 at 1:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.