Hi,
I am trying to implement FW update through ethernet on SAME54 so briefly I am booting from BANKA and will write new FW to BANKB and then switch banks and reboot. There is an application note for SAM4S from Atmel (no FreeRTOS).
I am building my project based on one of Atmel-start sample projects (LwIPsocketapiexample) with FreeRTOS and LWIP. This project is working fine. I have added the flash driver to that project in Atmel -start and tried to test writing one page (512 B) into starting address of BANKB (0x80000).
The sample project has three existing tasks two for LWIP and one of them just blinking a LED. I used the example function (FLASH_0_example) in the LED blinking task before the infinite loop.
Surprisingly, it is crashing after writing the data into the flash. I am using SAME54 explain pro board and can see the data is written in the flash correctly but after finishing the flash_write function it is throwing hard_fault exception. I tried to disable interrupts also completely suspend other tasks during flash access but still no luck.
Any thought that what can cause the problem or suggestion that how I can debug this.
Thanks a lot,
If you are disabling interrupts, writing to the flash bank that you are sure you are not executing from, not using any RAM functions to perform the write, not attempting to switch flash banks, and then crashing … I’m not sure what could be causing it. Especially if you have not re-enabled interrupts. Recommend trying to find the cause of the hard fault: Debugging and diagnosing hard faults on ARM Cortex-M CPUs
Are you really sure that the flash driver is capable to handle dual bank flashes properly ?
It starts with dealing with 2 EFCs, keeping track of the current bank and proper addressing etc. on SAM4SD.
In addition flash erase/write might take a pretty long time. So if you have a watchdog enabled you might need to re-estimate the timeout.
I have made a simple project without RTOS and the flash driver is working fine No problem. About the WD it is disabled right now and you are right. Flash writing is a slow process.
Is it possible that the interrupt priority of the NVM is higher than the system tick and for that reason RTOS throwing hard_fault? How can I check that?
Thought you had disabled interrupts?
Hi Richard,
Yes , I used portENTER_CRITICAL(); portEXIT_CRITICAL(); before and after writing to the flash with no lock. Then I tried vTaskSuspendAll() and xTaskResumeAll(). So when we enter the critical section the scheduler is also disabled?
I had seen the article about debugging cotex M and used the piece of code for capturing the error but do not know how to map PC to line of the code.
Can I use configASSERT() to capture the error?
Thanks and regards,
As I’ve seen the SAME54 is different to the SAM4SD with regard to the flash controller.
Thanks to the 2nd flash controller the SAM4SD is able to write to the inactive flash bank while executing code from the active one. No need to disable interrupts etc. with the exception when updating the bank selector.
Question is which restrictions caused by the (single) NVMCTRL have to be taken into account for when writing to the other bank … 
I have just solved the problem. Stack overflow. Sorry guys. I had some suspicion to stack over flow and had increased the stack size for the task with no luck but then I saw this post.
So seems that the flash driver bringing the whole page into the RAM and then makes changes in the buffer and after erasing the flash writing that back which translates to lots of memory.
This time I increased the stack size 16 times and know it is working.
Thanks for your time and sorry. Stupid mistake.