Hard fault while writing using user data to QSPI flash W25Q64JV

[thivya_ashokkum]

I'm running into a weird issue that I can't get a break with. I'm running XIP on an RT1052 and I also store user data on the same flash. I got that part working by following recommendations from this forum and @Daniel Sanchez  helped me get that working. I put all my flexspi code into SRAM_ITC and disable the interrupts and cache before performing a flash write and then reenable the interrupts and cache after I'm done with the operation. Everything works fine for the first few minutes. After that, when I try writing data to the flash, there is a hard fault and I'm unable to trace back the exact instruction causing the fault.

To provide some background, the flash operations are running on a separate FreeRTOS task and I receive the data to be written over TCPIP which runs on a different task. I use LWIP for my network stack.I made sure my flash task is set at the highest priority but still I'm not sure what's causing the hard fault. Within the first few minutes, all my flash writes go through and I'm able to view the sectors being erased and written to as expected. But after about 4 minutes, when I try to write, the erase happens and when it tries to write to the flash, there is a hard fault. I tried setting breakpoints to catch where exactly it breaks but couldn't succeed. Any help with this would be appreciated.

I've attached a screenshot of my debug window. 

UPDATE: The hard fault goes away when I disable Ethernet in my code and comes back when I re-enable it. So, I'm writing to and reading from valid addresses of the flash. It is only when I introduce the Ethernet, I run into the hardfault.

[victorjimenez]

Hello, 

In your update, you mentioned that if you disable the Ethernet module the hard fault goes away. This makes me think that at some point when you write to the FlexSPI you are actually interfering with some on-going Ethernet transfers. Before writing to the flash are you checking that there aren't any on-going transfers on the Ethernet module? 

Regards, 

Victor 

[thivya_ashokkum]

Hello Victor,

After some more debugging, I realized that after ~3-4 minutes of running the firmware with Ethernet transfers, there is a hard fault and the hard fault pointed towards UNDEFINSTR.  It looked like some kind of stack overflow(I'm not sure if it is a stack overflow but it seems like it could be) and it overwrites the flexspi instructions I've pulled into SRAM_ITC. Since I'm running XIP, I pulled my flexspi instructions into SRAM_ITC and somehow they were being tampered after 4 minutes of Ethernet operations. When I moved my flexspi instructions to SRAM_DTC, the fault went away and I can operate for over an hour without any faults. (I tested only for an hour)

I have SRAM_OC as my 1st RAM bank and it's almost full and I already have 110K allocated for my FreeRTOS heap and 3000 bytes for the TCP task. I haven't had time to play around with these values to see if they affected the fault. What are your suggestions?

1. Should I increase the task's stack size? (I have continuous TCP transfers of less than 200 bytes between my firmware and a client)

2. I tried moving my FreeRTOS heap to SRAM_DTC but since they are only 128K, I don't get too much of an advantage over my already existing 110K. What would your suggestion be for my scenario?

[victorjimenez]

Hello, 

The instructions that were writing to the QSPI where on the SRAM_ITC, but when you changed these instructions to the SRAM_DTC the hard fault goes away, correct? Do you have anything else besides these instructions in the SRAM_ITC? Because based on the information that you shared it seems that you are using only the SRAM_OC and that SRAM_DTC and SRAM_ITC are empty, am I correct on this? 

It would be a good idea to increase the task stack size to see what happens with this behavior. 

Regards,

Victor