ADC Data extraction at high sampling frequency

[chanchal94]

ST moderator: Edited the tile to add "ADC"

I want to extract data at high sampling frequency ~10KHz at STM32N6570-DK, Is it possible with USART for three channels or we have any other mode for this purpose. I want to continuously stream data at 10KHz sampling frequency.

[Ozone]

> I am trying to capture the data in two steps as you said. While trying to capture the data into memory, I am facing the issue of not being able to flash the code to MCU, It is showing shutting down and exit (screenshot is attached), ...

Not sure what you want to achieve here.
But storing this data in internal Flash in realtime will never work.
Just look up the erase/programming times in the MCU datasheet.

Either store it in RAM (external RAM would be the best option), or transmit it in realtime.
A proper USB implementation is another option, like so many "USB soundcard dongles" do.

I'm doing a somewhat similiar project on a F303, with 3 channels at 80kHz each.
Transfer is via SPI to a Linux SBC, which requires a short wiring and SPI clock rates of 10...20MHz.

[chanchal94]

Is this transfer via SPI to Linux is working without data loss? 

[Andrew Neil]

---

@chanchal94 wrote:

While trying to capture the data into memory, I am facing the issue of not being able to flash the code to MCU,

---

That's a separate issue - best to make a separate thread for that.

But first, check: How to solve debugger connection issues

Also: How to solve connection errors when connecting and programming the STM32 target board.

 I am trying to flash the data into MCU

---

As @Ozone said, that's not going to work.

You'll need to save it to RAM.

[Ozone]

Yes, if it's properly configured.
High clock frequencies require either special cabling or short wires, better both. In my case, the two boards are just a few centimeters away. The Linux SBC is Pi Zero-II, and thus even smaller than an average STM32 board.

The Linux SBC is SPI master, and I have two additional control lines to keep the transfer synchronized.
Total SPI transfer rates must be greater than sampling data rate to avoid data loss.
That should be easy to calculate.

[Ozone]

I might add, this approach comes with other challenges.

First, one needs to implement a proper Linux application to capture and store the sample data. However, the memory constraints are very much relaxed, one could easily sample several seconds at once into RAM buffers.
Realtime storage during sampling is somewhat more challenging.

Second, this approach makes only sense for me when operating the Linux SBC headless, i.e. without keyboard, mouse and display. I mostly use ssh or a serial terminal.
And for operating the setup, it is mandatory to shut down the Linux SBC properly. Just pulling the plug will corrupt the filesystem sooner and later, and give you "kernel panics" during boot.

I would only recommend this approach for developers with some solid Unix/Linux experience.
Just saying ...

[chanchal94]

Using memory buffer with USART is not sufficient for my requirement of getting 60, 000 samples( 10,000 samples - each from three sensors for 2 seconds = 3*10,000*2)

I am trying to use USB-HS mode with ADC+DMA+timer for data extraction at high sampling frequency.

My project is in FSBL only, will USB-HS mode will work in FSBL project only or I need to generate another one using application mode?

[MM..1]

I dont understand your loss and other issue. Little match exam 3 sensors 12 bit 10k samples = 360000 bps.

Simple serial in binary 8bit mode add some CDC overhead, but can work ok on 900kbaud. Many space here for CRC. Real hard jobs is megasamples , then HS or ethernet is required.

Then start with create clean CDC UART at 921600 with buffered offloaded send . After this second job is DMA ADC ...

[Andrew Neil]

---

@chanchal94 wrote:

Using memory buffer with USART is not sufficient for my requirement of getting 60, 000 samples

---

Why not?