CCS/RF430FRL152H: some problems about debugging RF430FRL152H with CCS.

Hi Helfried,

Thanks for your reply. I have read that document. And it shows that the SD14, GPIO, watchdog, timer, and eUSCI functionality can be controlled by the user firmware in FRAM. Does it mean I can use eUSCI driver to drive a digital sensor in my function? For example, at the start of main(), I configure slave sensor's setting , and then sample data in a while() function. But I suppose that will reduce storage space in FRAM and couldn't use register to change sample setting like RF430FRL152H_SensorHub_Project or Default Project.

If I use Default Project to drive the digital sensor without those in demo, can I use register in FRAM to drive eUSCI in ROM for configuring digital sensor? It would be better if I can set digital sensor firstly and then start repeat operation which includes sampling and storing data. Those step will be accessed through NFC command, aren't they?

Third question is the entry points in .cmd file. I have compared .cmd file in SensorHub Project and NFC Project respectively. And I find that ROM_ISR and FRAM are different. The former indicates function used in ROM, the latter shows block set in FRAM. Could I change FRAM block configuration as long as FRAM + FRAM_CODE lengths must equall 0x768 (with FRAM starting at 0xF868)? And FRAM or FRAM_NDEF could be accessed by NFC, however FRAM_CODE should be protected, if this guess is true, how  can I set it?

Look forward to your reply.

Sincerely, 

Li. 

Hi Helfried,

Thanks for your reply. At first, I want to start my project with RF430FRL152H_SensorHub_Project. But it really kills me ,because without main(), function in RF430FRL152H_SensorHub_Project would be triggered through NFC command in my thought. It seems complex and I just wanna debug eUSCI to drive I2C right now. Well,if I operate two parts in the meantime, it would be difficult to me to find out reasons, when some unexpected problem happen.

Do I think that project too complex? Or if it's like what I thought, could you show me how to configure eUSCI through NFC?

Here is my function. I think the sent number consist of slave address and other data(register and command). Slave address is sent at first, So in for() sendNum - 1. 

WRITE

#pragma CODE_SECTION (I2C_Write, ".fram_driver_code") //see .cmd file for details - all new firmware must go into fram_driver_code memory section space
void _I2C_Write(u08_t * txData, u16_t sendNum)
{
u08_t tem_coun = 0;
UCB0CTL1 |= UCSWRST; // Software reset enabled
UCB0I2CSA = MAX86150_SLAVE_ADDRESS; // I2C slave address 
UCB0CTLW1 = UCASTP_1;
UCB0TBCNT = sendNum;
// UCBCTL1 &= ~UCSWRST; // exit eusci reset

UCB0CTL1 &= ~UCSWRST; // put eUSCI out of reset
UCB0CTL1 |= UCTXSTT + UCTR; // start i2c write operation
while(!(UCB0IFG & UCTXIFG0)); // send the I2C address

// UCB0TXBUF = command; // send the command
// while(!(UCB0IFG & UCTXIFG0)); // wait until the command is sent out
for(tem_coun = 0; tem_coun < (u08_t)sendNum - 1; tem_coun++) // because slave address has been sent out
{
UCB0TXBUF = txData[tem_coun]; // send the Register address and command
while(!(UCB0IFG & UCTXIFG0)); // wait until it has been transmitted
}
// UCB0TXBUF = rxData[1]; // send the MSB
// while (!(UCB0IFG & UCBCNTIFG)); // wait until it has been transmitted
UCB0CTL1 |= UCTXSTP; // send the stop condition
while (!(UCB0IFG & UCSTPIFG)); // wait until it has been received
UCB0CTL1 |= UCSWRST; // put the eUSCI into reset mode

return;
}

READ

