Image by Mediamodifier

I have the Promira Serial Platform configured with SPI Active - Level 3 Application, which I am using as an SPI master to communicate with an SPI slave device. It works well until I set the SPI bitrate higher at 53,333 kHz.

At that higher bitrate, the Promira platform initially works well. However, after several minutes, the Promira platform starts sending corrupt data and eventually there is no communication. I used an oscilloscope and a logic analyzer to trace the SPI bus – I saw no data on the bus.

I have the script set up as a queue, as described in section 5.5.3 Queue of the Promira Serial Platform I2C/SPI Active User Manual where I am using API commands ps_queue_create … ps_queue_destroy continuously and setting the bitrate at high frequencies. Is this method correct? Also, are there other possible causes for the issues I observed?

Thank you for your questions! We will provide an overview of how the queue works, and tips for troubleshooting issues such as this.

How Queue Commands Function

Here is an example of using the Promira API queue mechanism for an SPI transfer:

1. Call ps_queue_create to create a queue, and specify the queue type (e.g. PS_MODULE_ID_SPI_ACTIVE).
2. Call ps_queue_clear to clear the queue.
3. Call ps_queue_spi_oe to add a command to the queue to enable SPI outputs.
4. Call ps_queue_spi_ss to add a command to the queue to assert SS line.
5. Call ps_queue_spi_write or ps_queue_spi_write_word or ps_queue_spi_read to add an SPI command that's shifts data on the bus.
6. Call ps_queue_spi_ss to add a command to the queue to deassert SS line.
7. Call ps_queue_spi_oe to add a command to the queue to disable master output.
8. Call ps_queue_submit to send the accumulated commands on the SPI bus.
9. Call ps_collect_resp to collect the first/next response from the previously submitted queue.

   1. Note - If the return value is PS_SPI_CMD_READ, call ps_collect_spi_read to collect the response with the SPI data. Otherwise, no additional functions need to be called.

10. Repeat step 9 until the function ps_collect_resp outputs the return value PS_APP_NO_MORE_CMDS_TO_COLLECT.
11. Call ps_queue_destroy to destroy the queue or go back to step 6 to submit the queue again.

In this example, from step 10, ps_collect_resp is called repeatedly until there is no more data to read from the queue buffer. When collecting and storing data in a local buffer, the queue buffer is consistently emptied and then re-filled with incoming data. Doing this quickly and consistently ensures data is not lost, that the 2MB buffer does not overflow.

Additional Promira API examples are available, which can be downloaded. One API example that may be useful to you is spi_file. This script configures the Promira platform as an SPI master device that sends data. The dev_collection() function collects data from the slave device.

Troubleshooting Data Flow

The issue that you described, corrupted data followed by data no longer transferred, indicates buffer overflow.

• Error codes may be reported, which can indicate the possible cause(s) of the problem.
• Submitting too many queues could overflow the internal memory of the Promira platform, resulting in loss of data. To prevent this problem, we recommend using the API command ps_channel_submitted_count, which verifies the number of queues submitted. The Promira device will not accept commands if the internal queue buffer is full.

We hope this answers your questions. Additional resources that you may find helpful include the following:

• Promira Serial Platform I2C/SPI Active User Manual
• Promira Serial Platform System User Manual
• SPI Background

If you want more information, feel free to contact us with your questions, or request a demo that applies to your application.