SQI protocol on i.MX RT1060 FlexSPI and memory mapped access

cancel
Showing results for 
Search instead for 
Did you mean: 

SQI protocol on i.MX RT1060 FlexSPI and memory mapped access

346 Views
Mysterion
Contributor II

For an EtherCAT application, my task is to operate a LAN9252 EtherCAT Slave Controller (ESC), which will be connected via a quad SPI connection to a i.MX RT 1060 platform.

My intention is to overlay the MCU address space with the ESCs register content, allowing for a memory mapped read/write access via the AHB bus, which - basically - should be possible using FlexSPI, if my understanding is right (I'm completely new to the i.MX series and not familiar with the FlexSPI module at all)?

The ESC supports several SPI modes, including SQI, where not only data, but also command and address information make use of all four lanes. Is there any way of configuring the FlexSPI LUT in order to support the SQI protocol?

I found AN12239, which comes close to my purpose (albeit using octal mode, and being specialised for HyperRAM), but the basic character is the same. Is there any example of how to configure FlexSPI for SQI mode?

 

Labels (1)
Tags (3)
0 Kudos
7 Replies

248 Views
Mysterion
Contributor II

Dear Jeremy,

FlexSPI and eDMA are up and running fine now, however I'm wondering, if IPBus access in fact is the adequate way to keep to.
The stack doesn't do huge block transfers, but seems to access the ESC address space even bytewise in some cases. Therefore I'm still wondering, if my initial idea of a adress overlay wouldn't be a better fit.

You mentioned, that could be too hard to make; did you think of some concrete issues I'd have to expect? As far as I see, the MPU needs to be configured properly, and the FlexSPI needs to know the sequences to call for reading and writing. So wouldn't that be a feasible yet not too complicated way?

0 Kudos

239 Views
jeremyzhou
NXP TechSupport
NXP TechSupport

Hi
Thanks for your reply.
1) Did you think of some concrete issues I'd have to expect? As far as I see, the MPU needs to be configured properly, and the FlexSPI needs to know the sequences to call for reading and writing. So wouldn't that be a feasible yet not too complicated way?
-- Let me explain my suggestion, firstly, the either AHB read or write operation is implemented by executing the LUT table’s command sequence, and the IP command mechanism is also can execute the LUT table’s command sequence.
Second, AHB read or write requires contiguous address space, however, the IP command mechanism hasn't this restriction.
So back to your question, the address of ESC registers are continuous, you can give use the AHB access way a try.
Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

 

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos

284 Views
Mysterion
Contributor II

Hi,

1) is not only a typo - there is no such flag in any of the MCR registers providing this kind of functionality

Knowing about the FIFO behaviour is essential for me, as I'm doing a low level abstraction in C++, and need to know how to operate it. Unfortunately, this is not clear from the reference manual.

What I found out: the FIFO seems to rotate its content by watermark steps each time, the watermark flag is cleared by W1C. Therefore, the correct way to push/pop data to/from it, is to do that from DR[0] by chunks of watermark size.

Just a few sentences of explanation in the manual would have saved me and my colleagues several hours of poking around in the mist. I love this platform, however I need to say: the documentation - despite its quantity of 3500 pages - the documentation is quite disappointing in quality.

 

0 Kudos

278 Views
jeremyzhou
NXP TechSupport
NXP TechSupport

Hi,
Thanks for your reply and sorry for bring inconvenience to you.
1) In my previous reply, I forgot to upload a figure which shows the MCR0 register and I'll report the error to the document team.

jeremyzhou_0-1616739346191.png


2) To be honest, sometimes, I also have some complaints about the RM, anyway, please create a post if you encounter any problem when developing the RT MCU, we'll help you out.
Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

 

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos

302 Views
Mysterion
Contributor II

Dear Jeremy,

thanks for your answer. I've been able to setup the LUT in a way, it should be able to setup the slave device in SQI mode, and transfer data via SQI protocol, heeding your advice to go with IP access. And I'm really excited about the way, the peripheral is designed in order to offer maximum flexibility. 

Now, however, I'm struggling with the IP RX/TX-FIFOs, and - no offence! - the i.MXRT1060 reference manual, which not only stands out by misleading wording (eg. the term "sequence number" instead of a much clearer "number of sequences"; at least "xxx number" used in a consistent way over the document), but seems to be incorrect and incomplete in many ways, e.g.
- 27.5.9.1: "If MCR0[ARDFEN] is set to 0x1," - there is no bit ARDFEN in register MCR0!
- 27.7.2.22.4: "The write address to IP RX FIFO should roll back to the start address of write window after
pushing IP TX FIFO by writing-one-clear to INTR[IPTXWE]" - shouldn't the TX FIFO roll back in that case?

 

