I’m doing some low level firmware hacking and trying to find out if communicating with the Broadcom Wifi chip can have side effects on other systems. Looks like its mostly closed source in the WICED library, but I’m hoping someone knows if it’s using DMA (what channel?), overloading some interrupts (which ones?) or using any other shared resources (like some GPIO pins that are unavailable for ADC, SPI, whatever peripherals).
Thanks for any help!
@wire, explaining what you are trying to achieve might help us in providing some guidance. The WICED library is mostly closed by Broadcom though you can get the details by registering as a Broadcom developer and downloading their source. Eventually, Particle will be allowed to share the code.
As for inner details, a good place to start is the open-source code. You may want to spend some time there and then ask specific questions. You can also search the Community as many members have contributed libraries and knowledge on how to exploit low-level resources including timers, GPIO and DMA. Explore! 
The use case here is to get as fast as possible analog input, process it and send it out over the network (ideally UDP). My current ideal plan is to use double buffered circular DMAs from the ADC, and when a buffer is full process it after spinlocking or in an interrupt. Various design choices could depend on what side effects the UDP packet sending are. If it’s messing on the same DMA channel as the ADC, I probably shouldnt use DMA. Similarly if it’s using similar interrupts, calling it within one, or even using interrupts at all might be a bad idea.
@wire, (I believe) the ADCs already use DMA for averaging and looking at the open source code would allow to see how you can exploit or reuse the code for your own use. The STM32F205 support multiple DMA channels and I recommend you dig into the ST reference document for more details.
I believe that, except for interrupt prioritization, there is no conflict between the ADC DMA and anything used by WICED but @mdma can confirm that.
Everything you want is possible with the Photon. Your data processing and the UDP throughput may ultimately be your rate limiters but you did not mention what throughput you needed.
That’s right - WICED doesn’t use any DMA since we don’t use their implementation of the peripheral drivers.
Thanks @mdma, do you also know if they mess with interrupts?
@peekay123 Yes, the plan is to change the ADC HAL in the firmware to do these high performance serial reads. I’ve already disabled the averaging in there to speed up regular analogRead(), but it’s still 3-6x slower than the hardware should be able to do (without interleaved sampling). Getting that set up I’m not too worried about, as the ST docs are pretty clear on how to set it up.
Just the black box around the network stuff is a bit concerning, as I have no idea how long even a tiny 8 byte packet might block the CPU, and what it might interfere with in the mean time.
what’s the required sample rate? Is it bursty or continuous? Bytes per sample?
So, something in the Wifi library or its hardware effects, is breaking my DMA from the ADC.
I am trying to sample continuously as fast as possible from the ADC, and am getting solid 2 MHz samples, then I process the data when one of the two double buffers is filled, and send 8 bytes roughly 60 times a second as a UDP packet.
After a random amount of time, somewhere between a quarter of a second to 10 seconds, the DMAing stops. Looking at all the flags, it looks like the ADC reports an overrun condition, ie that data was lost.
If I disable the UDP packet sending, and wait an roughly the same amount of time (200 usec) in its place, the capture runs very stable.
Any ideas how it could be interfering with the ADC or DMA?
WICED uses interrupts to communicate wit the WiFi module, if that's what you mean.
Keep in mind that your app is running on top of an RTOS, and your application may be switched out, so definitely best to empty the DMA buffer via an interrupt. After all, that's what interrupts are for - ensuring timing critical actions are serviced in a timely manner.
I’ve debugged this further and am concluding that the most logical reason why the ADC is reporting overrun conditions (which just shouldn’t happen if the DMA immediately fetches the data from the ADC), is because other concurrent DMAs must be triggered by the Wifi communication, and that I’m running in the same issue described in this blog post.
STM acknowledged the issue described in the post in recent errata documents for the chip (section 2.1.8), and explains it as a bug when DMAs with peripherals on both the AHB and APB bus get used simultaneously.
ADC is on the APB, the AHB services eg the GPIO, which I believe is where the Wifi chip is connected to, right? Are you certain that GPIO communication does not use DMA in any way? Or could anything else in the RTOS be triggered by UDP::sendPacket that causes DMAs?
I would love to turn off the DMAs in the Wifi communication, as it should be much lower bandwidth communication than my 2 MSamples/s ADC communication.