• State
  • Locked Locked
  • Replies 8 replies
  • Subscribers 33 subscribers
  • Views 205 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.

AM263P4-Q1: OSPI Flash_read() Causes FreeRTOS Assert

Kier
Mastermind 8825 points
Part Number: AM263P4-Q1

Tool/software:

Regarding the example 'ospi_flash_io_am263px-cc_r5fss0-0_nortos_ti-arm-clang'. It is bare metal and runs only once.

I have FreeRTOS running some time tasks at 1ms, 2ms, 4ms, 8ms and 20ms.

Since flash operations take a long time then I am calling functions such as Flash_write() from the vApplicationIdleHook in FreeRTOS. If I used 20ms task, it would overrun of course.

I am able to write large blocks of data, say 32k with no issue. By "no issue", I mean Flash_write() returns successfully and the time tasks listed above continue to interrupt the idle hook and execute as normal.

However, if I do a Flash_read() of more than about 1k, the application stops in the following assert trap.

<Question>

1. Can you think of a reason why Flash_write() works fine but Flash_read() causes a FreeRTOS trap please?

2. What is the best way to do lengthy flash operations in a FreeRTOS environment? I am using the idle hook but is that the best approach?

Thank you.

  • 0
    TI__Expert 4650 points

    Hello,

    I reached out to our experts on this, please expect a response in the next day or so.

    Thank you for your patience,

    Susan

  • 0
    TI__Intellectual 1885 points

    Hello,

    Allow me to check this and get back to you.

    Regards,

    Aswin

  • 0
    TI__Intellectual 1885 points

    Hello,

    Can you think of a reason why Flash_write() works fine but Flash_read() causes a FreeRTOS trap please?

    Can you check the following in the code

    1. Is DMA enabled for OSPI flash read. Also is the flash region under read/write operation cached. Can you check if the MPU configuration aligns with the ospi_flash_io example in MCU_PLUS_SDK. The region under consideration must be strongly ordered.

    2. Is the read buffer allocated in Idle task's stack? Is the stack size enough for flash read operation incase the buffer is a local buffer? 

    3. Can you check if the stack is getting overflowed for the task?

    4. In XIP being used in device? If so, is the code responsible for flash operation in flash itself? 

    What is the best way to do lengthy flash operations in a FreeRTOS environment? I am using the idle hook but is that the best approach?

    Rather than using an IDLE task to do flash operations, you may use a low priority task. Other tasks can then talk to this task to perform required flash operations.

    Regards,

    Aswin

  • 0 in reply to Aswin Sankar
    Mastermind 8825 points

    Hello Aswin,

    Thanks for the reply and apologies for the delay.

     

    Aswin Sankar said:
    1. Is DMA enabled for OSPI flash read.

    Yes, it is.

    Aswin Sankar said:
    Also is the flash region under read/write operation cached. Can you check if the MPU configuration aligns with the ospi_flash_io example in MCU_PLUS_SDK. The region under consideration must be strongly ordered.

    Here's my MPU config for the RAM used for write and read operations. I tried both Cached and Strongly Ordered but it made no difference:

    Aswin Sankar said:
    2. Is the read buffer allocated in Idle task's stack?

    No, but the example doesn't use stack either.

    Aswin Sankar said:
    3. Can you check if the stack is getting overflowed for the task?

    It's unlikely because I'm not using stack for the read buffer and the FreeRTOS does stack overflow detection anyway.

    Aswin Sankar said:
    4. In XIP being used in device?

    No, not using XIP.

    Aswin Sankar said:
    Rather than using an IDLE task to do flash operations, you may use a low priority task.

    But IDLE is a low priority task, is it not? Is there a reason IDLE would not work equally well?

  • 0 in reply to Kier
    TI__Intellectual 1885 points

    Hi Kier,

    Is it possible for you to send the project application that you are working on?

    Also, are you using a custom board or an EVM(CC or LP). If custom board, can you tell me which flash is being used.

    Regards,

    Aswin

  • 0 in reply to Aswin Sankar
    Mastermind 8825 points

    Hi Aswin,

    Thank you. I'm working on a project which demonstrates the issue(s) which I can give to you but which is not my actual project.

  • 0 in reply to Kier
    TI__Intellectual 1885 points

    Hi Kier,

    That would be good. Can you share it?

    Regards,

    Aswin

  • 0 in reply to Aswin Sankar
    Mastermind 8825 points

    I worked around the issue by using a much smaller read buffer.

    Previously, I was using a read buffer greater than the size to be read such that there was only one call to Flash_read() to simplify debugging. However, if I reduce the buffer size to say 512 bytes and then do multiple calls to Flash_read() with incrementing offset then it doesn't fall into assert trap.

    Since a small read buffer will be the production solution then I guess we can close this without worrying about the root cause.