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.
Tool/software:
Hello!
I am testing a design where a MSPM0G3507 (controller) communicates via SPI with an ADS8684A (peripheral).
I validated communication on each channel of the ADC individually-- successfully storing conversions. I am now working on obtaining conversions from each channel in succession, starting with Channel 0. I am doing manual instead of automatic scanning as I plan to implement averaging later on.
To achieve this operation with the ADC, I am transmitting data to the ADC in this order:
1) Setting the ADC input range to 0V to 10.24V in the program registers of the ADC: 0x0B05, 0x0D05, 0x0F05, 0x1105.
2) Sending the following commands for obtaining conversions: 0xC0, 0xC4, 0xC8, 0xCC. Then, repeating this cycle starting at 0xC0.
My software is based on the spi_controller_repeated_fifo_dma_interrupts example from the SDK. In this example, an SPI frame is sent every 1 second using Timer0. I modified the .syscfg so the SPI clock is 1MHz, clock polarity is low, and clock phase is high to capture data on the falling edge.
I have been using a lab oscilloscope to observe the SPI waveforms. As the SPI frames are sent every 1 second, I can observe the operation of the system with the naked eye. The oscilloscope is triggered on the falling edge of the chip select.
In order to observe the desired system behavior on the oscilloscope, I have written the following code. I have highlighted the code I added throughout to achieve this behavior. I did not observe 0x00 being transmit over the PICO line on the oscilloscope. Without this block of code, I observed the following messages being transmit over PICO on the oscilloscope: 0x0B05, 0x0F05, 0xC0, CxC8, 0xC0, 0xC8... Essentially, every other message to the ADC was skipped. This does not align with my current understanding of the MSPM0G3507 or ADS8684A, so I am looking for some clarity as to what is going wrong here.
Hi, thanks for the question! Let me replicate this using your code above and see if I can get you a solution to this issue.
-Brian
Okay. I also have an edit on my above post. "Without this block of code, I observed the following messages being transmit over PICO on the oscilloscope: 0x0B05, 0x0F05, 0xC0, CxC8, 0xC0, 0xC8..." I observe 0x0D05, 0x1105, 0xC4, 0xCC, 0xC4, 0xCC... and on and on. The odd messages (first, third, fifth...) are not transmitted/observed on the oscilloscope.
Hey sorry for the delay here, can you provide a screenshot of the logic output? Also what do you have your frame size set to? I added your code into Theia and ran it and it looks like I am getting 3 transactions of 0x00, then 0xC0, 3 more 0x00, and so on in a repeating pattern. Looks like I am getting the expected results, can you also share your sysconfig settings?
That's okay, I figured out what I was doing wrong. It had more to do with my own software than anything, especially placement of the __WFI() function. I rearranged some things and achieved the behavior I desired. Right now, my project is in a testing phase, and this is enough to validate the SPI connection between the ADC and MCU.
I can provide more information if needed.
I appreciate you looking into this.
Hey AudB,
Nice to hear that!
Please, could you share your code that is working. I'm strugling to do something similar, in my case I'll write/read from/to a FRAM.
Thanks,
Andrea
I should probably let AudB speak, but just in case: I suspect the trouble had to do with the highlighted code blocks, each of which (accidentally) says "Either wait for the timer Or do the transaction", rather than "wait for the timer, then do the transaction". You probably wouldn't use this part of the code for talking to a serial FRAM.
The SPI_send() logic looks fine; there are some refinements possible for the longer transactions you would probably have with a storage device.