• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 31 subscribers
  • Views 364 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.

AM2634: QSPI Flash address wrapping around over 16 bit addressing

Barna Csenteri
Expert 1880 points
Part Number: AM2634
Other Parts Discussed in Thread: UNIFLASH

Tool/software:

Hi

The flash used is the one the LP Devboard - the 16Mbyte S25FL128SAGNFI000, same syscfg as it is in the flash examples provided by TI. Addressing mode 4 byte is not enabled.

What I noticed that if I write something in to address 0x00040000 I can read it out from 0x00040000 but the same content will appear at 0x00840000.
Written in specific patterns and it is the same 0x00040000 and at 0x00840000 while only 0x00040000 was written with Flash_write TI driver call.

Both addresses are below 16M, this wrap around should not happen.

Followed the code which calls Flash_read and it reaches QSPI_spiMemMapReadDma and the mapped address is 0x60840000 which seems to be correct.

QSPI_edmaTransfer/edmaParam.srcAddr is still 0x60840000.

It is working ok with addresses <= 16 bit, the image written there it is ok, I can boot with TI SBL example from the given address.
The problem starts with 24 bit (in theory it should not, 3 byte addressing should work at 0x00840000 too).

The code itself is coming from the bootloader and QSPI flash examples, syscfg is not altered whatsoever.

Is there any 16 vs 24 bit limitation due to DMA transfer I am not aware of?

EDIT: checking more carefully it is not even 16 bit since 0x00040000 is already over 16 bit, the problem is rather with the upper bit of the 24 bit address (0x00840000).

EDIT2: I have current date-time as string and a special character seq to identify the entry in the flash - I used the UNIFLASH read and it seems I have duplicate data:

0x60040000 F8AD1BC2 0000FFFF 30320001 32313432 38303530 36333935
0x60840000 F8AD1BC2 0000FFFF 30320001 32313432 38303530 36333935

0x60240000 F8AD1BC2 0000FFFF 30320003 32313432 39303530 38333430
0x60A40000 F8AD1BC2 0000FFFF 30320003 32313432 39303530 38333430

0x60340000 F8AD1BC2 0000FFFF 30320002 32313432 38303530 38323135
0x60B40000 F8AD1BC2 0000FFFF 30320002 32313432 38303530 38323135

but it is not possible to have the same date twice (date changes always and I never touched the upper part of the flash - last header was written into 0x60340000).

The issue is the last bit of the 24 bit address (0x800000). 

Best regards

  • 0
    Expert 1880 points

    I did repeat the test with the LP devboard and uniflash (no customer code involved) and the results are the same.

    I did made a small file with a specific pattern:

    Loaded it in:

    Reading out uniflash memory:

    0x60040000 33323130 37363534 61303938 65646362 00000066 00000000 00000000 00000000
    0x60840000 33323130 37363534 61303938 65646362 00000066 00000000 00000000 00000000

    My "01234567890abcdef" string pattern is there on both addresses (0x33323130 = '3210')

    There is no 8M paging and extended addressing should not be needed for 16M flash so I can't explain why this happens.

  • +1 in reply to Barna Csenteri
    TI__Expert 3220 points

    Hi Barna Csentri,


    Sorry for the delay,

    There is a HW errata surrounding memory mapped access to addresses above 8MB in QSPI. Address lines going out from SoC interconnect to QSPI controller are 23. Hence this limits the usage of QSPI flash memory to 8MB per chip select in memory map mode. Although, in config mode (/Indirect Access mode), the flash can be accessed for entire 4GB.



    Please find the details of errata here https://www.ti.com/lit/er/sprz488e/sprz488e.pdf 

    Thanks and Regards,
    Rijohn

  • 0 in reply to Rijohn Pius
    Expert 1880 points

    Hi

    So for SBL which needs fast data rate (mapped mode DMA) we are stuck with 8Mb. Am I correct?

    What do you mean with config mode? 

    Is it possible to use the first 8Mb for SBL using the current flash drivers in mapped mode and the firmware (which will not needs to access the first 8Mb) to use the upper 8M for storage (configuration data) with a different driver? Does the SDK permits this? If yes are there any examples available or at least the config mode driver is available? 

    Best regards,
    Barna

  • 0 in reply to Barna Csenteri
    TI__Mastermind 44834 points

    Hi Bama,

    Config mode is used to connect to serial SPI devices.

    You can read more about this in TRM section: 13.3.4.4.1 QSPI Block Diagram

    Also we have SDK APIs which allows you to switch between the modes:

  • +1 in reply to Nilabh Anand
    TI__Mastermind 44834 points
    Barna Csenteri said:
    Is it possible to use the first 8Mb for SBL using the current flash drivers in mapped mode and the firmware (which will not needs to access the first 8Mb) to use the upper 8M for storage (configuration data) with a different driver? Does the SDK permits this? If yes are there any examples available or at least the config mode driver is available? 

    This is possible. But we do not support read and write APIs for Config mode now. It is planned for future SDK release. you will need to do this in application for now. It will be like a SPI cmd that states where to write/read then memory and data and size. This sequence is mentioned in TRM section  13.3.4.4.1.3 SPI Control Interface