SGPIO with DMA

[lpcware]

Content originally posted in LPCWare by jgorsk on Mon Oct 29 11:59:22 MST 2012
I've been trying to use SGPIO with DMA. I want to transfer ten 11 bit words
from memory to SGPIO REG_SS register, one at each SGPIO15 DMA triggering pulse.

TRANSFERSIZE is set to 10
burst sizes are set to 1
transfer widths are set to 16 bits (0x01)
flow control is memory to peripherial (DMA control)
SGPIO15 is output at the LPC43 pin so I can monitore it

DMAMUX in CREG is set properly to select SGPIO15 for peripherial 12 BREQ
(Keil debugger IO register view is showing this configuration as reserved,
not assigned to SGPIO15)

The source address in DMA controller is being incremented properly,
also TRANSFERSIZE  is changing to 10 but SGPIO is not reacting.
Only one positive pulse is generated at SGPIO15 which is a result
of the values I load to REG[15] and REG_SS[15] when I set up SGPIO to start triggering DMA
transfers. There is only one pulse triggering DMA but DMA 'counters' are incremented 10 times.

I'm configuring DMAMUX, SGPIO and DMA register. Is there anything else that needs to be configured
in order for SGPIO to work with DMA?

[lpcware]

Content originally posted in LPCWare by jgorsk on Thu Jan 10 09:02:38 MST 2013
I finnaly had some time to work on that. DMA transfers work for me now.
My mistake was I tried to do 16 bit DMA trasnfers from memory fo SGPIO.
SWIDTH and DWIDTH fields in CONTROLx register were 1. With 32 bit transfers
(SWIDTH = DWIDTH = 2) everything works.

Thanks again for your help DF9DQ.

[lpcware]

Content originally posted in LPCWare by xianghuiwang on Mon Dec 03 16:10:26 MST 2012
Hello Jgorsk,

We have just included a SGPIO_DMA_PatternGenerator sample project in the CMSIS PDL package which is available on the lpcware. It is using M0 to implement a 16 channel pattern generator with DMA to help with memory to SGPIO slice pattern transfer in the swap interrupt.

[lpcware]

Content originally posted in LPCWare by starblue on Wed Nov 28 02:41:13 MST 2012
For the AD7367-5 my approach is just to wait the specified maximal time (1.25µs) and to ignore the BUSY signal.
In reality it is high for about 900ns, so there is quite a bit of room left.

So except for data all my signals are outputs, which can be done by the SGPIO alone.

I use /CS as a qualifier for the bit clock for data, that works nicely without any trouble.
I clock in 14 bits each on two channels twice in succession, with a full cycle of 4µs.

To give the ADC enough time to enable the data signals I shift around /CS a bit,
by using a different initialization value for the bit clock timer.
I run at 200MHz system clock, so I can shift around the signals in steps of 5ns.

I don't use DMA, rather the Cortex M0 gets an interrupt after a full cycle.
It collects the data and sets the shadow registers for reinitialization of the signals.
As they are 20 or 40 bits long I can't let them run freely.
(It would be nice if there where a mode that copied the shadow registers instead of swapping.)

Bit 0 of the shift register affects the output immediately once outputs are enabled,
so it is best to start the bit-banging sequence in an idle state.

[lpcware]

Content originally posted in LPCWare by mark03 on Tue Nov 27 15:12:25 MST 2012
Yep, I'm hoping to use an LPC43xx in an SDR project too, eventually, although my immediate project is a bat receiver.

My ADC(s) will be triggered by a timer match output at ~ 500 ksps.  They indicate a conversion is ready to clock out by the falling edge of a BUSY signal.  So if I use SGPIO I must figure out some way to gate or trigger the SGPIO block, based on BUSY from the ADC.  And it is best if the bit clock only runs for the 16 bits of the conversion result, and then stops, rather than be free running.  I think I can cobble this together using the state configurable timer.  It will be fairly complex :)  There is also a gating function built into SGPIO, but as usual, information on it is sparse.

Have you tried scatter/gather DMA yet?  I am wondering if I can run two ADCs with DMA from two SGPIO shadow registers using the single DMA request.  Worst case, I can always use both SGPIO 14 and 15 and set up separate DMA channels to separate buffers.

Mark
KJ6PC

[lpcware]

Content originally posted in LPCWare by DF9DQ on Tue Nov 27 13:23:09 MST 2012
That's an interesting project for a ham like me :-)

So I started implementing that with the SGPIO today, and I got 8-bit parallel output data + bit clock running. That makes me confident that the receiver side can be done easily (8-bit path from ADC).

The transmit DAC has a 10-bit data path, so I need to spend some thought on this. Probably I will need a second DMA channel to feed another couple of slices for the remaining two bits.

[lpcware]

Content originally posted in LPCWare by DF9DQ on Tue Nov 27 13:12:10 MST 2012
11-bit frames can easily be accomplished by the very same procedure that I have used!

Self-looping always uses the full 32 bits of a slice. The pattern determines the rate by which the input clock is divided down. 0xAAAAAAAA gives you a DMA request rate of 1/2 the input clock, 0x80000000 results in a DMA request every 32 clock cycles. You cannot divide by 11 with the self-looping slice alone.

