Digital Sensor I2C interface with RF430FRL152H?

Thank you Alexander for your immediate reply.
I will try to implement SensorHub_Project with sensorHub boosterpack. and will let you know if any difficulties may occur.

On the same topic of external sensors, as part of fault testing the interface to a humidity sensor, power to the i2c slave was disabled, causing the supporting routine coupled to DIGITAL_SENSOR1 to hang.

After some amount of time, the rf430frl152h reset, with ResetError in the Error Control Register set, and the power on logging of the reset condition from SYSRSTIV was set at 0x02, indicating a BOR.

Verifying the watchdog and timer registers prior to causing the hang did not seem to show them active. I'm assuming a software BOR is initiated if the sensor sampling routine takes too long, and am attempting to verify what that time out is set to in the ROM.

Thanks, Karl

In the ROM there is a Watchdog timeout option, however it does not trigger a BOR.  I don't recall any software BOR in ROM being used.
The report indicates that there was a power drop that caused the RF430FRL152H to reset.

Could the power disablement to the I2C slave affected the power to the whole system? 

Not certain.

Have replicated it with the device completely disconnected from the circuit (ground, power, scl/sda), to the point where no external circuitry is drawing on the rf430frl152h.

Also tried a busy loop while(1) at the start of the sensor data collection method and caused the same behavior, no I2C interaction at all.

If there's no software BOR in the ROM, then perhaps this interaction is causing an abnormal draw.

Karl

Only thing that comes to mind is if running the CPU for long periods of time is draining too much power, such as from battery and causing a brownout.
Would be useful to capture the VDDSW power rail on a scope with this issue.

Actually it would me more useful to capture the VDD2X power rail since that is the most sensitive power supply.

Seems as soon as it hits any sort of busy loop (whether it be the infinite loop, or the busy wait checking of flags in UCB0IFG), it will dip VDDSW down to almost 1V. That timing correlates with the restarts.

This is currently over RF power, which is the goal for this implementation, but does provide insight into the issue. 

Under normal conditions, it will typically only dip ~50mV during any sampling, keeping it well above 1.5V. 

Karl

In this case it would be wise to avoid polling loops. The digital sensor driver can be rewritten to use interrupts to communicate with the digital sensor. This would be very power efficient and should prevent a brownout if the communication hangs.

Agreed. Thanks for the help and insight.

Karl

A follow-up question along these lines. We have an RF430FRL152H driving a BME280 and MAX44009 without issue at  run time, powered by the RF field.

The BME280, however, has about 40 bytes of calibration data that are pulled in and stored once in FRAM on the RF430FRL152H, and during that process a behavior was noticed with a simple for loop.

In order to replicate this to a neutral platform, an RF430FRL152HEVM was modified to remove IC6, IC5, IC4, U4, IC1, R14, and R13. The RF430FRL152H is programmed with an external programmer or OTA and interfaced with a TI TMP75C. The device is RF field powered and power is supplied via VDDSW to the TMP75C along with a direct connection to SDA/SCL. Whether VDDSW or VDD2X or VDDH are used is not the issue, it's just in the case of the TMP75C it likes to have the IO lines at VDD or higher, so VDDSW works.

The default SensorHub firmware was modified in only three way:

1) The voltage doubler is enabled.

2) ISL29023_I2C_Read() is modified to address 0x0048 (TMP75C)

3) The following code is placed at DigitalSensorMeasurement() for DIGITAL_SENSOR1:

{
 u08_t cnt, cnt_addr;
 for(cnt = 0, cnt_addr = 0x00; cnt < 1; cnt++, cnt_addr++) {
   ISL29023_I2C_Read(cnt_addr, temp_data);
 }
}

The addition and use of a second variable causes the RF430FRL152H to hit a brown-out condition. The removal of a second variable in the loop and multiple iterations of the loop cause no issue. 

Monitoring VDDH, VDDSW, VDD2X, and VDDD show no dips at until all uniformly drop when reset. Voltages are all in expected ranges. 

Although this has been worked around currently by using only a single loop variable, we are just seeking any sort of explanation as to what might cause this behavior. The only notable difference in the disassembly is the use of an additional register. 

Any insight appreciated, as it will make us more effective when designing code for this part. 

Thanks, Karl

The ROM code has been compiled using IAR. What you are probably using is CCS. It has been known that there are differences between IAR and CCS in terms of function calling. Slight register transfer differences can break the code.

While I don't know if this is causing an issue in your case. I would recommend, if you could debug through this code, maybe without RF calls, and see what is really happening.

Difficult to do without RF, as that's the way the ROM code is being triggered. The device is acting as an I2C master already.

Some basic checkpoint debugging using FRAM shows that it does make it through the sensor sampling (at least once), although the scope traces of the I2C bus show that there are successes mixed with non-successes as it continues to reset itself.

From a JTAG perspective, I'm only able to disconnect and reconnect to the target, at which point it is always in the Reset ISR. Behavior when JTAG/Battery powered is different in that it succeeds in sampling the sensor on the I2C bus once, and then seems to freeze and become non-receptive to any RF activity.

Apologies if this is nebulous, but the behavior is somewhat unexpected.

Thanks, Karl

I believe the reset is occurring due to some errant processor operation.

To determine this, it is important to be able to single step through the code that you created.

The reason that RF and JTAG operation usually does not work is that the traces for these features intersect on the EVM and are interfering with each other. I would recommend that you try the following changes on the EVM to hopefully fix this problem.

This has not been verified by me, but it may work. The solution is to bypass the RF traces between JP1 and C4. The JTAG traces cross in this region.

There are two possible ways. First is to attach an external antenna to JP1 and remove resistors R27 and R31. If you have a second RF430FRL152H EVM then this can be used as the antenna (of course removing the same resistors there too). If you use a wire loop instead it will have to be tuned.

With this change you should be able to have RF and JTAG operation concurrent.

With this, check your map file for where your code is residing and set breakpoints there and debug.

I tuned a wire coil, and stepped through the bottom DigitalSensorMeasurement(). There's not much to step through after that: 

fa8c: 5321 INCD.W SP
fa8e: 4030 F890 BR #__mspabi_func_epilog_2

which steps into: 

__mspabi_func_epilog_2():

f890: 0000 .word 0x0000

and the disassembly is just left at: 

0000:   0000                .word   0x0000

Not sure if any of that is helpful, I definitely don't follow what's happened at this point. Also reproduced this behavior outside the EVM. 

Thanks, Karl

Karl,

What is happening is that the firmware is calling a function that is not defined. The __mspabi_func_epilog_2() is not defined in FRAM.

I am not sure why this is happening, maybe a project configuration or otherwise. You could try to open a post on the CCS compiler forum on this issue.

I am also giving you the option to send me your project and I can see if somehow the function can be made to be defined.

Sure I can send it over. It's just a standard sensorhub project with a few lines added. What's the best way to make it available? 

Karl

You can attach it to this forum in your post. Click on "Use rich formatting" text on the bottom right and find the "attach file" buttons there.

Also if you need to, you can send it to me in one of the friend requested E2E threads that you have.

Thanks, I've sent in a private message.

Karl

Karl,

So there is a bug with one of the CCS config files in the SensorHub project.  I am attaching the correct file and will work on updating the web version.

/cfs-file/__key/communityserver-discussions-components-files/667/lnk_5F00_rf430frl152h_5F00_Driver.zip

Replace the attached file lnk_rf430frl152h_Driver.cmd with the one in your project.

Awesome, thank you for the quick resolution. It's looking good now both on battery and RF power.

Karl