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 ?

[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

[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

[kojima]

Thank you for your response.

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

I'm driving STM32H563ZI on Nucleo 144 with root clock source by HSI and PLL.

250MHz is fed as system clock frequescy.

>What is the OCTOSPI frequency? 

25MHz prescaled by setting for OCTOSPI's PRESCALER.

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

Yes, they are.

>Could you please share you project?

In this public area or just to ST ?  Let me consider for several days by some reasons....

Before to do it, I had better inform about my project format and IDE situations.

I'm using Keil MDK both Professional edition and Community edition (formaly called "MDK Lite").

I know that ST has been providing paticular "ST-Edition" based on MDK-Lite from Keil with relaxed features than Keil's but for limitted target only among ST MCUs.

For Cortex-v8M products, I'd tested with MDK Community-Edition with ST-Edition license, but that environment does not allow to make a build for ST's Cortex-v8M including STM32H5xx series.

So, now I'm using generically installed MDK ARM Community-Edition.

I do not use CubeMX and HAL in general. Trying to make it as simple as possible, espacially to forcus on the hardware component blocks implemented in targetted MCUs without any workarounds made by historical reasons thru the STM32 series families. By the same reason, I do not use CubeIDE. Sorry.

Is that format of project acceptable for you ST people ?

Thanks

[kojima]

Thank you for your response.

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

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

Thanks for your commentes.

I guradually learned the same..

OCTOSPI seem very far beyond QUADSPI found in STML4 generations'.

Thank you.

[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