I think the solution is obvious now! :-)
There's a pre-divider that selects the clock for each slice individually. A pattern of 0xAAAAAAAA (divides by 2) together with a predivider of 11 gives a DMA request every 22 bit times. All you have to do is predivide the clock of the data slice by two to get a DMA request every 11 bits.

I changed the numbers in my project to verify this works as expected. See the attached file.
For simplicity, I have organized source data as 32-bit values, where the 21 MSBs are unused. You can pack two frames into the 22 LSBs of a word, reducing the amount of memory wasted. Then you must update the DMA request rate accordingly.

For the records: There's another solution to this problem: You can use SGPIO3 or SGPIO12 to generate a bit clock. This is of interest if you have to generate that bit clock anyway, but want to use the DMA capable slices for something else. In this case you can use the GIMA multiplexer to route, for instance, SGPIO3 to a Timer0 capture input. That timer can run in counter mode, and generate a DMA request through one of its match registers, which has to be set to the desired frame length.

[lpcware]

Content originally posted in LPCWare by jgorsk on Tue Nov 27 11:28:58 MST 2012
Thank you very much Rolf.

I haven't got a chance to try your program out yet but I will. I only had a look at it.
There is one big difference bewteen the way I tried to use SGPIO with DMA and the way you do it.
You're sending 32 bits in one transaction so you can use selflooping to keep generating a pulse
on SGPIO15. I need to send only 11 bits so I came up with an idea of using two DMA channels.
One was supposed to update SGPIO15 data register to keep generating the DMA triggering pulse,
the other one was used to update the actual SGPIO channel data register I wanted to work with DMA.
Maybe that's where the problem is. I wonder if SGPIO15 can trigger two DMA channels at the same time?
I guess I can't do the selflooping trick, can I?

It's very good to have a working example. Thanks again.

[lpcware]

Content originally posted in LPCWare by mark03 on Mon Nov 26 11:47:13 MST 2012
Hey, thanks Rolf, this is really great!

I'm going to point the HackRF[1] folks over here, so they can figure out what part of the configuration they were missing.  I'm curious to find out myself.

Mark

[1] https://github.com/mossmann/hackrf/wiki/LPC43xx-SGPIO-Configuration

[lpcware]

Content originally posted in LPCWare by DF9DQ on Mon Nov 26 10:32:12 MST 2012
I stripped everything down to a simple test project. It comes with a project file of Keil uVision.

Test was done on a Keil MCB4300 board. Besides the unavoidable blinking LED (P9_2) it uses two SGPIO outputs:
P4_10 = SGPIO15: The DMA trigger. One pulse every 32 bits.
P9_0 = SGPIO0: The serial data output. DMA transfers 64 words, but only two are non-zero to allow easy triggering of the scope.

The CPU runs at the default 96 MHz, and that is also the serial bit rate at SGPIO0.

I use LPC4357, so it should run fine on your LPC4337 as well. Let me know if there are any problems.

Regards,
Rolf

[lpcware]

Content originally posted in LPCWare by jgorsk on Sun Nov 25 11:37:48 MST 2012
Hello JohnR,

Sometimes you can't do it without DMA. It's a matter of the transfer rate.
If you want to do high speed continuous transmission (or almost continuous),
you won't be able to do it using only SGPIO IRQ Handler. Just try it.
IRQ handler will consume most of the CPU time if you do continuous
transmission or there will be gaps between consecutive transfers
if you do it in 'single shot' mode (by setting bits in CTRL_DISABLED reg.).

[lpcware]

Content originally posted in LPCWare by jgorsk on Sun Nov 25 11:28:26 MST 2012
That's great news DF9DQ. Would you share your sample program with us?
I think I tried all AHB Master combinations and none of them worked
for me. I must have been doing something wrong.

BTW, which micro are you using. I'm using the LPC4337.

[lpcware]

Content originally posted in LPCWare by DF9DQ on Sat Nov 24 12:18:00 MST 2012
I found the time today to run a test of SGPIO with DMA, which is actually my very first SGPIO project. The setup is simple: I send data blocks (64 words of 32 bits) out via SGPIO0 (slice A). DMA requests are generated by SGPIO15 (slice P) every 32 bits to refill the shadow register REG_SS0.

Serial output at SGPIO0 is with full CPU speed (72 MHz in my setup), and everything is working fine as expected.

[Edit]:
One thing I came across was DMA AHB connections. There are two AHB master ports which you can individually assign to source and destination in the channel control register. The user manual says that only port 1 has full access to memory and AHB/APB peripherals, while port 0 is limited to memory areas. As it happens, this seems to be the other way round...

Although my intention was to carefully pick the right AHB master port for my example, I completely forgot it for my test yesterday. Today I checked this, and the result is that both master 0 and 1 can access memory, but only master 0 has access to the peripherals.

[lpcware]

Content originally posted in LPCWare by JohnR on Sat Nov 24 08:06:55 MST 2012
I am wondering whether DMA in this case is really needed.

