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: Over The Air Updates and Timer A0 Usage

Part Number: RF430FRL152H
Other Parts Discussed in Thread: MSP-FET

Tool/software:

Hello,

I have an application where I would like to update a low power electrochromic e-paper 7 segment display with the GPIOs on the RF430FRL152H when appropriate NFC Type V commands are sent to the device from a host smartphone. I had success creating custom commands using the patch table and programming that over the air. However, I have a need to do delays for timing when interfacing with the display and using __delay_cycles would consume too much of my very limited power budget while also driving a GPIO to turn on a segment of the display. I'm also not sure if the custom commands called by the RF stack are running in an ISR context and such delays would be a bad idea? I would like to be able to use Timer A0 to put the CPU in LPM3 while delaying to minimize power consumption. It's not clear to me if that is possible to do when using patched commands or if I would have to create my own custom main() function. If I had to create my own custom main() function and point the reset ISR to that, could that only be programmed with a programmer or could that be programmed over the air?

Thank you,

Nick

  • Hi Nick,

    I would like to be able to use Timer A0 to put the CPU in LPM3 while delaying to minimize power consumption. It's not clear to me if that is possible to do when using patched commands or if I would have to create my own custom main() function.

    I'm not really an expert in this device but I suppose you want to use the timer0 timeout to create the desired delay, correct? I also think you are using the Default Operation mode, correct? See below.

    In the Default Operation mode, both the RF Stack and sensor support are enabled. If you are in this mode, you can write to the Virtual Registers in FRAM to enable timer module via either RF or SPI interface. 

    Once the timer interrupts, you can service the interrupt in TimerA0_ISR. See below example.

  • Hi Charles,

    Ya I was trying to use the default operation mode. In that project you referenced there is a comment above the ISRs:

    // ********************************************************
    // It is not recommended to change anything below this line
    // The ROM code needs the below ISRs to be kept as they are
    // ********************************************************

    There is a different project, main.c in the NFC Projects folder that has a standalone main loop and replacing any of the ISRs except the RF one seems fine. I wasn't able to program that over the air and wasn't sure if it wasn't being allowed due to some protected memory regions or something went wrong with the programmer.

  • Hi Nick,

    There is a different project, main.c in the NFC Projects folder that has a standalone main loop and replacing any of the ISRs except the RF one seems fine.

      Are you referring to the RF430FRL152H_NFC_Only_Project_NDEF_Support? This example disable ROM support for Sensors. Refer to this line of code in NDEF.c file.  This example frees the FRAM that was occupied by the Virtual Register in the default mode to be used for NDEF messages. I think you can reference this example to add your Timer0 functionality. 

    volatile const u08_t Firmware_System_Control_Byte = ROM_SENSOR_SUPPORT_DISABLED + EROM_EUSCI_SUPPORT_DISABLED + NFC_BRIDGE_DISABLED + FOUR_BYTE_BLOCK + FIRST_ISO_PAGE; //0x7F, // this value sets the firmware system control register

  • Thanks Charles, I was able to program the demo project over the air using an open source android application GoodV but it seems now the tag is not responding to any NFC stuff. Perhaps there was an issue with the programming as I expected the NFC ISR would still run and respond to commands but not sure if that is the case. I would like to get a programmer / debugger that works with the RF430FRL152H so I can investigate further but the only thing I see mentioned in the FAQ is the MSP-TS430L092 and that doesn't seem to be available / supported anymore.

  • Hi Nick,

    I would like to get a programmer / debugger that works with the RF430FRL152H so I can investigate further

      Please refer to Frequently asked questions for RF430FRL15xH devices (Rev. C). You can use MSP-FET debug probe to program/debug the device. 

  • Thanks Charles! One thing that's a little confusing to me is that the RF430FRL152H datasheet says the supply voltage range is 1.45V - 1.65V and the MSP-FET page says it has a software configurable supply range between 1.8 V and 3.6 V. It sounds like the power would have to be supplied externally based on the MSP Debuggers user guide which is a bummer because I guess the Energy Trace features couldn't be used.

  • Hi,

    Please refer to this post answered by Ryan Brown. You can use MSP-FET to provide power to your target board via pin 2 on the JTAG connector and adjust the power output in CCS. 

    https://e2e.ti.com/support/microcontrollers/msp-low-power-microcontrollers-group/msp430/f/msp-low-power-microcontroller-forum/579419/ccs-msp-fet-how-to-adjust-supply-voltage

    The MSP-FET provides 3.3V from JTAG pin 2 by default, it can be changed during a CCS debugger session by altering the Target Voltage settings under Tools → Debugger Options → MSP43x Debugger Options (MSP430). It can also be changed during an editting session through Project → Properties → Debug → MSP430 Properties → Target Voltage.