RE: Re: QSPI PCS drops on MPC563
Dobbin Allan-r11834 <[email protected]>
| Newsgroups | gmane.comp.hardware.motorola.microcontrollers |
|---|---|
| Message-ID | <45E41B46B1F8D81183E4000F20D7C40B0B5684F9@az33exm40-bu.am.freescale.net> |
OK, setting the CONT pin will just keep PCS asserted between transfers, but when the queue is finished, the QSPI turns itself off automatically by clearing SPE and that causes PCS to de-assert which is not what you want in this case. To keep the PCS asserted, you would have to do something in software to get round this. There are a few options and you'd have to experiment to see what worked: A) Assuming you have CONT=1 for all command words and want PCS asserted through all transfers as well as held asserted at end, set PORTQS data to the opposite value (i.e. asserted state) soon after the transfer starts i.e. after setting SPE. This means that PCS asserts and at end of queue, it reverts back to PORTQS which is now also asserted. On your final set of transnsfers when you want PCS to de-assert, switch PORTQS back to original (unasserted value) just after you set SPE at PCS will de-assert on final transfer. I think this is probably the best one for you to implement as it can be used with multiple sets of transfers easily and timing is handled easily. B) set the HALT flag while the final command is transfering. This prevents SPI from disabling and therefor PCS remains asserted. This method is more timing critical and the PCS will still deassert when you start the next command round unless you can use the HALT flag on a transfer that is not the final one. C) Make use of the WREN so that you wrap to the next transfer and then PCS remains asserted. This only works if you have next set of data loaded and ready to go before queue wraps. Regards, Allan -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Johnnie Blom Sent: Thursday, July 14, 2005 3:48 AM To: [email protected] Subject: [MPC500] Re: QSPI PCS drops on MPC563 Thanks for the input, I checked the things you point out, but still got the problem but perhaps it is not possible to do what I want (but did not give a good description) I want the PCS to be asserted even after I leave the last position in the queue and remain like that until the next time I run the queue. Regards Johnnie Blom --- In [email protected], Dobbin Allan-r11834 <Allan.Dobbin@f...> wrote: > If CONT=1, PCS should remain asserted i.e. same value as you have in PCSx in command RAM. If CONT=0, PCS will return to PORTQS value as this is the base (unasserted value) of the PCSx. > > Make sure you are using as master, set relevant bits in PQSPAR and DDRQ. Write opposite value to PORTQS (unasserted value) as to command ram (asserted value). > > Regards, > Allan > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of Johnnie Blom > Sent: Wednesday, July 13, 2005 6:59 AM > To: [email protected] > Subject: [MPC500] QSPI PCS drops on MPC563 > > > Hello, > I have a problem with the Periferal Chip Selects (PCS) on the QSPI module of MPC563. > The problem is that the PCS is dropped (returned to PORTQS) when transfer is complete even when the CONT bit is asserted. Are there anyone who knows what could be the reason to this? > > Best regards > Johnnie Blom ----------------------------------------------------------- To learn more about Freescale Microcontrollers, please visit http://www.freescale.com/mcu Yahoo! Groups Links ----------------------------------------------------------- To learn more about Freescale Microcontrollers, please visit http://www.freescale.com/mcu Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/MPC500/ <*> To unsubscribe from this group, send an email to: [email protected] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/