In my dual-core project I have M0 running a dual 14-bit ADC via SGPIO and communicating the data to M4, using the M0_SGPIO_IRQHandler and M4_SGPIO_IRQHandler functions. The data to be transferred are held in common memory.

M4 starts a set of measurements sending __DSB() and __SEV() to M0. The ADC data are then repetitively read in interrupt mode using M0_SGPIO_IRQHandler. After a preset number of measurements, a flag is set to allow a loop in M0's main() to run and send the block of data to M4 using __DSB() and __SEV() again.

Hope this helps.

John.

[lpcware]

Content originally posted in LPCWare by mark03 on Fri Nov 23 12:48:41 MST 2012
Sorry, no, I don't actually have working hardware yet.  The lack of an answer from NXP has me frozen back in the hardware design stage, because without clarity on SGPIO it's not clear which is the best way to interface my ADCs.

I was going to allow a month from Xianghui's post, but seeing as that expires next Tuesday...  my best guess, unfortunately, is that he is having to reverse-engineer his company's own product.  Having worked in a fairly dysfunctional tech organization myself, I know that this is a disturbingly common scenario :|  He probably assumed it was possible, just like we did, and is now stuck, just like we are.  This would also explain why the other NXP folks on the forum, like bavarian and wellsk, have studiously avoided making any comments in this thread: they don't know either, and are afraid to make a definitive statement for fear of being wrong.

At this point I have to put my project on the shelf and work on other things, until either NXP surprises us, or some other vendor releases a similarly performant M4 solution.  It's really too bad.

[lpcware]

Content originally posted in LPCWare by jgorsk on Thu Nov 22 10:37:23 MST 2012
Has anyone managed to use SGPIO with DMA yet?

I tried to use the M0 core to handle SGPIO in polling
mode instead of using M4 with DMA (which didn't work for me).
Even this solution wasn't fast enough to implement a simple
output only SPI bus running at 35MHz SPI clock (CPU clock is 176MHz).
It seems to me like SGPIO is not really suitable for high speed
applications since without DMA it uses too much CPU time. Also,
if you use SGPIO in 'single shot' mode when the slices automatically
stop after one POS countdown, there will be gaps between consecutive
transfers since CPU will need time to reconfigure some of the SGPIO
register before next transfer can be made. That reduces the effective
speed of the transfer.

On the other hand, it does great job on handling 8 data line SPI bus
to an 8 channel ADC in my application. But the clock speed is only about 2MHz.

[lpcware]

Content originally posted in LPCWare by jgorsk on Mon Nov 05 02:17:42 MST 2012
Hello xianghuiwang,

How are you getting on with the sample code for SGPIO
with DMA? Have you been able to get that to work
or are you just going to work that out? If you managed
to get SGPIO to work with DMA, please give us an idea
of how to do it.

[lpcware]

Content originally posted in LPCWare by mark03 on Wed Oct 31 11:14:37 MST 2012
Hi Xianghui,

That's great news!  and encouraging that someone at NXP is looking into it.  We'll be eagerly awaiting your findings.

Mark

[lpcware]

Content originally posted in LPCWare by xianghuiwang on Tue Oct 30 15:32:01 MST 2012
Hi, Jgorsk,

We will have some sample code for SGPIO with DMA coming really soon.

Xianghui

[lpcware]

Content originally posted in LPCWare by jgorsk on Tue Oct 30 10:31:02 MST 2012
Hello mark03,

I tried many different things to get SGPIO to work with DMA. It didn't work. I think there is pretty big chance it can work, we just don't know how to use it. That's because the documentation is far from being good.
It's not detailed at all, sometimes there is not much more in it than just the bit or register name. NXP must be very busy at the moment, we can only wait for them. Flash based LPC43xx were supposed to be
released in May this year, then I heard about October. There is not much point in releasing those micros if there is no decent documentation. Who can fully use them? I think they deserve to be used. The samples
I have, work well (so far except for  the SGPIO with DMA) but it takes a lot of effort to get some things to work due to the lack of proper documentation. I hope NXP will improve the documentation soon enough.
I haven't used any NXP micro since good old Philips 8051. Back then they used to have very good documentation. Great application notes, not like nowadays.

BTW, I think NXP microcontroller division is based in the US not in the Netherlands. I may be wrong though.

[lpcware]

Content originally posted in LPCWare by mark03 on Tue Oct 30 09:59:24 MST 2012
Hi jgorsk,

I'm the one who revived this question over at the NXP MCU forum.  There's a tiny bit of discussion there, and a link to the HackRF wiki where they have [tentatively] concluded that SGPIO DMA is not possible.  Still not a peep from NXP.  It's surreal--like they don't actually *want* anyone to use their microcontrollers.

I even tried submitting a formal request for tech support at the web site, but after carefully typing in my question and filling out all of the required fields, it comes back with

"We’re sorry, but something went wrong with the sending of your inquiry. Please try again later." !!

This has been the case for at least 24 hours, and for all I know, weeks or months.  What does it take to get an answer from these people?  Fly to Eindhoven and knock on doors?