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.

CC110L: CC110L radio in IFADCON state

Part Number: CC110L

Hi!

I have a problem I cannot understand. In a setup with the CC110L chip, I do some packet transfers, then some asynchronous raw sensor data transfer, and again packet mode. In the end, the radio gets stuck in the 0x0B state (IFADCON settling).

According to the control state diagram in datasheet, this state is entered after the autocalibration is complete (in my case active when entering RX/TX), and it should enter RX.

Can anyone tell more about this state and how is it possible to get stuck?

Any configuration parameters that might affect settling?

Thank you!

  • It should not be possible to get stuck in this state which indicate that something is wrong with how the state is read.

    Note the "SPI Read Synchronization Issue" in the errata which could affect the the MARCSTATE register. Also, I assume you have set the burst bit correctly when reading a status register?

    How do you know that you are stuck in this state?
  • Ter: I will check the note on "SPI Read Synchronization Issue", thank you.
    I read the marcstate quite often, to determine the state of my radio, to detect RX overflows, before going to sleep, before flushing the fifos etc. The reading function works correctly, as I never had problems with it, and always returns what is expected.
    I know it is stuck in the settling state, because I saw the radio was not receiving any more packets, so I started searching for the reason. When is stuck, I read the state every 131ms and display it on lcd screen - so it is a fact and it stays in this state until I pull it out in idle.
    From this state, I issue an idle command and next time I enter RX, it works well, returning RX state and receiving again.
  • If you still see the same problem, could you provide plots of the SPI lines when you read this status?
  • The problem is still there, but I must rectify the above information regarding the issuing of idle commad: no, after a few seconds in the 0x0B state the chip stops responding, the SO pin doesn't go low any more. So I will check the crystal oscillator when it gets stuck in this state.

    No, I cannot provide plots, I do not have the equipment.

    If you want I could paste here the SPI interface code, but it is in AVR assembler. I use the same function with different addresses for all status registers, and I always read them corectly: RXBYTES, RSSI, CRC_REG, and MARCSTATE.

    The problem appeared after I modified some code to use the sleep mode more often. Maybe it has nothing to do, and I thing I handle the sleep correctly: I only issue the sleep command from idle mode, and when it wakes up I just wait for the SO pin to indicate chip ready - I even determined the waking time to 135µs. Always after wake up I rewrite all registers in a burst transfer.

  • So, after some more tests I found out that all comes from configuring the radio in asynchronous mode.
    Like I said, I fully configure my radio writing the 48 registers in one burst transfer, for both modes: packet & async.
    After I get to configure the radio in async mode, if I don't reset (with a reset command) the chip it starts acting crazy when I reconfigure it for packet mode.
    The 0x0B state is not the only weird thing about it, but also the fact, that when configuring the GDO2 pin for PKT RX signalling, it stays right on (logic 1) after entering RX, without receiving anything.

    So, I wonder what could be wrong with it, something that only a reset can bring back to normal...
    Like I said, I always test the marcstate before entering sleep, before configuring, before flushing fifos.
  • Hi
    When testing different modes we have tested transparent mode and ordinary packet mode in different test cases, and when running test in the lab there will always be a full reset between the different test cases to have full control over which settings are used in which case. That means that we have not tested switching between packet mode and transparent more in the same test case, as we have not previously come across use cases for this.
    It might look like there are some internal registers that are set for one mode, and are not properly reset without doing an SRES.
    Is doing an SRES between modes a solution you can use?
    If you need us to look more into this we will need a description of a test setup that will show us the issues you are seeing.
    Siri
  • Siri: yes, SRES is a solution in my case.

    I did not have time now to dig deeper into the behaviour, but I know it only happens when I use the sleep mode between transmissions. Until now, while in early development phase, I did not use sleep and there were no problems, the radio was switching between fifo-async modes and the transmissions were fine, I never used SRES. The strange behaviour only started after I implemented sleep state all the time when not in RX/TX.

    I will have to analize this deeper anyway, the SRES solution is fine for now, when I have the time I will describe here more exactly the setup/problems/facts.

    Thank you!