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.

RF430CL331H: RF430CL331H

Part Number: RF430CL331H
Other Parts Discussed in Thread: RF430CL330H

I have attached a RF430CL331H to a MSP430F5529LP and run the load "RF430CL331H_On_BoosterPack_Host_5529" with no problems.

I then attached the RF430CL331H to a MSP432P401R and  migrated the load by altering the respective GPIO ... ie. F5529 INTO P3.2 to 432 P5.2 etc. and cannot get a card reader (android phone) to activate the INTO interrupt..

What I have found is that I can manually drive the INTO by manually grounding P5.2 and the logic works as expected with reading the INT_FLAG_REG by I2C giving a value of 0.  However, if I pass a card reader (android phone) over the 331 there is no noticeable effect but when I then manually drive the INTO again the next read on the card via the I2C locks up.  So, its apparent the card reader is influencing the 331 but I am at a dead end.  Any suggestions as to what I can do to progress this project.

thanks Dave

  • There is a typo in the description (incorrect F5529 gpio pin)  ... it should be ie. F5529 INTO P2.3 to 432 P5.2 etc.

  • Hello David,

    to better help you, we would need more information.
    Is it possible for you to scope the I2C lines so we can see the communication between MCU and RF430CL331H ?

    Can you compare the I2C communication between your two setups with the MSP430F5529LP and the MSP432P401R to see if there are any differences.

    Best regards,
    Helfried
  • Helfried,

    Here is an update.  If I comment out the 2nd line of the fix then a phone will energize the 331 and the INTO interrupt is generated.  The result of the INT_FLAG_REG is 0x20 (32) which is DATA_TRANSACTION_INT_ENABLE and according to the documentation (SLASE18A –SEPTEMBER 2015–REVISED NOVEMBER 2015)  indicates there is a pending IRQ.  I'm trying to work out where I go from here but it would be nice to know why commenting out writing 0x80 to the control register results in the INTO being generated on the MSP432P401R whereas on the MSP430F5529LP the code works flawlessly with the code left unchanged..

    Write_Register(0xFFE0, 0x004E);
    // Write_Register(0xFFFE, 0x0080);
    Write_Continuous (0x2AD0, (uint8_t *) &errata_fixes, sizeof(errata_fixes)); //write the patch to memory
    Write_Register(0x2A90, 0x2AFC); // looping fix
    Write_Register(0x2AAE, 0x2AD0); // wait time extension fix
    Write_Register(0x2A66, 0x0000); // fix by init
    Write_Register(0xFFE0, 0x004E);

    regards,

    Dave

  • Hello Dave,

    a question about the line you have commented out.
    When I look into the datasheets register description for the control register 0xFFFE, is see bit 7 is describe as reserved.
    In this case this would be an illegal register value.

    Best regards,
    Helfried
  • Helfried,

    Thanks for the response.  However, the line I am referring to is something TI engineers put into the example for the RF430CL331H that is in sloc330.  If you look at the solution there are a bunch of fixes the TI team put in for the card to work, so you need to consult the RF430CL331H development team as to why they did this and why I need to comment it out for the MSP432.  All I want to do is run the RF430CL331H on the MSP432P401R launchpad.

    regards,

    Dave

  • Dave,

    yes, you are right . I missed that one. This is part of a firmware patch which is explained in the RF430CL331H errata sheet.
    But if you comment out this line the complete patch is not working. It is the enable for a test mode which is in the datasheet marked as reserved.
    Why not implementing the patch solves your problem is unclear. Because this patch is implemented to solve problems like this.

    Have you checked the INTO input in the MSP432P401R in case of needed pullup / pulldown resistors ?

    Best regards,
    Helfried
  • Helfried,

    Thanks again.  Are you saying I need to add a hardware pullup/pulldown resistor for the INTO?  If so where do I find the details?

    Here is how I setup the INTO which works as I see the start of the data transfer

    //configure pin for INTO interrupts
    MAP_GPIO_setAsInputPin (INTO_PORT, INTO_PIN);
    MAP_GPIO_setAsInputPinWithPullUpResistor (INTO_PORT, INTO_PIN);
    MAP_GPIO_clearInterruptFlag (INTO_PORT, INTO_PIN);
    MAP_GPIO_interruptEdgeSelect (INTO_PORT, INTO_PIN, GPIO_HIGH_TO_LOW_TRANSITION);
    GPIO_registerInterrupt(GPIO_PORT_P5, PORTP52_ISR);

    where

    #define INTO_PORT GPIO_PORT_P5
    #define INTO_PIN GPIO_PIN2

    thanks

    Dave

  • Helfried,

    On a hunch we added a pullup resistor to the INTO but it didn't do anything. Is it possible you can get the engineers to plug a RF430CL331H boosterpack onto a MSP432P401R launchpad and get it working and send me the source code they are using. I'm dead in the water here.

    thanks
    Dave
  • Hello Dave,

    I don't have these boards on hand.
    What I did is a check with the RF430CL330H Booster-Pack together with the EXP430G2 Launchpad and used the firmware example SLOC303.
    The same problem occurred that I could not see any change on the INTO line.

    A check of the datasheet, the register description of the Control Register, showed that in my opinion bit 4 should be "0" instead of "1".
    If bit 4 is "1" an external pulldown would be required, but the firmware set the INTO input with an internal pullup.

    Please check the configuration of bit 3 and bit 4 of the Control Register. In your code you have also set an internal pullup.

    Best regards,
    Helfried
  • Helfried,

    I will follow your suggestion and check and play around with the Control Register.  However, I have not had any issues on running the RF430CL330H on either the MSP430 or MSP432 lauchpads.  My only issue is running the  MSP430331H on the MSP432P401R.  Is it possible you can get an engineer at TI to plug a MSP430331H boosterpack onto a MSP432P401R launchpad to see if they can get it to work.

    regards,

    Dave

  • Hello David,

    Helfried had raised this request to me, but at this point we are not doing any new development of software for the RF430CL331H (a device which has been out now for over 3 years), and porting it to another MCU is not a task we'll take on from our end.

    If you can share I2C captures we can probably determine what is going wrong.