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.

RF430FRL152H: The reset vector change

Part Number: RF430FRL152H
Other Parts Discussed in Thread: TRF7960, ADS1018, , MSP430FR5972

Hello

I have a problem . the chip stop working quite often. then i used emulator to read memory. I found reset vector changed to like 0x0080 , 0x1250, it's random. I have a 20KW high power device beside this chip. no problem if it's off. I think this is interference problem  cause memory corrupted. I searched there are few kind of this problem in this forum.I tried their way. still can not solve the problem. why only reset vector changed?

  • Hello MaLin,

    It could potentially be an interference problem, but we haven't seen that before so let's take a step back and first if you could share your schematic I can review it for any possible hardware problems.

    Also, are you ever communicating with the device when the reset vector change happens, or does it occur randomly without an RF reader being present?
  • Hello Ralph,

    It always communicates with TRF7960 chip when i test it. I attached my circuit diagram. pls help to check it. and also part of progarm is below.

    void main()
    {
        

        WDTCTL = WDTPW + WDTHOLD;                   // Stop watchdog

        // ROM RF13M module setup ** The following three lines are needed for proper RF stack operation
        DS = 1;                                     // ROM variable needs to be initialized here
        asm ( " CALL #0x5CDA ");                     // Call ROM function ( Initialize function pointers)
        asm ( " CALL #0x5CAC ");                     // Call ROM function ( Check part configuration)



        RFPMMCTL0 = PMMPW;                                    //Unlock RFPMM
        RFPMMCTL0_L |= RFPMM_EN_V_DOUB;                          //Enable the VDD Doubler
        RFPMMCTL0_H |= 0xFF;                                    //Lock RFPMM
        
        NFC_Buff[0]=0;
        NFC_Buff[1] =0;
        NFC_Buff[2] =0;
        NFC_Buff[3] =VERSION;
        
        
        RF13MCTL |= RF13MTXEN + RF13MRXEN + RF13MRFTOEN;     // set up rx and tx functionality on RF13M module
        // enable interrupts  ** Do not change the following two lines, needed for proper RF stack operatoin
        RF13MINT |= RF13MRXIE + RX13MRFTOIE;              // enable interrupts on RX and on timeout and over and under flow checking
     
     

        //initISO15693(CLEAR_BLOCK_LOCKS);//clear protection
        
        memset ((u08_t *) FRAM_LOCK_BLOCKS, 0x00, 36);        //lock NDEF area
        FRAMAccessLimit_Byte = 0xF8D0;

        

        DeviceInit();


        //Setup ADC
        //SD14CTL0 = SD14EN + VIRTGND + SD14IE; //ADC enabled, Virtual Ground enabled, Interrupt enabled.
        //SD14CTL1 = SD14UNI + SD14INTDLY0;     // Unipolar mode, Interrupt triggered after first sample.

        __bis_SR_register(GIE);
        
        //Read ambient Temperature
        Write_to_ADS1018(1);//read ambient
       
         tempi=Read_Fr_ADS1018(1);
         AmbientTemp=tempi;
        Write_to_ADS1018(0);//read TC
        TA0CTL |= MC_1;//Start Timer
        while(1)
        {
            // SD14CTL0 |= SD14SC; //begin conversion
            __bis_SR_register(LPM3_bits + GIE);
        }
    }

    sensor board.pdf

  • Hello MaLin,

    Great, thank you for the schematic. Your post definitely reminded me of a previous one where the VDDSW capacitor wasn't our recommended value and had the same behavior. This could be what you are seeing here. The recommended value for VDDSW is 2.2uF. Can you please try to change that capacitor and see if the behavior goes away?

    For reference, the prior issue was posted on E2E as well: e2e.ti.com/.../2303394

    Please report back if the change works, because when this first came up I suspected that the cap used was too small, but if changing a 4.7uF to a 2.2uF solves the issue for you then it will be important to know it needs to be that exact value for proper functionality.
  • Hello Ralph,

    Still same after i replaced 4.7uf to 2.2uF.

  • Hello MaLin,

    Hmm I see, okay thanks for trying that out first and foremost. Revisiting your prior post,

    MaLin said:
    It always communicates with TRF7960 chip when i test it.

    Right, I understand that, but more what I am trying to figure out is, is the TRF7960 sending and receiving data to/from the RF430FRL152H when communication suddenly stops, or is it a situation where when the TRF7960 attempts to talk with it, the device is suddenly unresponsive.

    Basically, I am trying to gauge if there is any risk that the FRAM stored vector tables may have gotten overwritten on accident.

  • Hello Ralph,

    We changed C5 which is for VDDH to 4.7uF from 100nF.  The problem doesn't happen again. I cannot sure it solved problem absolutely. but it did improve. I think the antenna picked noise cause memory power supply problem or  there is program protection  in ROM over write reset vector.

  • Hello MaLin,

    Thanks for the update, that sounds like a reasonable solution to me, as long as the device looks to be working fine and the problem is resolved I see no issue with that modification. Thank you for sharing your current solution.

  • HI MaLin, Ralph  

    I have the same problem on the Msp430FR5972, this happens because the Fram are in effect like ram and is not protect 

    by writing in the flash section, so is possible to read and write at any time all  memory size like a ram. 

    I didn't check the item RE430FRl152h memory but if is FRAM may be is the same. 

    Luigi