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.

WEBENCH® Tools/MSP430F5529: Difference between 2 silicon version

Part Number: MSP430F5529
Other Parts Discussed in Thread: MSPBSL,

Tool/software: WEBENCH® Design Tools

Hello,

Till now we produced ~2000 boards based on REV-F of the MCU.

Few days ago we stsrted getting REV-K.

The print on the chip was:

24A0T4TCH

M430F5529

Rev F

and now:

69A9Y1TGH

M430F5529

Rev K

It seems that Rev K fails to boot in BSL mode. 

BSL mode is required to burn the application on the flash. 

Can you please help ?

Thank you,

Zvika 

  • Maybe it is not related to silicon, but to factory preloaded USB BSL version. Try to replace BSL on rev K, with older one from revision F.

  • Hello,

    Both silicon versions are burned with the same BSL. It is a customized BSL burned by me.
    Upon boot, BSL checks for a patten in a specified flash address.
    If pattern exists, MCU stays in BSL and does not jump to application.

    Thank you,
    Zvika
  • Zvika,

    There are several errata fixes to the chip between revision F to revision K. I would check these errata differences to see if your custom BSL would get hung up some how. You could have a situation where your previous code was expecting an action or workaround to happen that does not get executed in HW on newer part as it is a newer revision.

    All I can suggest beyond the above is to load the factory BSL to ensure proper operation. Afterwards, a debug of your custom BSL is needed.
  • Dear Team,

    We've looked it up on the errata at http://www.ti.com/lit/er/slaz314w/slaz314w.pdf

    and it seems like the BLS7 can't work with revision K of the silicon.

    Can you advise why this change has been implementable ?

    Can you also advise any method of running the BSL the customer uses with older revisions on the new silicon without upgrading this ?

    Best regards,

    Nir.

  • Nir,

    BSL7 caused the BSL not to start if you were waking up form LPMx.5. This was due tot he fact that LPMx.5 locks the I/Os into their state before entering the mode (Lock I/O Bit does this). Upon normal reset, this bit is cleared, but BSLs until revision K did not clear this bit. Revision K added additional code within the BSL to make sure this bit was cleared so the BSL can start up properly. This particular errata should not affect functionality as the workaround was to not use the Lock I/O bit. Also, this errata doesn't apply if you are not using LPMx.5

    Furthermore, the customer has stated they use a Custom BSL. In that case, our BSL errata would not directly be related to the issue as they have replaced our BSL with their own. The only relevant BSL errata would be ones that the custom BSL is based off of. I would concentrate more on the USB errata if they are using the USB BSL interface or USCI errata if they switched to a UART/I2C based BSL.
  • Hello,

    Where can I find the original BSL code used in Rev. K ?
    On this version I want to do my minor changes and check.
    This modified BSL will be checked also on Rev. F

    Thank you,
    Zvika
  • Zvi,

    BSL source good as well as the last two BSL images for devices can be found within the Custom BSL SW download. the Source code is only available for the latest version of the BSL which may not directly correlate with the latest version on the particular you are looking at. this is due to the fact that the BSL is maintained and updated across devices, and only gets updated in devices when a new revision happens. Please download the CUSTOM-BSL430 download on the MSPBSL webpage.
    http:/.../MSPBSL
  • Dear Jace,

    This project is running for 7 years already with the custom BSL.
    Implementing the same change on the new BSL will require a lot of resources not available at the moment.
    Is there any possibility to purchase the previous silicon of the device ?

    Regards,
    Nir.
  • Nir,

    Unfortunately, there is no way to purchase older revision silicon or any specific revision particularly. Our supply chain including distributors do not track shipments in regard to their revision. For older silicon, what is out within the distribution channel is all there is as only the newest revision is coming form TI factories.
  • Hello,

    I investigated the problem.

    Revision K can work with the old BSL. 

    The only difference I can see in this project:

    During the product's ATP the MSP is reset using pin 76 (global reset). 

    With rev. F, the reset works. But not with rev. K. 

    In F, K I completely erased the BSL. Then I ran a simple program that sets a GPIO pin to '1'

    With rev. F, the reset set the GPIO to '0'. 

    With rev. K, the reset did not change the GPIO. 

    Thank you,

    Zvika 

  • Hello Zvika,

    For the Reset, was the pulse meet the minimum spec of 2 us?
    How do you check the state of the pin? By looking at the registers or just measuring voltage on the pin?
    When does the test occur, right when you start the part or after a steady state?
    Is there any external components on the pin?
    Which pin are you testing?
    In your test, did you use any LPMs?

    When a reset occurs, the GPIO IN and OUT register will be undefined and may reflect residual voltage. The DIR register will set the pins to an input, and the other port registers are set to '0h' which means pins are in GPIO state, no pull up/downs.
  • Hello,

    Attached a code I compiled with CCS 4.1.2

    It sets a GPIO to '0' which turns on a LED.

    In my scenario, the RESET signal applied is not a pulse. 

    I set the RESET to '0' for a very long time (e.g 10 seconds).

    In the 'F' revision, applying RESET turns off the LED. This is what happens when I click 'RESET' in the CCS IDE (the chip icon) 

    In the  'K' revisoin the RESET does not turn off the LED. 

    Thank you,

    Zvika 


    #include <msp430f5529.h>
    
    void main(void)
    {
    	P1DIR |= 0xF; 						// Set P1_0,P1_1,P1_2,P1_3 direction to out (LED)  
    	P1OUT |= 0xF;						// Turn off P1_0,P1_1,P1_2,P1_3
    	
      	//Turn on P1_4	
    	P1OUT &= 0x7;
                
    	while (1);
    }
    
    
    

  • Hello Zvika,

    A few things. The above code will not mess with P1.4 as you have in your comments. this will result in P1.3 being turned off. I assume here that the comment above that line is typo'd.

    Second, I am unable to reproduce your behavior. I am testing on a MSP430F5529 Launchpad that has REV K on the board. I P1.3 jumper ed to the LED1. The behavior is as expected as the code is written even through resets caused by the IDE and by the RESET button on the board. The LED momentarily flashes as it is turned on by your second line, then turns off by your third line. There is also no errata difference between the two revisions that would effect this code.

    Can you share the portion of the schematic for your Port 1? Can you attempt this with the newest version of CCS?
  • Hello,

    I installed the MSP430 (Rev K) on the evaluation board and ran the code.

    The code turns on the LED on the EVB. 

    Then I disconnected the JTAG connector and pressed the RED reset button.

    The LED did not turn off.

    Is this the scenario you tried  ?

    Thank you,

    Zvika 

  • Hello Zvika,

    As stated before I tested this on the MSP430F5529 Launchpad which has Rev K on it. I have also tried it wiht the MSO-TS430PN80USB Target board and do not see the issue. Please know, that I tested the target board by pulling power to the board as the board does not have a RESET button. It does have one button, S3, that is red, but it is not a Reset button. This button is used to pull the PUR line high when powering the device in order to invoke the USB BSL.

  • Hello Jace,

    You are absolutely right !

    The cause to the problem was in the PCB on which the MSP430 was assembled, not the difference between K and F. 

    Thank you very much,

    Zvika 

**Attention** This is a public forum