nrf5340 qspi flash dma

RE: nrf5340 qspi flash dma

ovrebekk — Mon, 23 May 2022 08:59:30 GMT

[quote user="szhaulai"]Hi Thanks for the answer, I got it to work with your suggestion, putting put fifo out of interrupt handler. One final question to this thread about flash driver, is it needed to erase before writing a new dataset into flash? [/quote]

If you use the low level flash driver then you normally need to erase a page before you can write anything to it, that is correct. Since flash only allows you to clear bits when writing and not set bits any word that is not already 0xFFFFFFFF (all ones) can not be written to without first erasing the page.

If you use a higher level driver, like NVS, then the page erase is handled for you by the driver, and you don't need to know about the intricacies of working with flash memory.

[quote user="szhaulai"]Some other question, is there example on using other zephyr fifo api, like k_fifo_alloc_put(). I get error on zephyr CPU and don't know how to debug. I have tried to run in debug mode, but zephyr doesn't report any error or halting.[/quote]

Are you saying that the k_fifo_alloc_put() call doesn't return any error codes, but still the application will crash?

[quote user="szhaulai"]I feel frustrated when it comes to zephyr, the document is not very clear. Is there forum for zephyr like the one you have hosted very well on the nordic site? [/quote]

Zephyr is hosted on Github, which means you can raise issues or ask questions through Github directly:
https://github.com/zephyrproject-rtos/zephyr/issues

We are also happy to help with Zephyr related questions here on the Devzone 🙂

Best regards
Torbjørn

RE: nrf5340 qspi flash dma

szhaulai — Fri, 20 May 2022 15:44:13 GMT

Hi Thanks for the answer, I got it to work with your suggestion, putting put fifo out of interrupt handler. One final question to this thread about flash driver, is it needed to erase before writing a new dataset into flash?

Some other question, is there example on using other zephyr fifo api, like k_fifo_alloc_put(). I get error on zephyr CPU and don't know how to debug. I have tried to run in debug mode, but zephyr doesn't report any error or halting. I feel frustrated when it comes to zephyr, the document is not very clear. Is there forum for zephyr like the one you have hosted very well on the nordic site?

RE: nrf5340 qspi flash dma

ovrebekk — Wed, 18 May 2022 11:02:22 GMT

Maybe yo could try just to print something to the log if mem_ptr != 0 ?

You should skip the remaining code in the timer event handler if this occurs, to avoid writing to the flash_write_fifo if the malloc fails.

Also, unless you don't use k_malloc anywhere else it is not safe to call this function from an interrupt handler. It is best to only use this method from a thread or a work item (or even better to use statically defined memory structures, rather than dynamic memory allocation).

[quote user="szhaulai"]question 1. if I have a thread that needs a long time to process (assume extreme case 100ms), is it a "o.k" practice to have a sleep period less than the process time (assume 1ms). [/quote]

If the thread has a positive priority number it can be interrupted by other, more important threads as long as they have a higher interrupt priority (lower number).

As an example, if you give your time consuming but less critical thread a priority of 5, you can put other more time critical threads at priority 4 or below, and they will be able to interrupt the slow running thread when they have some work to do.

[quote user="szhaulai"]question 2: assume I have many threads that do multiple signal processings, writing to flash. How do I know which thread will be run during the sleep. Should I plan a specific time for the main thread to sleep and activate a specific thread to run during the sleep time of main thread?[/quote]

You don't really know when the different threads are going to run, this is all controlled by the scheduler.

If you feel that you need to know this information then it sounds like you need a better way to synchronize the different activities in your program.

As an example, if you have multiple processes that need to access the flash at different times you can use a FIFO to allow the different threads to schedule flash operations, and execute the operations (read the FIFO) from a single thread so that you avoid conflicts.

Best regards
Torbjørn

RE: nrf5340 qspi flash dma

szhaulai — Mon, 16 May 2022 08:17:06 GMT

