Simple SGPIO test program isn't working as expected

[lpcware]

Content originally posted in LPCWare by jgorsk on Fri Oct 05 07:42:57 MST 2012
I'm trying learn how to use the SGPIO, I wrote a simple test program
and I expected to see 8 clock pulses at SGPIO9 and SGPIO13 outputs
(OUT_MUX_CFG = 0x08).
Instead I'm getting serial bit patterns as specified by REG
register contents.

What am I doing wrong in the following example?


LPC_RGU -> RESET_CTRL1 = (LPC_RGU->RESET_ACTIVE_STATUS1) | (1 << 25); // reset the SGPIO block

LPC_SGPIO -> OUT_MUX_CFG[9] = 0x00000008;//SPGIO9 is clk_out
LPC_SGPIO -> OUT_MUX_CFG[13] = 0x00000008;//SPGIO13 is clk_out

LPC_SGPIO -> SLICE_MUX_CFG[12] = 0x00000000;//slice M
LPC_SGPIO -> SLICE_MUX_CFG[14] = 0x00000000;//slice O

LPC_SGPIO -> SGPIO_MUX_CFG[12] = 0x00000000;//Slice M
LPC_SGPIO -> SGPIO_MUX_CFG[14] = 0x00000000;//Slice O



LPC_SGPIO -> CTRL_ENABLED  &= ~((1 << 12) | (1 << 14));
LPC_SGPIO -> CTRL_DISABLED &= ~((1 << 12) | (1 << 14));


LPC_SGPIO -> GPIO_OENREG |= (1 << 9) | (1 << 13); //SGPIO9 and 13 are active outputs

LPC_SGPIO -> REG[12] = 0x00000050;
LPC_SGPIO -> REG[14] = 0xffffff0f;

LPC_SGPIO -> REG_SS[12] = 0xffffffff;
LPC_SGPIO -> REG_SS[14] = 0xffffffff;

LPC_SGPIO -> PRESET[12] = 16;
LPC_SGPIO -> PRESET[14] = 16;

LPC_SGPIO -> COUNT[12] = 16;
LPC_SGPIO -> COUNT[14] = 16;

LPC_SGPIO -> POS[12] = 0x00000808;
LPC_SGPIO -> POS[14] = 0x00000808;

LPC_SGPIO -> CTRL_ENABLED  |= (1 << 12) | (1 << 14);
LPC_SGPIO -> CTRL_DISABLED |= (1 << 12) | (1 << 14);

[lpcware]

Content originally posted in LPCWare by Jeroen3 on Thu Oct 11 02:35:51 MST 2012
You should have a Exchange interrupt in which you can load the REG_SS register for the next data. When you only load one register and incrementing a counter in the interrupt, you should be able to make it, I think.

However, you've set CTRL_DISABLED so you need to manually restart the slices (since they have stopped when pos went 0). This probably causes the delay.

[lpcware]

Content originally posted in LPCWare by jgorsk on Wed Oct 10 09:27:43 MST 2012
I'm executing from the internal flash memory. It looks like the delays are casued by my program. I'll try to implement DMA transfers instead of using interrupts. That should solve the problem.

[lpcware]

Content originally posted in LPCWare by Jeroen3 on Wed Oct 10 00:05:11 MST 2012
Where do you execute from?

[lpcware]

Content originally posted in LPCWare by jgorsk on Tue Oct 09 10:54:03 MST 2012
Thank you Jeroen3, that makes sense.

I have another timing related problem. I'm trying to do a simple master SPI port
using SGPIO with just clock and data_out (MOSI) outputs. It's supposed to send
11 bits of data in each transmission. For the initial testing I decided to automatically
stop the shift registers when the transmission is finished (bits in CTRL_DISABLED register
corresponding to the slices used are set just after setting the corresponding bits in CTRL_ENABLED
register). I'm using SGPIO interrupt. Everything works but there are big gaps between consecutive
transmissions.  Some of that is caused by the SGPIO ISR but it looks like the interrupr is triggered
about 300ns after the end of a transmission. (SGPIO clock is 176MHz, SPI clock is 44MHz).I'm using
the exchange clock interrupt.

Is it supposed to work that way or is it an error in my program?

[lpcware]

Content originally posted in LPCWare by Jeroen3 on Tue Oct 09 00:26:07 MST 2012
User Manual 13.2 table 110 describes that BASE_SAFE_CLK is used for RGU delays. Which can be slower than your core speed.
Maybe you can try waiting for the RESET_ACTIVE_STATUS1 register?

[lpcware]

Content originally posted in LPCWare by jgorsk on Mon Oct 08 01:30:41 MST 2012
I think I found out what the problem was. Some extra delay is needed between
writing to RESET_CTRL1 register (to reset SGPIO) and writing to SGPIO registers.
The delay needs to be pretty long, definitely more than just a few CPU instructions.

It is very strange, I know that the extra delay helps but is it really solving the problem?
Can somebody in NXP Support explain why it works that way please? Timing may be crucial
in SPGIO applications which often work at high speed. Any timing constraints should be
clearly stated in the SGPIO documentation.

[lpcware]

Content originally posted in LPCWare by jgorsk on Fri Oct 05 09:17:59 MST 2012
I found an error in the program, SGPIO13 is clk out for slice J not O. I corrected the program but I'm still not getting the clock outputs