CC1100: Suggested workaround in errata of CC1100 to read TXBYTES doesn't work in RIOT OS

Marian,

We do not know very much about this operating system, but the errata you mention only happens very rarely and you write it happens all the time. Therefore I believe that their is something else wrong and my guess is a configuration error of the SPI port of the host MCU. The typical configuration error that happens is that the host MCU is configured to sample on the rising edge and the CC11x device is sampling on the falling edge of the SPI clock. I suggest getting an oscilloscope and verifying the SPI communication is correct as per the datasheet of the both devices.

Regards,

/TA

Thank you very much for your reply.

Sadly I was unable to confirm that SPI communication is the source of the problem due to a lack of equipment. However, this is by far the most plausible explanation for the problems. Additionally the problem was introduced with a commit for a major refactoring of the SPI implementation of RIOT.

The documenation says:

In RX mode, data is set up on the falling edge by CC1100 when GDOx_INV=0.
In TX mode, data is sampled by CC1100 on the rising edge of the serial clock when GDOx_INV=0.

And the RIOT driver configures the SPI to rising edge mode. I don't have a hardware background and I'm unable to understand the two sentences above. Could someone please rephrase in which cases the CC1100 expects transmission on falling edge? And how the driver can instruct it to stay in rising edge mode?

Thank you very much!

Kind regards,

Marian

I could not find much information on the MSBA2 board. Is this open source and you have to make the board yourself or is it of the self? Put it differently, why is the board using CC1100 and not CC1101? CC1100 has been NRND for some time.

"
In RX mode, data is set up on the falling edge by CC1100 when GDOx_INV=0.
In TX mode, data is sampled by CC1100 on the rising edge of the serial clock when GDOx_INV=0.
"
This is not related to the SPI interface but for synchronous serial mode which you don't use if you use the FIFO. See chapter 10 in the UserGuide for details on the SPI interface.

Is it just the TXBYTES you have an issue reading? Have you verified that the SPI interface works reading/ writing to other registers?

Why do you do polling and not interrupt driven in the first place?

Hi,

the MSBA2 board was designed by Dr. Liers at the Free University of Berlin. It is rather old, I assume the CC1101 was not available at that time. It's successor, the MSB-IoT Board, uses the CC1101. Because my PhD supervisor was a professor at the FU Berlin, he got a bunch of both boards.

I'm currently trying to revive those boards for our students, so that they can learn embedded C programming. Both modules use the same driver for CC1100/CC1101 transceiver. Interestingly the problem with reading the TXBYTES register is only present on the MSBA2 (CC1100, CPU=lpc2387), not on the MSB-IoT (CC1101, CPU=stm32f415rg).

I have no idea why polling was favored over interrupt driven operation and the authors of the driver are unavailable at the moment. A rewrite of the driver to work without polling is no option for me at the moment, because I lack the time to do so. At the moment I don't even have the required knowledge about about the chip or the RIOT driver framework, as I'm new to this topic. So just gathering the required knowledge would take a few weeks...

So for know I would be happy with a quick fix.

> This is not related to the SPI interface but for synchronous serial mode which you don't use if you use the FIFO.

The problematic code is

    do {
        res1 = spi_transfer_reg(dev->params.spi, SPI_CS_UNDEF,
                                (addr | CC110X_READ_BURST), CC110X_NOBYTE);
        res2 = spi_transfer_reg(dev->params.spi, SPI_CS_UNDEF,
                                (addr | CC110X_READ_BURST), CC110X_NOBYTE);
    } while (res1 != res2);

in which res1 and res2 continuously return different values. So only SPI communication is done here.

Kind regards,

Marian

Out of curiosity, the requirement is that is has to be a board running RIOS OS?

Yes, either that or I would have to port RIOT to it. My PhD supervisor is one of the authors of RIOT, so naturally he has an interest in getting his PhD students ;-)

But while RIOT still has some rough edges (like the poorly maintained CC1100/CC1101 driver), it really is an interesting OS for the IoT. For example because of the POSIX compliance, I can run most of my code with only minor modifications on RIOT. Thus, I'm really looking forward to working with RIOT.

I see that some work has been done porting RIOS to github.com/.../Board:-CC2538DK and github.com/.../Board:-CC2650STK Have you considered to try to get it to run on a CC13xx or CC26xx Launchpad? That would provide you with a relatively cheap and flexible platform.

Thanks for the hint. In fact, my college has a few CC2650STK in his office, but didn't had the time to work on those. Maybe now is a good time to give them a close look. Especially being compact and having an really appealing and robust case makes them ideal for lending them to students :-)

Also support for 802.15.4 and BLE is quite nice. Of course, our students will never work on OSI layers below the application layer, so the actual technology does not matter much. But still, using state of the art technologies can highly motive them.