#pragma CODE_SECTION (MAX86150_I2C_Read, ".fram_driver_code") //see .cmd file for details - all new firmware must go into fram_driver_code memory section space
void I2C_Read(u08_t * rwData, u16_t sendNum)
{
u08_t tem_coun = 0;
UCB0CTL1 |= UCSWRST; // Software reset enabled
UCB0I2CSA = MAX86150_SLAVE_ADDRESS; // I2C slave address 
UCB0CTLW1 = UCASTP_1;
UCB0TBCNT = sendNum;
// UCBCTL1 &= ~UCSWRST; // exit eusci reset

UCB0CTL1 &= ~UCSWRST; // put eUSCI out of reset mode
UCB0CTL1 |= UCTXSTT + UCTR; // start i2c write operation
while(!(UCB0IFG & UCTXIFG0)); // wait until transmit is needed
for(tem_coun = 0; tem_coun < (u08_t)sendNum - 1; tem_coun++)
{
UCB0TXBUF = rwData[tem_coun]; // send the Register address
while(!(UCB0IFG & UCBCNTIFG)); // wait until the stop counter
}

UCB0CTL1 &= ~UCTR; // read operation
UCB0CTL1 |= UCTXSTT; // repeated start

for(tem_coun = 0; tem_coun < 8; tem_coun++)
{
while(!(UCB0IFG & UCRXIFG0)); // wait until read data available
rwData[tem_coun] = UCB0RXBUF; // read the MSB
if(tem_coun == 7)
{
UCB0CTLW0 |= UCTXSTP; // send stop after next byte
}
}
// rwData[0] = UCB0RXBUF; // read the MSB
// UCB0CTLW0 |= UCTXSTP; // send stop after next byte
// while(!(UCB0IFG & UCRXIFG0)); // wait until read data available
// rxData[1] = UCB0RXBUF; // read the MSB
while (!(UCB0IFG & UCSTPIFG)); // Ensure stop condition got sent
UCB0CTL1 |= UCSWRST; // put I2C in reset mode

return;
}

In simple terms，how could I call  functions DigitalSensorInit() and DigitalSensorMeasurement()? If I know it, the the rest of the matter is debugging eUSCI driver.By the way, RF430FRL152H works as Master here.

Look forward to your reply.

Sincerely,

Li.

Hello Li,

can you explain in short how your application should work. This helps maybe to find the right software solution for it.

Does it operate from battery? Will you log data over a longer timeframe? Should the logging start without RF interaction?

Will you readout the logged data afterwards? etc....

Best regards,

Helfried

Hi Helfried:

Thanks for your reply. In general, my solution needs RF transmission, however, digital sensor configuration in that is a little complex. So I want to finish register configuration before sample process.

And now, I have known void DigitalSensorInit() will be processed during initialization, only once. It's pretty good to configure register in that function. But sensor initialization function written by myself seems not work very well.

Here is the function(just one register configuration example):

u08_t buf[] = {SYSTEM_CTRL_REG,SYSTEM_RESET};
//reset sensor
I2C_Write(buf, 0x0003);

void I2C_Write(u08_t * txData, u16_t sendNum)
{
u08_t tem_coun = 0;
UCB0CTL1 |= UCSWRST; // Software reset enabled
UCB0I2CSA = SLAVE_ADDRESS; // I2C slave address
UCB0CTLW1 = UCASTP_1;
UCB0TBCNT = sendNum;
// UCBCTL1 &= ~UCSWRST; // exit eusci reset

UCB0CTL1 &= ~UCSWRST; // put eUSCI out of reset
UCB0CTL1 |= UCTXSTT + UCTR; // start i2c write operation
while(!(UCB0IFG & UCTXIFG0)); // send the I2C address

// UCB0TXBUF = command; // send the command
// while(!(UCB0IFG & UCTXIFG0)); // wait until the command is sent out
for(tem_coun = 0; tem_coun < (u08_t)sendNum - 1; tem_coun++) // because slave address has been sent out
{
UCB0TXBUF = txData[tem_coun]; // send the Register address and command
while(!(UCB0IFG & UCTXIFG0)); // wait until it has been transmitted
}
// UCB0TXBUF = rxData[1]; // send the MSB
// while (!(UCB0IFG & UCBCNTIFG)); // wait until it has been transmitted
UCB0CTL1 |= UCTXSTP; // send the stop condition
while (!(UCB0IFG & UCSTPIFG)); // wait until it has been received
UCB0CTL1 |= UCSWRST; // put the eUSCI into reset mode

return;
}

 I have seen Enhanced Universal Serial Communication Interface(eUSCI) – I2C Mode in slau506, and haven't figured out error reason.Could you show me the key problem?

Look forward to your reply.

Sincerely, 

Li.

Hi Helfried,

Now I'm trying to put initialization function in DigitalSensorMeasurement () with a flag which makes sure setting register at first sample rather than sampling data. However, when I send 0x00700001 to block 0(block 4 mode), nothing happened. Command is sent by a custom ISO15693 reader.

Did I make some mistakes?

Look forward to your reply.

Sincerely,

Li.

Hi Helfried,

Well, I could communicate digital sensor now. The reason of error is pull_up resistance which is set too high. And sensor configuration is set during  the first sample  in DigitalSensorMeasurement ().

And I find log memory space in datasheet is different from that in RF430FRL152H_SensorHub_Project  which even include register. Could you give me some advice?

Look forward to your reply.

Sincerely,

Li.