Skip to main content
s m
s m
Associate III
May 19, 2018
Solved

STM32L4R9I-EVAL OctoSPI problem with 8bit access

  • May 19, 2018
  • 9 replies
  • 2152 views
Posted on May 19, 2018 at 22:56

Hello,

I am currently using the OctoSPI RAM on the STM32L4R9I-EVAL board (IS66WVH8M8BLL-100BLI (Hyperram)).

At first sight everything looks as expected, but when I read and than write with 8 bit access, only every second write is successful.

I changed the code of the OSPI_RAM_MemoryMapped as follows to show the problem:

while (1)

  {

    BSP_LED_On(LED_GREEN);

    /* Writing Sequence ----------------------------------------------- */

    mem_addr = (__IO uint8_t *)(OCTOSPI1_BASE);

    for (index = 0; index < 1024; index++)

    {

      *mem_addr = (index & 0xff);

      mem_addr++;

    }

    

    /* Reading Sequence ---------------------------------------------- */

    mem_addr = (__IO uint8_t *)(OCTOSPI1_BASE);

    for (index = 0; index < 1024; index++)

    {

      if (*mem_addr != (index & 0xff))

      {

        BSP_LED_On(LED_ORANGE);

      }

      mem_addr++;

    }

    /* Reading/Writing Sequence ---------------------------------------- */

    mem_addr = (__IO uint8_t *)(OCTOSPI1_BASE);

    for (index = 0; index < 1024; index++)

    {

      if (*mem_addr != (index & 0xff))

      {

        BSP_LED_Off(LED_GREEN);

        while(1)

            ;

      }

      *mem_addr = 0;

      if ( *mem_addr != 0 )

      {

          BSP_LED_On(LED_RED);

          //while(1)

              ;

      }

      mem_addr++;

    }

  }

During debugging and inspecting the memory region 0x90000000, the problems is visible.

When changing mem_addr to an uint16_t or an uint32_t everything works as expected.

Even when adding directly after '*mem_addr = 0;' the same statement again; thus writing twice to the same location, it works.

I need some advise to understand and hopefully fix that problem.

Thanks.

#stm32l4r9 #octospi #stm32l4+ #hyperram
This topic has been closed for replies.
Best answer by s m

ST confirmed that this is a bug;

you find the description in

https://www.st.com/content/ccc/resource/technical/document/errata_sheet/group0/ef/74/70/f6/89/a9/42/3f/DM00371862/files/DM00371862.pdf/jcr:content/translations/en.DM00371862.pdf

Chapter: "2.7.11 A memory-mapped write request with only one-byte length at odd-start address finished by any event is masked".

Thus, the octospi interface cannot be used as direct ram replacement when 8 bit access is required.

Nevertheless, when using uint8_t or derivates, this is likely happening.

Using the indirect mode instead will not be possible for such a case!

9 replies

Andreas Bolsch
Andreas Bolsch
Lead III
May 20, 2018
Posted on May 20, 2018 at 10:43

The HyperBus is in fact a 16-bit transport protocol, although each 16-bit word is split into two bytes, cf. 'HyperBus Spec.', document 001-99253. That's probably due to DDR, one byte clocked at each *edge*. Same issue with Quad-SPI interface if you use DDR. So you simply can't use byte accesses at all.

s m
s mAuthor
Associate III
May 20, 2018
Posted on May 20, 2018 at 13:23

Well I am not familiar with the HyperBus specification but that would be a huge problem when using HyperRAM as general RAM replacement. Therefore I can't really believe it or maybe I do not want to believe it ...

  1. During write data transfers, RWDS indicates whether a data byte is masked (prevented from changing the byte location in memory) or not masked (written to memory). Data masking may be used by the host to byte align write data within the memory or to enable merging of multiple non-word aligned writes in a single burst write. During write transactions, data is center aligned with the clock.

Why can I read 8 bit aligned but when writing not? By data masking it should be possible but how the memory mapping and octospi is working on the STM32, I do not know.

Hopefully, some ST employee is able to give more information about this.

