This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

SPIM deterministic TX timing control

Hi fellows,

I'm trying to control accurate/deterministic timing of the first bit from MOSI PIN of SPIM, employing EasyDMA.

According to Figure 69 SPI master with EsayDMA, SPIM block has "TXD+1". That would be double buffer for Tx. So, for accurate immediate timing control of MOSI signal, I would like to trigger SPIM to start Tx'ing while the first byte has already been on that double buffer, not under situation where nothing is pre-buffered by EasyDMA, because EasyDMA's bus activity will take addtional cycles.

And additionally, for accurate periodic/pre-scheduled timing control, I'm driving TASKS_START not by CPU but by Timer's EVENTS_COMPARE[i] routed thru PPI.

But, still, some timing jitter is observed on MOSI signal. What indeed is the cause of this timing jitter ? And, any other smart ways to do it accurately on time? Or, SPIM's TASKS_SUSPEND/RESUME can be used alternative to TAKS_STOP/START ?

Parents
  • Hi,

    I got another fact that my application is runnig under clock control by SoftDevice.... My target device is nRF52832 and is running on the platform S132_nrf52_2.0.0-7.alpha. My application is a modified one from a sample code of Central-styled UART supplied by Nordic. At somewhere and/or by some reasons, the original sample codes specify this dynamic clock switching behavior. One of the reasons would be poweer-saving... But, In MY case, timing stability is more important than power-saving. So, I suppose, I should patch the code to prevent this before going into deeper analysis. But, I have no enough idea that the SoftDeice S132 does/may-do dynamic HC clock switching right now. Does anyone have suggestions on that ?

Reply
  • Hi,

    I got another fact that my application is runnig under clock control by SoftDevice.... My target device is nRF52832 and is running on the platform S132_nrf52_2.0.0-7.alpha. My application is a modified one from a sample code of Central-styled UART supplied by Nordic. At somewhere and/or by some reasons, the original sample codes specify this dynamic clock switching behavior. One of the reasons would be poweer-saving... But, In MY case, timing stability is more important than power-saving. So, I suppose, I should patch the code to prevent this before going into deeper analysis. But, I have no enough idea that the SoftDeice S132 does/may-do dynamic HC clock switching right now. Does anyone have suggestions on that ?

Children
No Data
Related