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.

AM263P4-Q1: UniFlash Feature Request : Memory Read of OSPI Flash

Part Number: AM263P4-Q1
Other Parts Discussed in Thread: UNIFLASH

Hello,

I'm trying the Memory feature in UniFlash 9.3. Reading of OCRAM seems OK but not for OSPI flash.

I'm expecting the ELF magic numbers at 0x60081000 but I just get zeros:

Unlike flashing operation, I noticed that no program (e.g. flasher.out) is downloaded in the log file. I guess that would be required in order to report the OSPI memory contents.

Please can you add this facility?

  • Hi Kier,

    Reading the RAM data is possible because the memory is present on-chip, thus it is possible to read it via JTAG/debugger

    As you already know that AM263Px is an external flash device, so unless OSPI is properly initialized, it is not possible to access the external flash memory.

  • The memory read feature in Uniflash, underlying implementations is based on JTAG, thus it would not be possible to implement memory read directly.

    However once you flash sbl/app using  the Uniflash, it loads the the flasher program(flasher_jtag.out), which does the actual writing to flash, then you will be able to read back the flash content via memeory browser as OSPI gets initialized by it(i.e DAC mode is enabled_), then you might be able to view the flash memory content.

    We had a discussion with our tools team about this, the limitation is due to external flash device

  • thus it would not be possible to implement memory read directly.

    Hi Nilabh,

    Yes, that's understood. My suggestion hints that you could download a "memory_read.out" file before doing an Memory Read in same way that flasher.out is downloaded before doing a flashing session. I see no real difference in the workflow.

    the limitation is due to external flash device

    I think you've done all the hard work already implementing a flasher.out. Simply initializing and reading OSPI should be straightforward in comparison.


    I understand if you decide not to do this based on a lack of demand or effort required but I really don't think there's any technical barrier here.

  • I agree, Kier, the limitations is not really from a technical perspective, but more of how the tool handles it and also the overall effort, as you mentioned. Appreciate the understanding.

    I will create a backlog ticket for this for future consideration.