nRF52 sending an octet

RE: nRF52 sending an octet

Elaine — Wed, 20 Jan 2016 18:21:41 GMT

Ok, I've attached my code in a different post: devzone.nordicsemi.com/.../

RE: nRF52 sending an octet

Susheel Nuguru — Wed, 20 Jan 2016 08:14:20 GMT

Hi Elaine, Sorry for late response, This workaround is not being applied in the SDK yet and there are no other examples to show this. I can help you to apply this to your code, attach the code where you have difficulty understanding this. You just need to use one unused GPIOTE and PPI channel to automatically trigger SPI->TASKS_STOP when the clock toggles, which will result in one byte transfer as SPI cannot stop the transfer mid byte.

RE: nRF52 sending an octet

Elaine — Fri, 15 Jan 2016 18:58:25 GMT

Hi Aryan, I'm trying to implement this workaround and am having some difficulties figuring out how to pass in the required parameters to run this piece of code. Is there an example code that I can refer to?

RE: nRF52 sending an octet

Susheel Nuguru — Wed, 16 Dec 2015 12:05:47 GMT

No it is not fixed yet, so for one byte transfers using DMA, you have to use this workaround.

RE: nRF52 sending an octet

Abhi — Tue, 15 Dec 2015 19:35:53 GMT

Thanks for letting me know about this, sorry for replying so late. I was wondering if this is still the only way around to send an octet? Or has the issue with using the DMA been fixed?

RE: nRF52 sending an octet

Susheel Nuguru — Wed, 18 Nov 2015 08:33:33 GMT

There is a PAN for this with the workaround, you can see this here

[58] SPIM: SPIM clocks out an additional byte when RXD.MAXCNT = 1

You can use the SPI module same as nRF51 (depreciated but still available at same register addresses) That SPI module can be use for one byte transfers. Else you need to use below workaround

/**
 * @brief Work-around for transmitting 1 byte with SPIM.
 *
 * @param spim: The SPIM instance that is in use.
 * @param ppi_channel: An unused PPI channel that will be used by the
 workaround.
 * @param gpiote_channel: An unused GPIOTE channel that will be used by
 the workaround.
 *
 * @warning Must not be used when transmitting multiple bytes.
 * @warning After this workaround is used, the user must reset the PPI
 channel and the GPIOTE channel before attempting to transmit multiple
 bytes.
 */
void setup_workaround_for_ftpan_58(NRF_SPIM_Type * spim, uint32_t
 ppi_channel, uint32_t gpiote_channel)
{
 // Create an event when SCK toggles.
 NRF_GPIOTE->CONFIG[gpiote_channel] = (
 GPIOTE_CONFIG_MODE_Event <<
 GPIOTE_CONFIG_MODE_Pos
 ) | (
 spim->PSEL.SCK <<
 GPIOTE_CONFIG_PSEL_Pos
 ) | (
 GPIOTE_CONFIG_POLARITY_Toggle <<
 GPIOTE_CONFIG_POLARITY_Pos
 );
 // Stop the spim instance when SCK toggles.
 NRF_PPI->CH[ppi_channel].EEP = (uint32_t)&NRF_GPIOTE-
>EVENTS_IN[gpiote_channel];
 NRF_PPI->CH[ppi_channel].TEP = (uint32_t)&spim->TASKS_STOP;
 NRF_PPI->CHENSET = 1U << ppi_channel;
3 New and inherited anomalies
Page 12
 // The spim instance cannot be stopped mid-byte, so it will finish
 // transmitting the first byte and then stop. Effectively ensuring
 // that only 1 byte is transmitted.
}

What this workaround does is that it uses GPIOTE and PPI to trigger the SPI->TASKS_STOP when the SPI_CLOCK toggles. And since the SPI transaction cannot be stopped mid byte, it will complete that one byte transfer.

You have to remember to enable the GPIOTE and PPI channel used for this workaround just before one byte transfer and then disable them when you want to transfer multiple bytes. This is little ugly but works.

RE: nRF52 sending an octet

Abhi — Wed, 04 Nov 2015 17:47:38 GMT

Yes, that post covers the same issue. Ok, so I was wondering if it is possible to shorten the time for which SS is set to low by half then? Because the 8 bits that I need to send contain a command that will execute on the rising edge of the SS after those 8 bits have been sent.

RE: nRF52 sending an octet

Susheel Nuguru — Wed, 04 Nov 2015 08:54:52 GMT

Have not looked into this driver but, if it is using DMA then there is a known issue regarding this. You can find the related post here