• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 32 subscribers
  • Views 151 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM2432: Issue during copy of data from secondary flash on MCSPI to primary flash on OSPI.

Peta
Prodigy 30 points

Part Number: AM2432
Other Parts Discussed in Thread: UNIFLASH, SYSCONFIG

Hi,

we are using AM243x with a custom QSPI flash A (GigaDevice GD25Q64E) on OSPI interface. We already created a custom flasher_jtag_uniflash project for programming the flash with uniflash tool and a custom sbl to copy the application from the custom flash to RAM. This works already pretty well. Also writing to flash in sbl is ok.

In a first step, for a firmware upgrade process, I copy a firmware image from a location in flash A to another location in flash A and vice versa. This is done sector by sector and works without issues.

In an second step, we connected a 2nd custom flash B of the same type (GigaDevice GD25Q64E) on MCSPI (SPI2). Aim is to copy the firmware image from a location in flash B to a location in flash A and vice versa. For copying I use the same code except the driver to read/write from/to flash B because it is connected via MCSPI and not via OSPI interface.

Now, in the mentioned setup I run into the following issues during write to flash A (OSPI):
In OSPI_waitIndWriteComplete() the code cannot detect the completion of the process and returns with error. Now, I suspect communication by MCSPI to somehow disturb communication to OSPI. But I cannot figure it out. MCSPI and OSPI never act parallel. Do you have any ideas what might go wrong in this setup? What is shared between both peripherals? DMA?

For reference I added the syscfg file.

Thanks in advance and best regards,
Peta

example.zip 

  • 0
    TI__Guru 63518 points

    Hi Peta,

    I have assigned your thread to our domain expert. Please expect response in a day or two.

    Regards,

    Tushar

  • 0
    TI__Guru 58125 points

    Hi,

    I would like to know if with the following configuration which you mentioned:

    Peta said:
    In an second step, we connected a 2nd custom flash B of the same type (GigaDevice GD25Q64E) on MCSPI (SPI2).

    Q1. Are the MCSPI reads working when reading from Flash B into a local RX Buffer?

    Q2. I think it should not, given QSPI protocol formatting is different than MCSPI protocol. If it works, let me know how you are achieving successful reads?

    Peta said:
    Do you have any ideas what might go wrong in this setup? What is shared between both peripherals? DMA?

    Allow me sometime to review the attached SysConfig file, and update you in sometime.

    Regards,

    Vaibhav

  • 0 in reply to Vaibhav Kumar
    Prodigy 30 points

    Hi Vaibhav,

    Thank you for responding.
    Q1: Yes. Reading from flash B via MCSPI works fine.
    Q2: I use our own routines with flash commands suitable for GD25Q64E like "Read Data" (0x03).
           These routines make use of     MCSPI_transfer() of the TI driver code.

    Regards,
    Peter

  • 0 in reply to Peta
    TI__Guru 58125 points

    Hi Peta,

    I see that in your SysConfig file, you have certain pins in GPIO which are declared under MCSPI section as well. Are you aware of the same? This will cause resource allocation issue for the pins.

    Please let me know your thoughts.

    Regards,

    Vaibhav

  • 0 in reply to Vaibhav Kumar
    Prodigy 30 points

    Hi Vaibhav,

    Do you mean CS? I'm controlling CS by software. So far I did not understand how to keep CS activated by MCSPI peripheral over hundreds of bytes. But this is another story. Maybe you can give me a hint here, too. But I don't think this is related to the mentioned issue.

    I think I found the issue with OSPI/MCSPI: I think I have a buffer overflow during MCSPI transfer and this overwrites some stuff related to OSPI, gOspiObjects for example. I think you can stop your investigation. Thank you for your help. 

    Regards,
    Peta