CC2530 Possible Hardware (MCU) Bug

Sjef de Krijger

Hi all,

I spent this morning chasing a very elusive bug that appeared to be in my key reading routine. It's a very simple polling routine that reads P0_1 which is connected to a pushbutton on my custom board. The problem is that no matter what, P0_1 always reads 1.

After a few hours I traced the bug down to the use of the internal temperature sensor in my ADC routine. In its initialisation I do:

TR0 = 0x01; // temp sensor connect to ch 14
ATEST = 0x01;

And this causes the P0_1 input to be read as 0 at no matter what the voltage on the pin actually is (the pin still is in input mode i.e. high impedance).Comment these two statements out, P0_1 is ok. So I have to conclude that somehow enabling the temperature sensor in this way has an effect on P0_1 so that it can't be used as an input anymore. I've read other posts on this forum where the above sequence was supposed to solve this problem, but it clearly does not.

I would be very interested in knowing whether someone else on this forum, or TI is aware of this and knows any workaround.

Regards,

Sjef.

over 12 years ago

Igor Sherer over 12 years ago

Guru 31280 points

Hey,

Welcome to the "this information is not mentioned in datasheet or the user's guide" section. :)

Read this thread.

Besides when one of these pins configured to have an interrupt it is a good idea to disable

the interrupt on P0.0 and P0.1 during the measurement of temperature (enabling temperature sensor),

and re-enabling the interrupt when the measurement is finished (do not forget to clear P0.0 and P0.1

Interrupt flags prior re-enabling the interrupts).

Attached is an example code (i'm using it in my projects when measuring temperature and there are

interrupts allocated to P0.0 and/or P0.1)

Fullscreen 3301.TR0_Workaround.c Download

/* TR0 workaround */
intDisable(PORT_0, P0_0_P0_1_MASK);	/* P0IEN &= ~P0_0_P0_1_MASK */
for(i=0; i<NUM_OF_SAMPLES; i++ ) {
	TR0 |= 0x01;	/*  TR0 must be modified prior to ATEST, */
	ATEST |= 0x01;	/* 	otherwise P0_0 and P0_1 forced with 0 */
	temperature += HalAdcRead(HAL_ADC_CHN_TEMP, HAL_ADC_RESOLUTION_12);
}
TR0 &= ~0x01;
ATEST &= ~0x01;

/* TR0 workaround.
 * Assuming that intState holds the information whether P0_0 and/or P0_1
 * interrupt should be re-enabled
 */
if( intState & P0_0_INT_MASK )
	P0IFG = ~P0_0_INT_MASK;
	intEnable(PORT_0, P0_0_INT_MASK);
}
if( intState & P0_1_INT_MASK )
	P0IFG = ~P0_1_INT_MASK;
	intEnable(PORT_0, P0_1_INT_MASK);
}

Sjef de Krijger over 12 years ago in reply to Igor Sherer

Expert 1405 points

Igor,

The thread you mention is the one I read before. But setting TR0 before ATEST as mentioned in the thread's answer does not solve the problem - P0_1 is still read as zero during the time that the temperature sensor is connected. In other words, it does not have effect.

In my project I'm not using interrupts, but as a workaround I'm now not polling the pin during the ADC conversion. It's kind of ugly but it works.

Regards,

Sjef.

Igor Sherer over 12 years ago in reply to Sjef de Krijger

Guru 31280 points

Hi,

I wasn't sure about the thread, just wanted you to read it.

You are right, during temperature measurement the P0_0 and P0_1 read as zero (caught

it myself once, hence the workaround). It is also not mentioned in errata notes.

I don't think there's another way to treat it besides code specific workarounds, and yes, this

is ugly.

I'm on my way to submit documentation feedback with detailed description of this issue.

upct upct over 12 years ago in reply to Igor Sherer

Prodigy 55 points

Hi,

I also have a custom platform which has a button in P0.1 and this works well while I 'm reading the temperature sensor. I use TR0 an ATEST registers during the reading process.

Regards, Antonio Rosa.

Igor Sherer over 12 years ago in reply to upct upct

Guru 31280 points

Hi,

How exactly you have configured the P0_1 and the interrupt?

Zigbee & Thread

Zigbee & Thread forum

CC2530 Possible Hardware (MCU) Bug