Thanks for the reply. I've been able to let the thread run by making k_msleep. But I still have a bunch of question about thread, which will be deviate from my origin question about flash writing time. Please suggest if I should raise a new ticket.

The setback I have experienced is the thread is somehow locked. In the code, it uses __ASSERT_NO_MSG, I have no idea how to debug with the message. I tried to take __ASSERT_NO_MSG away and get some zephyr message about faulting during interrupt handling but I have no idea how to debug it.

devzone.nordicsemi.com/.../0827.main.c

Please give me some indication how I can debug thread and interrupt. I've tried with breakpoint but it doesn't seems to help, the thread just suddenly halted.

Another question I have about thread is about the sleep time that you suggested.

question 1. if I have a thread that needs a long time to process (assume extreme case 100ms), is it a "o.k" practice to have a sleep period less than the process time (assume 1ms).

question 2: assume I have many threads that do multiple signal processings, writing to flash. How do I know which thread will be run during the sleep. Should I plan a specific time for the main thread to sleep and activate a specific thread to run during the sleep time of main thread?

I hope there are example that can explain this better.

Thanks for help

RE: nrf5340 qspi flash dma

ovrebekk — Wed, 11 May 2022 08:25:43 GMT

There is no need to run k_thread_start(..) manually. It will start automatically as long as you use the K_THREAD_DEFINE(..) macro.

I think the problem here is that you have a while(1){} loop in your main function. This will make the main thread run 100%, potentially blocking other threads from running.

Could you try either removing the loop (with Zephyr it is fine to exit the main() function), or adding a delay function inside the while(1) loop to allow other threads to run?

Just changing the loop like this should be sufficient:

while(1) {
k_msleep(1000);
}

Best regards
Torbjørn

RE: nrf5340 qspi flash dma

szhaulai — Tue, 10 May 2022 08:13:22 GMT

I tried to implement the thread but experience some set back. I couldn't start the thread. Would you please check my file and let me know where I do wrong. Thanks for help!

I use a timer to create a counter and save the number to a fifo. Then I tried to use a thread that handling the flash, in which, I plan to get the data from fifo and write to flash for every 128 samples. However, the tread is never started.

devzone.nordicsemi.com/.../3386.main.c devzone.nordicsemi.com/.../0243.prj.conf

RE: nrf5340 qspi flash dma

ovrebekk — Thu, 05 May 2022 11:40:17 GMT

Making your own threads in Zephyr is very easy, and there is also a sample available here showing you how you can do it.

Essentially you can create a new thread with a single line of code:

// The thread function should be void(void)
void thread_func(void)
{

}

// Make a thread with priority 5 and stacksize 512
#define MY_THREAD_PRIORITY 5
#define MY_THREAD_STACKSIZE 512
K_THREAD_DEFINE(blink0_id, MY_THREAD_STACKSIZE, thread_func, NULL, NULL, NULL, MY_THREAD_PRIORITY, 0, 0);

If you exit the thread function the thread will be disabled, so normally you would have an infinite loop in the thread function to make it run forever.

In order for the thread not to occupy the CPU all the time you can use a sleep function, like k_msleep(), or yield the thread by calling k_yield(), whenever you don't have anything to do in the thread.

Best regards
Torbjørn

RE: nrf5340 qspi flash dma

szhaulai — Wed, 04 May 2022 08:21:45 GMT

Thanks for reply, can you give example on how to use different thread? I am testing with external memory chip mx25R6435 on nRF5340DK.

RE: nrf5340 qspi flash dma

ovrebekk — Wed, 04 May 2022 08:15:56 GMT

Normally the higher level flash driver will use the Nordic SPI drivers under the hood, and these drivers will utilize the EasyDMA controller by default.

In the nRF5340 there is no option to disable EasyDMA in the SPI master peripheral, and DMA will always be used.

Have you tried to run the flash writing from a different thread to see if it will still block the system?
Even if the flash API is a blocking API, as long as DMA is used under the hood other threads should still be able to run.

Are you testing this using the external memory chip on the nRF5340DK?

Best regards
Torbjørn