OCTOSPI as simple QUAD/Dual/Single parallel-to-serial output on STM32H5xx

[kojima]

Dear fellows,

I've been trying to use OCTOSPI just as serial-to-parallel I/F which is protocol-free, continously working...

I'm not intending to interface with any existing serial-memory devices. That's why I noted "protocol-free".

Intending just have an interval-time-stable output pins...

I suppose to make OCTOSPI protocol-free, AMODE, IMODE, ABMODE are to be set 0 and DMODE to be set for the number of pins to be employed, 0b001 for single pin, 0b011 for quad pins etc...

And additionally, I'm supposing only the following parameter settings are importantly required: 

indirect-write mode, DR=0xFFFFFFFF(a maximum), DEVSIZE=0x1F(maximum) .

Most of all others can be left as initial reset values, zero, I suppose. 

When I make a write access to DR register the data should go out on the pins ....

I've done and gotten success on the similar setting on STM32L4xx(not L4+)'s OSPI.

So, I guess also on STM32H5xx's OCTOSPI should work by similar setting. But, it did NOT...

As busmaster to make write access to DR, I've tried CPU instruction and GPDMA.

But, both bus master methos don't work as expected.

When I invoke those write-access continupusly , the SWD connection to the debugger will be lost somewhat...

SWD connection lost is very painful for me to make further analysis....

Anyway, is there any BIG changing in OCTOSPI from QSPI?

Are there some required parameter setting are missing to have the expected behavior?

Just as behavior comparison checks, I've tested with some DEVSIZE settings.

for DEVSIZE=0, it works, al least SWD connection is NOT lost.

for DEVSIZE=1, it works, at least SWD connection is NOT lost.

for DEVSIZE=2, it works for certain amout of time, but SWD connection will ne lost then,,,,

I hope those give some hints to the experts...

Does anypne have suggestions ?

[KDJEM.1]

Hello @kojima and welcome to the community;

Could you specify which STM32H5 you're using?

Do you have the same problem with single and octal communications?

I recommend you to look at the STM32H5 errata sheet and check the OCTOSPI errata. 

Thank you.

Kaouthar 

[kojima]

Thank you for your response.

I've been tresting on Nucleo 144 STM32H563ZI mounted.

DBGMCU_IDCODE: 0x10076484

One of the biggest reason why I use that board is that board is ETM-ready, which is very effective to analyze ANY kinds of communication made between external devices.

I'm considering to implement that same kind of ways on much smaller MCUs, such as STM32H523/533 etc..

Thanx

[KDJEM.1]

Hello @kojima,

Thank you for updating post.

What do you mean by "I suppose to make OCTOSPI protocol-free"?

When in regular-command protocol, the OCTOSPI communicates with the external device using commands. Each command can include the following phases:
• Instruction phase
• Address phase
• Alternate-byte phase
• Dummy-cycle phase
• Data phase
Any of these phases can be configured to be skipped but, in case of single-phase command, the only use case supported is instruction-phase-only.

Please refer to RM0481 precisely section 23 Octo-SPI interface (OCTOSPI) for AMODE, IMODE, ABMODE configuration.

Thank you.
kaouthar

[kojima]

You wrote:

> What do you mean by "I suppose to make OCTOSPI protocol-free"?

I understand that the peripheral IP "OCTOSPI" is designed much more than 1/2/4/8-lane SPI and is designed as highly flexible memory interface for various kinds of external serial memory devices, most of those devices require some kind of communication protocols with tight timing constrains.

But, what I'm trying is to utilize it just as 1/2/4-lane serial output-only interface.

To the practical serial memory devices, we have to take care about 'phase's, such as Instruction, Address, Alternatate-bytes, Dummy-cycle and Data. Along to those keywords, what I'm going to employ is Data phase ONLY.

And furtherly, I want ever-lasting, contiguous, endless data output on 1/2/4 lanes at constant rate and hopefully without ANY extra/illegular timing gaps. 

Thanx,

[kojima]

Dear staff,

I also checked errata sheet.

But, I could not find the issues which explain my trouble cases.

"2.5.7 Indirect write mode limited to 256 Mbytes" might be the one of those that related.

I read behind "2.5.7"  that OCTOSPI peripheral IP block is ALWAYS working some sorts of address range checking internally that considering "memory-mapped" mode's usage case.even if the FMODE setting is NOT memory-mapped.

So, if that ckecking condition is saticefiled (even if it is not the one that expected) OCTOSPI block issues some sort of reports to the MCU system.

Unfortunetely in my case, debugger connection thru SWD (which is a part of Cortex CPU IP block) is lost....

This is very SERIOUS to go on any development/evaluation steps...

I could not guess reasonable and acceptable reasons which explain this final phenomana.

