• State TI Thinks Resolved
  • Locked Locked
  • Replies 19 replies
  • Answers 2 answers
  • Subscribers 31 subscribers
  • Views 503 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

MCU-PLUS-SDK-AM243X: loadCpus sometimes asserts in DMA access

Fabian Sorkalla
Prodigy 220 points
Part Number: MCU-PLUS-SDK-AM243X

Hello,

currently we are facing some issues in our bootloader which is based on the SBL OSPI bootloader. Sometimes the we get an assert here:

Which should be the following assert in ospi_dma_udma.c:

In what cases can this assert be thrown?

Since this is randomly appening on bootups what can we do against it?

Just repowering the board helps. I made a temporary fix where the asserts triggers a (software-)restart which is also fixing this issue. But we would still like to fix the issue at the root.

BR Fabian 

  • 0
    TI__Mastermind 26025 points

    Hi ,

    Apologies for inconvenience. But if this issue is visible on am243x-evm, can you share the updated example code to us ? We would like to root cause this.

    In my first guess, this looks like a custom flash device and the custom flash driver software. Is your dummy reads correctly set ? Can you share more information on this ?

    Best Regards,
    Aakash

  • 0 in reply to Aakash Kedia
    Prodigy 220 points

    Hi Aakash,

    thanks for the hint. I will check this again. 

    Is this assert thrown because of some specific failure or is it a general assert with many root causes?

    Fabian

  • 0 in reply to Aakash Kedia
    Prodigy 220 points

    Hi Aakash,

    maybe you can verify the values we use, so we are sure they are set correctly. 

    We are using these flashes:

    1. IS24WX256 https://www.issi.com/WW/pdf/25LX-WX256-128.pdf

    2. GD25LX256E https://www.gigadevice.com/datasheet/gd25lx256e/

    3. MX25UM25645G www.macronix.com/.../MX25UM25645G, 1.8V, 256Mb, v1.1.pdf

    I will attach you our configs for those flashes.

    Can you please help us out here and verify that we are using the correct values for the configs? SPI is configured to 166Mhz.

    Thanks! 

    Fabian

    flash_nor_ospi_device_IS25WX256.c
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    #include <board/flash.h>
    Flash_NorOspiDevDefines gFlashNorOspiDeviceDefines_IS25WX256 = {
    .NOR_CMD_RSTEN = 0x66U,
    .NOR_CMD_RST_MEM = 0x99U,
    .NOR_CMD_WREN = 0x06U,
    .NOR_CMD_WRDI = 0x04U,
    .NOR_CMD_RDCR = 0x00U,
    .NOR_CMD_WRCR = 0x01U,
    .NOR_CMD_RDCR2 = 0x85U,
    .NOR_CMD_RDCR2_NVO = 0xB5U,
    .NOR_CMD_WRCR2 = 0x81U,
    .NOR_CMD_WRCR2_NVO = 0xB1U,
    .NOR_CMD_BULK_ERASE = 0xC7U,
    .NOR_CMD_BLOCK_ERASE = 0xDCU,
    .NOR_CMD_SECTOR_ERASE = 0x21U,
    .NOR_CMD_RDSR = 0x05U,
    .NOR_CMD_RDID = 0x9FU,
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    flash_nor_ospi_device_GD25LX256E.c
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    #include <board/flash.h>
    Flash_NorOspiDevDefines gFlashNorOspiDeviceDefines_GD25LX256E = {
    .NOR_CMD_RSTEN = 0x66U,
    .NOR_CMD_RST_MEM = 0x99U,
    .NOR_CMD_WREN = 0x06U,
    .NOR_CMD_VOWREN = 0x50U,
    .NOR_CMD_WRDI = 0x04U,
    .NOR_CMD_RDCR = 0x00U,
    .NOR_CMD_WRCR = 0x01U,
    .NOR_CMD_RDCR2 = 0x85U,
    .NOR_CMD_RDCR2_NVO = 0xB5U,
    .NOR_CMD_WRCR2 = 0x81U,
    .NOR_CMD_WRCR2_NVO = 0xB1U,
    .NOR_CMD_BULK_ERASE = 0xC7U,
    .NOR_CMD_BLOCK_ERASE = 0xDCU,
    .NOR_CMD_SECTOR_ERASE = 0x21U,
    .NOR_CMD_RDSR = 0x05U,
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    flash_nor_ospi_device_MX25UM25645G.c
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    #include <board/flash.h>
    Flash_NorOspiDevDefines gFlashNorOspiDeviceDefines_MX25UM25645G = {
    .NOR_CMD_RSTEN = 0x66U,
    .NOR_CMD_RST_MEM = 0x99U,
    .NOR_CMD_WREN = 0x06U,
    .NOR_CMD_WRDI = 0x04U,
    .NOR_CMD_RDCR = 0x15U,
    .NOR_CMD_WRCR = 0x01U,
    .NOR_CMD_RDCR2 = 0x71U,
    .NOR_CMD_WRCR2 = 0x72U,
    .NOR_CMD_BULK_ERASE = 0xC7U,
    .NOR_CMD_BLOCK_ERASE = 0xDCU,
    .NOR_CMD_SECTOR_ERASE = 0x21U,
    .NOR_CMD_RDSR = 0x05U,
    .NOR_CMD_RDID = 0x9FU,
    .NOR_CMD_RDSFDP = 0x5AU,
    .NOR_CMD_READ = 0x13U,
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • 0 in reply to Fabian Sorkalla
    TI__Mastermind 26025 points

    Hi ,

    It seems like you are using a very old version of MCU_PLUS_SDK. Do you intend to migrate to 08.05 release of SDK. The SDK has updated methodology which will help you configure the flash driver better.

    Here is the link for the same - https://software-dl.ti.com/mcu-plus-sdk/esd/AM243X/08_05_00_24/exports/docs/api_guide_am243x/CUSTOM_FLASH_SUPPORT_GUIDE.html

    If you can send the *.json files generated for all the flashes that would help us debug even faster.

    Best Regards,
    Aakash

  • 0 in reply to Aakash Kedia
    Prodigy 220 points

    Hi Aakash,

    yes we are on a older version of the SDK.

    For background:

    We need to configure the flash at runtime since we do not know which of the three are placed during production.

    Therefore we read via Single SPI the Device ID and configure the flash driver accordingly. For this we had to do some changes to the SDK. Therefore a upgrade is not that easy. 

    BR Fabian

  • 0 in reply to Fabian Sorkalla
    TI__Mastermind 26025 points

    Hi ,

    Did you try to disable the DMA and find this to be working ?

    Thanks and Regards,
    Aakash

  • 0 in reply to Aakash Kedia
    Prodigy 220 points

    Hi Aakash,

    okay I will try this also.

    But another question. We just noticed that our Flash is limited to 166Mhz in SDR mode. So I changed Input Clock Frequency in to 166000000Mhz. But then the boad is not booting anymore. But if I change it to 166666666Mhz it works.

    How are Input Clock Frequency and Input Clock Divider related to system clock. How to choose the correct value? Syscfg doesn't provide any help here. 

    BR 

    Fabian

  • 0 in reply to Fabian Sorkalla
    TI__Mastermind 26025 points

    Hi Fabian,

    So 166 MHz usually means 166666666 Hz, rather than 166000000. Latter one won't be achievable by any clock setting and changing the input frequency just by syscfg would not work OOB. You might also need to change the clock tree for that matter.

    Ideally, if you need to change the frequency of the operation you should be doing that without changing the input frequency and configuring the flash's clock dividers. 

    Here the OSPI_RCLK (output clock) is fed to flash. OSPI_RCLK = OSPI_ICLK(input clock)/OSPI_DIVIDER. OSPI_DIVIDER value we usually choose as 4 or 8. So if ICLK = 200 MHz, divider is 4, flash will be effectively clocked at 50 MHz if PHY is disabled. If PHY is enabled OSPI_RCLK = OSPI_ICLK

    Hope this helps.

    Aakash

  • 0 in reply to Aakash Kedia
    Expert 1150 points

    Hey Aakash,

    colleague of Fabian here.

    So I was just trying to update the SDK but the new Flash-Driver has some bugs and it does not work with our flash anymore. The configuration is the same, I just migrated all relevant data. Since the OSPI-registers look the same after startup I guess it's not a problem of the OSPI-configuration. it seems the driver does configure the flash wrong and/or uses wrong cycles. I noticed that e.g. in the Flash_norOspiWaitReady-function the dummycycles are not used as before. now there is a "dummyBits"-field which is set hard to 0 if you do not use XIP. Instead it should be set to "OSPI_CMD_INVALID_DUMMY" so the underlying OSPI_readCmd will use the configured read-cycles.

    Also I found another bug, which I explained here:
    https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1193867/mcu-plus-sdk-am243x-update-to-sdk-08-05-08-04-flash-driver-problems?tisearch=e2e-sitesearch&keymatch=%2520user%253A453845#

    I am not sure how many more bugs came in with the update. We need to postpone it, since even the fixes at these points are not helping.

  • 0 in reply to Aakash Kedia
    Expert 1150 points

    Hey Aakash,

    so I compared the init of both sdks. First I let the old one run, which works. I copied all the issued flash-cmds for config inside Flash_norOspiOpen and copied the register values to compare them. The only difference I see is the order of the address-byte setting. But the registers seem to be the same in the end. I let both run until

    Fullscreen
    1
    attackVectorStatus = OSPI_phyReadAttackVector(obj->ospiHandle, phyTuningOffset);
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    since this is the point where we get different results when reading the flash.

    Every indendation means this is the value/call inside the function above.

    for the old working drivers:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    Flash_norOspiReadId
    Flash_norOspiCmdRead(config, cmd(0x9F), cmdAddr(OSPI_CMD_INVALID_ADDR), numAddrBytes(0), idCode, numRdIdBytes(5))
    OSPI_setDeviceSize(obj->ospiHandle, attrs->pageSize, attrs->blockSize)
    OSPI0__OSPI_CFG_VBUSP__VBP2APB_WRAP__OSPI_CFG_VBP__OSPI_FLASH_APB_REGS_dev_size_config_reg 0x00111002 Device Size Configuration Register [Memory Mapped]
    OSPI_setCmdExtType(obj->ospiHandle, OSPI_CMD_EXT_TYPE_INVERSE)
    obj->cmdExtType = cmdExtType;
    obj->dtrEnable = OSPI_isDtrEnable(obj->ospiHandle); (1)
    OSPI_getXferLines(obj->ospiHandle) (3/OCTAL)
    Flash_norOspiEnable4ByteAddr(config)
    Flash_norOspiCmdWrite(config, devDefines->NOR_CMD_WREN(0x06), OSPI_CMD_INVALID_ADDR, 0, NULL, 0)
    Flash_norOspiCmdWrite(config, devDefines->NOR_CMD_WRCR2(0x81), devDefines->NOR_ADDRESS_CONFIG_REG_ADDR(0x5), 3, &regData(0xFE), 1);
    Flash_norOspiCmdWrite(config, ((Flash_NorOspiDevDefines *)config->devDefines)->NOR_CMD_4BEN(0xB7), OSPI_CMD_INVALID_ADDR, 0, NULL, 0);
    OSPI_setNumAddrBytes(obj->ospiHandle, 4)
    OSPI0__OSPI_CFG_VBUSP__VBP2APB_WRAP__OSPI_CFG_VBP__OSPI_FLASH_APB_REGS_dev_size_config_reg 0x00111003 Device Size Configuration Register [Memory Mapped]
    Flash_norOspiEnableDDR(config)
    Flash_norOspiCmdWrite(config, devDefines->NOR_CMD_WREN(0x06), OSPI_CMD_INVALID_ADDR, 0, NULL, 0);
    Flash_norOspiCmdWrite(config, devDefines->NOR_CMD_WRCR2(0x81), devDefines->NOR_DDR_EN_REG_ADDR(0), 4, &regData(0xE7), 1);
    OSPI_enableDDR(obj->ospiHandle)
    OSPI0__OSPI_CFG_VBUSP__VBP2APB_WRAP__OSPI_CFG_VBP__OSPI_FLASH_APB_REGS_config_reg 0x81783801 Octal-SPI Configuration Register [Memory Mapped]
    obj->xferLines = OSPI_XFER_LINES_OCTAL;
    Flash_norOspiSetOpcodes(config)
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    for the new updated - not working - driver:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    OSPI_setDeviceSize
    OSPI0__OSPI_CFG_VBUSP__VBP2APB_WRAP__OSPI_CFG_VBP__OSPI_FLASH_APB_REGS_dev_size_config_reg 0x00111002 Device Size Configuration Register [Memory Mapped]
    OSPI_setCmdExtType
    obj->cmdExtType = cmdExtType;
    obj->numAddrBytes = 3;
    obj->currentProtocol = FLASH_CFG_PROTO_1S_1S_1S;
    Flash_norOspiSetProtocol
    Flash_set888mode
    Flash_norOspiRegRead(config, octCfg->cmdRegRd (0x85), octCfg->cfgReg (0), &reg (0xFF))
    Flash_norOspiRegWrite(config, octCfg->cmdRegWr (0x81), octCfg->cfgReg (0), reg (0xE7));
    OSPI_setProtocol((OSPI_Handle)(obj->ospiHandle), gFlashToSpiProtocolMap[pCfg->protocol]);
    OSPI0__OSPI_CFG_VBUSP__VBP2APB_WRAP__OSPI_CFG_VBP__OSPI_FLASH_APB_REGS_dev_instr_rd_config_reg 0x00033303 Device Read Instruction Configuration Register [Memory Mapped]
    OSPI0__OSPI_CFG_VBUSP__VBP2APB_WRAP__OSPI_CFG_VBP__OSPI_FLASH_APB_REGS_dev_instr_wr_config_reg 0x00033002 Device Write Instruction Configuration Register [Memory Mapped]
    OSPI_enableDDR(handle)
    OSPI0__OSPI_CFG_VBUSP__VBP2APB_WRAP__OSPI_CFG_VBP__OSPI_FLASH_APB_REGS_config_reg 0x81783801 Octal-SPI Configuration Register [Memory Mapped]
    OSPI_setDualOpCodeMode(handle)
    OSPI0__OSPI_CFG_VBUSP__VBP2APB_WRAP__OSPI_CFG_VBP__OSPI_FLASH_APB_REGS_config_reg 0xC1783801 Octal-SPI Configuration Register [Memory Mapped]
    obj->protocol = protocol;
    obj->currentProtocol = pCfg->protocol;
    OSPI_setProtocol((OSPI_Handle)ospiHandle, gFlashToSpiProtocolMap[protocol]);
    obj->currentProtocol = config->devConfig->protocolCfg.protocol;
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    I also noticed that, when trying to do a CPU reset via ccs and load the image again after the call of the mentioned OSPI_phyReadAttackVector, the first read in SDR config won't work anymore and thus we can't read out the flash-id. We do - independently of the driver - have the same sequence you use in your driver-example:

    Fullscreen
    1
    2
    3
    4
    5
    6
    OSPI_norFlashSetCmds(0x03, 0x02, 0xD8);
    /* Initialize the flash device in 1s1s1s mode */
    OSPI_norFlashInit1s1s1s(ospiObject_.handle);
    /* Read ID */
    status = OSPI_norFlashReadId(ospiObject_.handle, &manfId, &deviceId);
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    This always worked with the old driver. With the new driver we need a power reset of the device to get this working. Else the read stuff is not correct. I guess the driver configures something different here but I don't know what.

    Also some screenshots of how the read out memory looks after the call of OSPI_phyReadAttackVector at 0x60000000 via memory browser:

    old driver:

    new driver:

    it seems only some values match and then somehow all memory after that has the same value. Maybe that helps to identify the problem better.

    Additionally here is our new configuration that I migrated:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    #define FLASH_SIZE (32U * 1024U * 1024U)
    #define FLASH_BLOCK_SIZE (128U * 1024U)
    #define FLASH_SECTOR_SIZE (4U * 1024U)
    #define FLASH_PAGE_SIZE (256U)
    #define FLASH_NUM_BLOCKS (FLASH_SIZE / FLASH_BLOCK_SIZE)
    #define FLASH_NUM_PAGES_PER_BLOCK (FLASH_BLOCK_SIZE / FLASH_PAGE_SIZE)
    #define FLASH_NUM_SECTORS (FLASH_SIZE / FLASH_SECTOR_SIZE)
    Flash_DevConfig gFlashDevCfg_IS25WX256T =
    {
    .cmdExtType = OSPI_CMD_EXT_TYPE_INVERSE,
    .enable4BAddr = TRUE,
    .addrByteSupport = 1,
    .fourByteAddrEnSeq = 0x02, // NOR_CMD_4BEN
    .cmdWren = 0x06, // NOR_CMD_WREN
    .cmdRdsr = 0x05, // NOR_CMD_RDSR
    .srWip = (1 << 0), // NOR_SR_WIP
    .srWel = (1 << 1),
    .xspiWipRdCmd = 0x00,
    .xspiWipReg = 0x00000000,
    .xspiWipBit = (1 << 0),
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    is there maybe another point inside the sdk that was changed that could have an impact here? But all other drivers are working fine. mcspi, pruicss, icssemac, clock, hwtimer, adc, gpios and so on are working as expected.

    Also pls mention: I fixed the both other mentioned bugs to get this far.

    Best regards

    Felix

  • 0 in reply to Felix Heil
    TI__Mastermind 26025 points

    Hi Felix,

    Can I assume flash_nor_ospi_device_IS25WX256.c from your previous release to be a working option ? I can surely recheck the current release status. We have supported the ISSI flash with the latest SDKs so we are sure, that this can work.

    But let me come back to you on this by Friday.

    Best Regards,
    Aakash

  • 0 in reply to Aakash Kedia
    Expert 1150 points

    Hey Aakash,

    yes exactly. the previous was working fine. I did not found a json in the new meta-folder of the SDK for this flash-device. Anyway we do not directly use SysCfg since, as Fabian mentioned, we need to dynamically support multiple flashes, which are identified at startup via their ids.

    Best regards

    Felix

  • 0 in reply to Felix Heil
    TI__Mastermind 26025 points

    Hi ,

    Do you have a non-SDK driver to support the same ?

    Best Regards,
    Aakash

  • 0 in reply to Aakash Kedia
    Expert 1150 points

    Hey Aakash,

    no, we always used the SDK-drivers internally. Above we just hade some OSPIFlash-Abstraction-Driver. the "dynamic" approach of chosing the right Flash was just done at the beginning where we read out the flash-id in 1s1s1s-mode and then accordingly to the id choose the right Configs to use for the TI-Flash-Driver. End of last year we modified the SDK-API slighty so intead of an array with index, which contains the configs, the open-functions take the config directly. But nothing else was changed and it was still working like before.

    Best regards,

    Felix

  • 0 in reply to Felix Heil
    TI__Mastermind 26025 points

    Hi ,

    This makes sense. What issues are you facing with DMA configuration ? Is this working when the DMA is disabled ?

    Best Regards,
    Aakash

  • 0 in reply to Aakash Kedia
    Expert 1150 points

    yes, we do not need the DMA. We only used it in our bootloader, which worked fine so far. But the loaded application did not use it. Both were working. I guess it was only sometimes a problem because of the flash-access itself, which did not work sometimes.

    Best regards,
    Felix

  • 0 in reply to Felix Heil
    TI__Mastermind 26025 points

    Hi ,

    Do you need any more support on this ?

    Best Regards,
    Aakash

  • 0 in reply to Aakash Kedia
    Expert 1150 points

    Hey Aakash, yes.
    With the new sdk update our flash is not able to be used anymore as I mentioned above. But we can move this topic to another thread if it makes more sense.

  • 0 in reply to Felix Heil
    TI__Mastermind 26025 points

    Hi ,

    I would say, if we could move this to new thread and one flash at a time would be better.

    Best Regards,
    Aakash