alt_write_flash - single threaded

[Altera_Forum]

I'm currently experimenting with uC/OS-II with NicheStack on Nios II. Things are going well except for situations where I am writing 128K of data to flash using alt_write_flash(). I noticed in the Nios II Software Developers guide that alt_write_flash() should be used in a single threaded build. Is there a HAL implementation that allows flash writing in multithreaded mode available in the NIOS II EDS or must I implement this myself?

[Altera_Forum]

Does it say you should only use it in a single-threaded build? Or does it simply say that the function is not thread-safe? Big difference. As long as you only have one thread making calls to the flash, I think you'll be okay. 

 Jake

[Altera_Forum]

It actually mentions that it is only for single-threaded builds.

[Altera_Forum]

Hello, 

the alter flash driver doesn't work in a multithreaded enviroment!!!! Have you found a sollution for this issue? Thanks!

[Altera_Forum]

I avoided the use of the alt_write_flash() function which seemed to be problematic with uCosII from my experience and instead I use the alt_write_flash_block() and alt_erase_flash_block() with an implementation that will yield to the uCosII scheduler. This seems to be working just fine for me. 

 From the investigation I have been doing, it looks like you should be able to wrap the flash API with OSSchedLock() and OSSchedUnlock(). This will guarantee that the flash function execution will never get preempted by the uCosII scheduler.   Have you actually run into problems using uCosII and the NiosII flash API?

[Altera_Forum]

Currently i have µC-OS-II running with the niche-stack. 

When i try to write something to the flash, this action corrupts a list, wich is used by the niche-stack and so the network-stack crashes gracefully!!! I have modifyed the flash function so that it will directly return to the caller without accessing the flash (just for testing of course) but this doesn't work! So the problem seems to start earlier in the "alt_flash_open_dev()" function! I have also tryed to wrap all calls to the device-driver within   OSSchedLock(); alt_irq_disable_all(); ... ... OSSchedUnlock(); alt_irq_enable_all();   But without success!!! --> How can that be??!! I will continue debugging and reporting on this forum! Any ideas?

[Altera_Forum]

I'll throw a few ideas your way: 

 1) Have you allocated enough stack size for each of your tasks? This seems to be likely based on your problem description.  2) Are you making calls to the flash device from multiple tasks? If so, try making the flash calls from a single task only.  3) Is the network stack actively processing when your attempt to make the call to write to flash causes the corruption? If so, what happens when the network stack is idle and you attempt to make the call to write to flash?  4) Are you able to start a task that will write to flash before you start the network stack to see if you can reproduce the problem even before the network stack task is running?  I'll think about this a bit more. Good luck!

[Altera_Forum]

4) 

I have tested the whole flash within the InitialTask (before the network stack is running) --> That works fine!   3) Everything works fine, if the network-stack doesn't process any data   2) All calls to the flash-device came from the context of a single tasks (and also not from an interrupt-context). The priority of this task is the lower than those of the network-tasks. Only "statistic-task" and "idle-task" have a lower priority   1) The Stack usage reaches a maximum of 41% But i will try to increase the stack-size....   Perhaps there is something wrong with my code.....

[Altera_Forum]

If your stack sizes are fine then it sounds more like some sort of memory overrun or corruption of some sort. Maybe it is in your code like you mentioned. I don't know how your code interacts with the network stack but I would say if you are doing reads from the network stack and then processing, maybe try reading and throwing away the data instead of processing it to see if the problem persists.  

 Are you able to trace into the call stack right to the point of corruption? I would use the Eclipse debugger and follow the code path into alt_flash_write() or alt_flash_write_block() and watch the memory area that you know gets corrupted closely as you step through each call. I wonder if you can still reproduce the problem as you step through the code.

[Altera_Forum]

Hello,  

thanks a lot for your ideas... I have solved the problem! It was my fault... The problem was a Stack Overflow within the Task wich writes to the flash memory. This overflow accours only, if the flash-write will be executed and if a interrupt context places it's data on the stack of this tasks either. In this case the stack usage increases from about 36% to overflow on a 22 kByte Stack!!   It is possible to use the flush-driver on a multythreaded enviroment as long as only one task is accessing the flash-device. I think that this is what Altera means with the parameter "thread safe: no"

[Altera_Forum]

We are VLSI design center and we made several designs before, using FPGAs, by writing the required codes and testbench for functional and timing simulation of the design, then download the design on the hardware . Currently we have a design that uses IPs only . We implemented it using SOPC builder and we have also a development board for hardware testing . 

My question is : do we need to write the testbench for this design in order to perform functional simulation first then download it on the development board ? or can we skip the functional simulation since the design consists of IPs only and these IPs are tested by Altera?

[Altera_Forum]

--- Quote Start ---  Hello,  thanks a lot for your ideas... I have solved the problem! It was my fault... The problem was a Stack Overflow within the Task wich writes to the flash memory. This overflow accours only, if the flash-write will be executed and if a interrupt context places it's data on the stack of this tasks either. In this case the stack usage increases from about 36% to overflow on a 22 kByte Stack!!   It is possible to use the flush-driver on a multythreaded enviroment as long as only one task is accessing the flash-device. I think that this is what Altera means with the parameter "thread safe: no"  --- Quote End ---    Great news! I'm glad you sorted it out. Cheers.