• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 79 subscribers
  • Views 721 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.

MSP430F5253: Trouble with GetDevice() function from slau320ac

Martin Grani
Prodigy 60 points
Part Number: MSP430F5253
Other Parts Discussed in Thread: MSP430F5172, MSP-GANG

Hello.

I'm trying to program MSP430F5253 with a beaglebone black. I've "ported" the code from the associated files referred to from slau320ac.

When i run "SyncJtag_AssertPor" i get the JTAG ID, but the sync always fails. The example code does 50 tries, but doesn't matter if its 3000 it still won't give me any confirmation that the device is in "JTAG mode + read". 

I've checked that the macros are working as they should with a logic analyzer, and any IR commands always returns the jtag-id so the communication must be working. 

I've also tried to program it with MSPDEBUG () but I've found it they don't support F5xx and F6xx families. But under the fusecheck it returned 0x5555, which i haven't managed to reproduce with my program, even though the signals looks exactly the same. 

Does anybody have any experience with programming through the JTAG that could help me?

  • 0
    Guru 33653 points

    AFAIK, MSP Debug support all MSP430 families. Returned 0x5555 is related to blown fuse on target device, not to unsupported device. Beside slau320, maybe this can help...

    https://forum.43oh.com/topic/10035-4-wire-jtag-with-mspdebug-and-raspberry-pi-gpio/

    http://zacklalanne.me/automated-deployment-of-msp430-firmware-part-1/

  • 0 in reply to zrno soli
    Prodigy 60 points

    Thanks for reply.

    Yes 0x5555 means fuse is blown, but I'm very certain that it isn't. When i do the same check with the replicator software it does not give me 0x5555 back even though the signals look identical. They do differ in speed though. 

    It's to my understanding that MSPDEBUG uses the "old" way programming the memory (not using the JTAG mailbox). This method is only referenced to the F1xx, F2xx, F3xx and F4xx devices in slau320ac. The method to program F5xx and F6xx described in slau320ac loads a program in RAM to utillize the JTAG mailbox to program itself (atleast thats how i interpret it).

    But if the "old" method still works with F5xx devices i don't mind using it. Would be cool if someone could confirm that it works?

    I believe that the entry sequence patch from the first forum thread is already implemented in MSPDEBUG. And since I do receive the JTAG ID with the IRShift(0x14) the entry must have been succesfull?

    EDIT: Added signals

    https://www.dropbox.com/sh/mvseyuc9jqrazqs/AAAl8ctyOo0a_DVE_XR-vLrua?dl=0

  • 0 in reply to Martin Grani
    Guru 33653 points

    Martin Grani said:
    It's to my understanding that MSPDEBUG uses the "old" way programming the memory (not using the JTAG mailbox). This method is only referenced to the F1xx, F2xx, F3xx and F4xx devices in slau320ac. The method to program F5xx and F6xx described in slau320ac loads a program in RAM to utillize the JTAG mailbox to program itself (atleast thats how i interpret it).

    But if the "old" method still works with F5xx devices i don't mind using it. Would be cool if someone could confirm that it works?

    "old" method without using mailbox system working for all MSP430 devices (5xx / 6xx included). Returning valid JTAG ID does not prove that SBW / JTAG functions / interface is working fine. It doesn't meant that your data (16-bit) shifting working correctly. Even everything is done right, SBW / JTAG communication with target device can fail (not able to synchronize) even correct JTAG ID was returned.

    You can read core id (COREIP_ID) after fuse check (without synchronization) just to check if data shifting (16-bit) function is working correctly. However I don't know correct core id for your device, but know for some other from 5xx families, if you maybe have to compare.

    Get Device
# JTID Fuse Device Core Hard Soft LotWafer DieX DieY
1  91   OK   3080  1104  30   10  B15B9446 2000 1700
2  91   OK   3081  2106  10   10  B7A50951 0A00 1100
3  91   OK   3180  1104  12   12  013BB046 0D00 1E00
4  91   OK   3881  1106  10   10  219CA446 1800 0F00
5  91   OK   5435  0100  10   10  ADE98146 0400 2000

    Non-blown fuse result that I am receiving from MSP430F5172 (8 times) is 0001 0081 0081 0081 0081 8001 8081 8081 

    Sorry, I don't have free time to analyze signals.

  • 0 in reply to zrno soli
    Prodigy 60 points
    Thanks for reply!

    Then i guess i can use MSPDEBUG for MSP430F5253. I will check the coreip_id tomorrow to see if its somethings off with the DRShift.
    But since the MSPDEBUG does return a 0x5555 when DRShift(0xAAAA) is it fairly certain that the JTAG fuse is blown? It can not "mistakenly" give me that value?


    Thanks for the help!
  • 0 in reply to Martin Grani
    Guru 33653 points

    For example, here is GetDevice internal log  for my (MSP-GANG like) flasher. There are 4 connected devices. For 2xx, function after device id, will 8 times check fuse value, and try to do synchronization. For 5xx, function after device id, will 8 times check fuse value, get core id, and try to do synchronization. If synchronization is not done, after 8 retries, there will be error reported. But as you can see, synchronization for all connected devices is done with only one try. 

    -------- GetDevice --------
#0 0000000000010000 00000001 89
Fuse 2481 2481 2481 2481 2481 2481 2481 2481
Sync 2681
#1 0000000000100000 00000010 91
Fuse C121 C121 C121 C121 C121 C121 C121 C121
Core 1104
Sync D321
#2 0000000001000000 00000100 98
Fuse 0081 8001 0081 0081 0001 4081 4081 4001
Core 0906
Sync D201
#3 0000000010000000 00001000 99
Fuse 0081 0081 0081 0081 0081 0081 0081 0081
Core 1106
Sync D301
#4 0010000000000000 00010000 FF !
#5 0100000000000000 00100000 FF !
#6 1000000000000000 01000000 FF !
#7 0000000100000000 10000000 FF !
Dev 00001111 D89 00000001 D91 00000010 D98 00000100 D99 00001000
  • 0 in reply to zrno soli
    Prodigy 60 points
    Hello.

    Turns out my code was correct, but the execution was too slow. With a bit more speed we're able to program and read from the memory.

**Attention** This is a public forum