Concerning the FIFO - as described in the manual, and the way it's used in the MCUExpresso framework, this doesn't look like a FIFO at all, but more like a kind of buffer used in a rather complicated manner.

In my opinion, for transmitting data, it doesn't make too much sense to set up a watermark level, fill the TX FIFO up to this watermark level, waiting until the data has been consumed completely, reset the TX FIFO, fill in the next chunk and so on. That's what one would do with a conventional buffer, and in that case, it doesn't make sense to limit the buffer size by a watermark, as the sole effect would be an increase of loops neccessary for transmitting the same amount of data, just in smaller chunks.

Even worse when receiving data: if one waits until a watermark has been reached, then picking up the fifo's content [0..watermark[, there is a certain chance of further data arriving while processing [0..watermark[. Resetting the RX fifo at this point will lose exactly this additional data received in the meantime. The risk for this constellation to occur might be low on a 600MHz machine - but usually a FIFO is dedicated to avoid this very constellation.

So I'm racking my brain if there is any reason to not making use of the FIFOs as they usually are intended for, taking the watermark as well as the IP FIFO status registers into account, which indicate the actual fill level. Any FIFO I've ever dealt with, wraps around it's data pointer automatically after having read or written the buffer's last byte (or in ths case: the last 64 bit). Everything you should have to do, is picking up the accumulated data from time to time, indicated by reaching a watermark level, providing a yet convenient time window for that job, without risk of an data overflow.

Unfortuntely, the reference manual doesn't describe the FIFOs behaviour concerning wrap around (at least, I didn't find anything about that), and doesn't specify, whether the watermark refers to a certain position within the FIFO data registers, or to the FILL field in the FIFO status registers.

Currently I can't even explore the behaviour through experimens, as my hardware will not arrive for a few more week. Could you please check if the FIFO shows some limitation or hardware bug, preventing the usual type of access, or if the documentation is just incomplete, and the provided drivers being... well... not so sophisticated as could be?

Regards
Mysterion

 

0 Kudos

288 Views
jeremyzhou
NXP TechSupport
NXP TechSupport

Hi,
Thanks for your reply.
1) - 27.5.9.1: "If MCR0[ARDFEN] is set to 0x1," - there is no bit ARDFEN in register MCR0!
-- There's a typo in the RM of the RT1060.
2) 27.7.2.22.4: "The write address to IP RX FIFO should roll back to the start address of write window after
pushing IP TX FIFO by writing-one-clear to INTR[IPTXWE]" - shouldn't the TX FIFO roll back in that case?
-- Yes, your understanding is right.
2) Could you please check if the FIFO shows some limitation or hardware bug, preventing the usual type of access, or if the documentation is just incomplete, and the provided drivers being... well... not so sophisticated as could be?
-- In my opinion, the hardware FIFO is manipulated by the CPU automatically in addition to code, for instance, the push for RX FIFO and pop for TX FIFO are in charge of the CPU.
So it's not necessary for developers to explore the mechanism of the FIFO, for us, we should focus on the build an appropriate water level to monitor the data in the FIFOs, then we can read from or write data to FIFO prior to overflow or underflow event happen.
Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

 

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos

335 Views
jeremyzhou
NXP TechSupport
NXP TechSupport

Hi,
Thank you for your interest in NXP Semiconductor products and for the opportunity to serve you.
1) My intention is to overlay the MCU address space with the ESCs register content, allowing for a memory-mapped read/write access via the AHB bus, which - basically - should be possible using FlexSPI, if my understanding is right (I'm completely new to the i.MX series and not familiar with the FlexSPI module at all)?
-- In my opinion, it's too hard to make it, and IP command may be a better option to access the registers in the ESC. So I'd highly recommend you to go through the FlexSPI module chapter in the RM as soon as possible.
2) Is there any way of configuring the FlexSPI LUT in order to support the SQI protocol?
-- According to RM, the FlexSPI should support the SQI protocol, and please refer to Table 27-7. Instruction set in the RM to learn how to configure the sequences in the LUT table.
3) Is there any example of how to configure FlexSPI for SQI mode?
-- There're some FlexSPI demos in the SDK library, and you can refer to them for details now.
Hope it helps.
Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

 

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos