We're working on the CC430F5137 and we came across a problem with the single byte reading.
Here's a detailed descriptions one of our developers wrote:
Single byte read of a radio register does not work.
When trying to perform a single byte read from a radio register using RF1A library ReadSingleReg() implementation, the radio interface data out interrupt flag (RFDOUTIFG) in RF1AIFCTL1 register sometimes fail to set. When the RFDOUTIFG flag fail to set it will cause the internal while statement to loop forever hence stalling the application.
The radio is configured to MCSM1 = 0x0F. The firmware application transmits and receives messages to/from clients over the air. When trying to read current RSSI value from the radio RSSI status register, while clients transmit to the application, then there is a good chance that after a finite number of iteration the read operation won't work. If no client traffic exists (no message to be received by the application radio) then the operation would work.
We suspect that pooling the radio interface (reading RF1AIFCTL1 register in a loop) while in RX mode and simultaneously receiving an incoming message accounts for this failure. It may be related specifically to RSSI register or to its internal update mechanism.
We are looking for a work around and also considering the following:
We are facing the similar problem. Any follow up on this question is appreciated!!
Does anyone have an answer to this problem? It looks like this pops up every once in a while on the forums and never gets an answer. It sounds like this is the same as this thread:
I remember a similar problem in the old 1x family MSPs. When you got a por tpin interrupt at the same moment you wer reading the port pin interrupt egister, the interrupt was lost. Maybe the problem still exists even in newer MSPs, but the implementaion of IV registers has removed the need to check the IFG register.
It's possible that a similar problem exists here.
_____________________________________Before posting bug reports or ask for help, do at least quick scan over this article. It applies to any kind of problem reporting. On any forum. And/or look here.If you cannot discuss your problem in the public, feel free to start a private conversation: click on my name and then 'start conversation'. But please do so only if you really cannot do it in a public thread, as I usually read all threads. And I prefer to answer where others can profit from it (or contribute to it) too.
That's an interesting theory. I disabled all interrupts inside of the ReadSingleReg () function that was locking up, and the problem seems to go away. Since the lock-up problem only occurs when receiving data, it is possible that an interrupt is triggered while performing the ReadSingleReg function.
I don't have time to debug further and see what exactly is happening; but I'd recommend anyone else having this problem to try disabling interrupts while in this function and see if that helps your problem.
- Chad C.
Chad ChristensenThat's an interesting theory. I disabled all interrupts inside of the ReadSingleReg () function that was locking up, and the problem seems to go away. Since the lock-up problem only occurs when receiving data, it is possible that an interrupt is triggered while performing the ReadSingleReg function.
What I meant was that the reading of the IFG register prevented the new interrupt flag to be set in the register, so the interrupt was never recorded by the hardware.
However, if blocking interrupts solved it for you, it is possible that there is a racing condition between the ReadSingleReg() function and an interrupt function, perhaps both reading the same register. I don't know the code, so I can only guess.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.