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

[kojima]

I'm feeding clock to OCTOSPI from system clock running at 250MHz, origined from HSI thru PLL.

OCTOSPI's frequency is set at 25MHz by setting of PRESCALER as 9 (=10-1) in DCR2 register.

I'd also tested with 200MHz --> 20MHz, but the same result.

>Are the OCTOSPI GPIOs configured to very-high speed?

Sure, i set corresponding pis for very-high-speed.

 

>Could you please share you project?

A great proposal. Thank you so much.

I think I can.

But, it may take sevaral days. Because, I'd already proceeded to test the other features for OCTOSPI and GPDMA.

So, the project and codes are including some other trials, a llittle bit complicated...

My project is in Keil MDK format.

I've been testing by both comercial edition and Community-Edition generically-installed.

(Not by ST-Edition. because ST-Edition did not allow compliation for Cortex-M33)

Let me consider about sharing here...

 

Re-genarating the project from the scratch might be much easier to replay the phenomena.

 

Thanks

 

[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.

[kojima]

Thank you for your short-summary followup

.

> it's not an extension of basic SPI so there is no "here's how to set it up as a basic SPI" procedure. 

I gradually learn the same...

 

Thank you

[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.

[kojima]

Thank you for your response.

Sorry for my delay of response due to my accidental Internet connection problems..

 

>What would you like to connect the MCU to? What protocol does this device use? What timing/frequency does this device work on?

 

I can understand your annoyments (sorry), confusions and interrests 

 

This is one of my generic fundamental experiments to evaluate as may as MCUs and peripheral IPs newly introduced.

 

If I answer to your questions to help everybody have the same image,,....

how about "VGA controller" application to connect analog VGA display monitor?

 

Timing-stable parallel-to-serial output feature is required to generate video image.

If I could prepare a combination of PWM timier output for generating Hsync and Vsync, then I try to set

frequency for parallel-to-serial functioning portion in reasonable ratio to those PWMs. 

If I could prepare those basic functions working synchronously in expected timings, then I can see the behavior of Parallel-to-Serial functioning portion as a visible display image on monitor screen.

If that VERY portion is not able to generate contiguous signal output seamlessly in timing without any extra time duration, we can find some limitations in that portion loss or extra time duration should be accepted to our final future application. 

 

As you might imagine, I hope, then in the further steps those tests will be made by emlopying the other busmasters than CPU, such as DMA controllers etc... Those busmaster can issue more dense bus transactions, such as so-called "burst". At this step, we can see busmatrix pathway characteristics and peripheral-side's improved features such as dedicated FIFO elements, capable for more efficient bus traffic management or not...

And, also by DMAC and supported trigger/request source variations, scenarion variations that supported by DMAC bus masters such as Linked-List capabilities etc...

One of the better cases, we may let leave the any loads off the CPU, let them done by DMAs etc...

 

During this evaluation steps, in this case,OCTOSPI is going to be tested to generate contiguous data output and its wave forms, checking that is seamlessly contiguous or some extra signal duration appears periodically

Simple and very early stages to do for data supply to OCTOSPI is done by simple polling done by CPU execution, a "pasty" approach. Then, emloyment for DMAC will be tested, in place of executions made by CPU and  instructions sequences for the CPU...

 

The problem I encounterd appeared in very early stages with such "pasty" approach for data supply.

Maybe, some RANGING features built inside OCTOSPI is working behind contiguous data putput.

So, I'm on the way to try with sevaral setting values for DEVSIZE and DL.

 

Sudden connection lost between the MCU and debugger thru SWD is a very BIG impact.

I could not find any reasonable explanation arround this behavior.

Why mere a bus peripheral can make such an essential impacts to CPU ?

Maybe, some of my *** understanding about OCTOSPI is the one of the originall causing triggers..

I would like to know what and how this happens to keep SWD ever working expectedly.

 

Thank you

 

#Parallely, I'm going to try jumping to further steps to employ GDMAC, removing jobs done by CPU completely from regular data supply activities to OCTOSPI.

 

 

[unsigned_char_array]

That's a creative use for that peripheral! It's not designed for that, but you can probably make it work. You would need some additional hardware obviously.
How do you propose to connect it? 1 bit to each color channel? And then pulse those pins and filter them with an RC-filter to get more than 1 bit per color? In that case I would not use PWM, but Delta-sigma modulation. Or do you want to use more than 1 pin per color channel? H-sync and v-sync pin too?

I suggest you start simple and do 1 bit black and white. So tie all colors to the same pin and do not modulate it. If you can get that working start adding colors.

Use the lowest frequency you can so you can capture it with a logic analyzer. If the signals look good you can increase the frequency.

Here is an example project I found: https://hackaday.io/project/196282-1080p-on-an-stm32-microcontroller