If you ST staffs can imagine some "errata"-ble implemention facts behind, let me know, please.

Anyway,

I'm going to search for and try alternative ways that OSTOSPI do NOT destory SWD connection.

Thank you

[kojima]

Dear staff, 

I'd reported this in another thread and still working on analysis, solution and conpromise.

Solved: OCTOSPI as simple QUAD/Dual/Single parallel-to-ser... - STMicroelectronics Community

By my operation mistake on this site, that was marked "Solved", but not yet in reality....

So, I changed Subject and let start again in a new thread.

I've been trying utilize OCTOSPI just as 4-lane output-only parallel-to-quad interface pased stabelly by several built-in elements in OCTOSPI such as FIFO with threshold-level setting to CPU and/ot DMAC etc...

I'm not going to connect any kinds of existing serial memory devices externally to MCU.

Just for your imagination without prejudice, let me say, a very simple, *** circuitry such as R-2R radder works as tiny DAC and so on....

So, I do not need any phase tracking features built in OCTOSPI to support complex protocols used in serial memory devices flexibly. Data-phase-only everlasting output.

But, I gradually understand that OCTOSPI is not a "Octal-Serial/Parallel", it is designed as "serial memory controller" or "HyperBus interface" etc... So, the guy like me encounter many problems.

As I titled this thred, one of the unexpected serious problems is SWD lost.

I guess that OCTOSPI is always working with cares to keep transaction frame in certain limited length and should terminate to release the communication lines to the external devices.

The value setting on DEVSIZE and DL and phase/frame defining parameters and write access steps to DR register and to someother registers are tightly related, I suppose. If those proceed unexpectedly, OCTOSPI is going to terminate phase steps safely such as force relasing NCS etc....

I guess that as one of side-effects of that phase terminating steps made inside OCTOSPI may cause SWD lost.

This phenomena easily happens during repeating write access to DR by polling freeroom in FIFO.

I set FMODE as Indirect-write to make any write access sequence mainly to DR, with ADMODE, ABMODE, IMODE setting in CCR are ZEROs to skip corresponding phases CCR.DMODE is set b'011 to employing 4-lanes.

Depending on DEVSIZE and DL setting, total number of write access to DR, some particular conditions are saticefied inside OCTOSPI. Very roughly, as one of those might be a cause of SWD lost, I guess.

Total number fo write access (or actial number of bytes) to DR increments some virtual memory address kind of phase tracking activity made inside OCTOSPI and limitting or wrap-arounding are done by checking DL and DEVSIZE setting.

I'd done in the similart methods to QUADSPI in STM32L4xx (not L4+) with paticular value setting DL and FSIZE with there maximum and gotten success no promlem..

I'd started with DL as 0xFFFFFFFF expecting for 32bit fullbit wrap-arounding..

I've been doing the same evaluation/implementation steps also on STM32H563ZI(Nucleo 144).

Just for phenomena comparisons, I've tried several DEVSIZE from 0x1F down to 0.

SWD lost does not happen for DEVSIZE=0 and =1 cases.

SWD lost phenomena apprears from the value 0x02 to DEVSIZE setting at the certain number of write access to DR. I'd observed NCS forcingly deasserted and reasserted which inserts some additional time even in case where SWD Lost does not appear.

I guess, this NCS output behavior may indicates OCTOSPI is doing cheking total number of DR bytes and internal 'phase' resetting etc...

I undrerstand that on OCTOSPI, those limitting value fields are treated diffreently from those on QUADSPI.

and there are some errata introduced in "ES0565 -Rev.5" for setting DEVSIZE fields prohibitted to exceed 256Mbytes etc...

Anyway, "SWD Lost" is a very serious pit hole, debugger connection suddenly losts...

I would like to know the casing mechinism behind OCTOSPI to think about avoiding compromises..

Thank you.

[KDJEM.1]

Hello @kojima,

By my operation mistake on this site, that was marked "Solved", but not yet in reality....

--> I removed the accepted solution.

What is the OCTOSPI frequency? 

Are the OCTOSPI GPIOs configured to very-high speed?

Could you please share you project?

Thank you.

Kaouthar

[TDK]

You might need to explain your usage in more detail if you want useful feedback. Show your code, show what you're seeing on a scope, show what you're expecting to get.

OCTOSPI is a memory interface peripheral, it's not an extension of basic SPI so there is no "here's how to set it up as a basic SPI" procedure. You can send snippets of bytes using all lanes, but not by simply shoving data into DR as you would with a basic SPI.

[unsigned_char_array]

I've read all the posts in this topic and still don't know what you want.
What would you like to connect the MCU to? What protocol does this device use? What timing/frequency does this device work on? There is no such thing as a protocol free protocol.

Please share your code and your Logic Analyzer captures.