Andreas Bolsch
Andreas Bolsch
Lead III
May 22, 2018
Posted on May 22, 2018 at 15:40

You're right, in theory it should be possible. But there a few obstacles:

- When using indirect read/write, the address sent is taken from the OCTOSPI's address register. The RM says that bit 0   must equal 0, so it is impossible to write or read bytes with odd addresses individually.

- When reading (indirect or memory mapped) RWDS is an output of the memory chip, so only 16-bit words can ever be read. The OCTOSPI can discard the unwanted byte, of course, but only in memory mapped mode.

- When writing RWDS is an input, so this may be used as a byte strobe for writing individual bytes, but only in memory mapped write. In this case, there must be an additional latency between  command/address and data phase. That's the required turn-around time for RWDS signal (cf. e. g. data sheet S27KL0641/S27KS0641, '3.4 Write Transactions with Initial Latency' vs. '3.5 Write Transactions without Initial Latency'). So you may check whether the latency reg. in OCTOSPI is set up properly. But even if so, the fact that bit 0 in AR must be kept at zero strongly suggests to me that byte write is simply not (fully) implemented. For good reason: Because if you write two bytes, even, odd, in succession, should those be written in two individual write cycles or in one cycle? Some sort of timeout mechanism would be required. Or the actual write cycle always occurs only after the odd byte has been written.

So, I wouldn't rely on being able to use byte accesses at all. At least, byte accesses would be rather inefficient.

s m
s mAuthor
Associate III
May 22, 2018
Posted on May 22, 2018 at 18:50

@

Bolsch.Andreas

Thank you for your detailed answer. Of course 8-bit access is far away from being efficient. But when the SRAM is used as frame buffer, at least some frameworks are using 8-bit access for manipulating the data.

I opened a technical case to get info from ST.

Regardless, if there is a limitation, it should be noted, as it is then not a 1:1 replacement for a parallel SRAM.

s m
s mAuthor
Associate III
June 5, 2018
Posted on June 05, 2018 at 17:13

st.mcu

‌

I also opened a technical ticket for this issue, but until now, I didn't get any response.

Will you investigate and clarify this issue?

Amel NASRI
Amel NASRI
ST Technical Moderator
June 6, 2018
Posted on June 06, 2018 at 12:51

Hi s m,

Did you tried the example STM32Cube_FW_L4_V1.11.0\Projects\STM32L4R9I-EVAL\Examples\OSPI\OSPI_RAM_MemoryMapped without modification first?

It is using 8-bit access for reading and writing and interfacing with HyperRAM memory. Do you have same issue?

It will be helpful also if you can share the ID of your technical ticket.

-Amel

To give better visibility on the answered topics, please click on "Best Answer" on the reply which solved your issue or answered your question.
s m
s mAuthor
Associate III
June 17, 2018
Posted on June 17, 2018 at 22:42

Dear Amel,

the ID is TECH051928.

As I posted in the original text, everything works as expected with the supplied example from STM.

Nevertheless, the 8 bit access is just writing everything, than reading everything.

Thus, the problem does not arise. It only happens, if just a single 8 bit value is changed.

So mixing writing and reading while having 8-bit access.

Please see the attached C-code above.

s m
s mAuthor
Associate III
June 26, 2018
Posted on June 26, 2018 at 08:49

Dear

st.mcu

,

I posted all the information above and updated also the case.

Is there any chance that I will get an answer in the next days?

Thank you.

s m
s mAuthorBest answer
Associate III
August 26, 2018

ST confirmed that this is a bug;

you find the description in

https://www.st.com/content/ccc/resource/technical/document/errata_sheet/group0/ef/74/70/f6/89/a9/42/3f/DM00371862/files/DM00371862.pdf/jcr:content/translations/en.DM00371862.pdf

Chapter: "2.7.11 A memory-mapped write request with only one-byte length at odd-start address finished by any event is masked".

Thus, the octospi interface cannot be used as direct ram replacement when 8 bit access is required.

Nevertheless, when using uint8_t or derivates, this is likely happening.

Using the indirect mode instead will not be possible for such a case!

Terms & ConditionsAccessibility statement