LPC55S69: Ef(50): flash driver failed to initialize

[andrew_lonsdale]

I'm repeatedly hitting a situation where I load my latest code to the LPC55S69 demo board for debug, but if I try and load it a second time, then I get the Ef(50): flash driver failed to initialize error.

The initial error reads:

Sending VECTRESET to run flash driver

content (at 0x30006800) not set as written

I assume that my code is overwriting something critical during runtime, probably the flash driver.

I am using the PowerQuad to do a sqrt calculation either through arm_sqrt_q31() which calls the PowerQuad  or PQ_VectorSqrtFixed32() directly. Commenting out these lines seems to solve the problem.

I note that the error message above indicates a problem accessing location 0x30006800, but also note from the User Manual, that the PowerQuad uses 0x20040000 to 0x20043FFF, or 0x30040000 to 0x30043FFF as a scratchpad. Could the PowerQuad somehow be restricting access to or corrupting the flash driver in some way, and if so is there a way around this?

I should add that I am debugging through the onboard LinkServer debugger.

I can recover access to the board by holding the ISP button down and loading a random example program, so that my program is not running. At that point I can load my code again.

Regards

Charles

[andrew_lonsdale]

I've made some progress and have a solution, but would still welcome more info on the underlying mechanism.

I added a 10 second delay to the start of my program before any DMA's were initialized. This was to test whether or not the VECTRESET that is issued to load the Flash Driver was working. The theory being that the debugger would have time to connect before the DMA's would be overwriting critical parts of the memory.

This did not fix the problem, so I presume that the VECTRESET is being prevented from working.

In the workspace tab there is an object "Project LinkServer Debug.launch". Double clicking this gave some debug options. Under the Debugger Tab there is a list of Target Configuration options. Selecting "Flash Driver Reset Handling" = SYSRESETREQ solved my problem.

I hope this might help others, and if anyone has any more info on why VECTRESET appears to not be working in this case, please add a comment.

[andrew_lonsdale]

I have the first inkling of the issue, but not the resolution.

My code is using the non-secure SRAM0 space 0x20000000 - 0x20000FFFF, and I have a number of DMA channels running.

It looks like the debugger is issuing a VECTRESET and then trying to get a response from secure address 0x30006800.

However, when I add certain lines in my code, it pushes the DMA buffers such that they are using address 0x20006800.

0x30006800 is the same physical address in SRAM as 0x20006800, so I assume that the expected response location is being overwritten by the DMA.

So the failure occurs if the buffers are allocated to the wrong place.

Any guidance on what would be the elegant solution to this problem ? I'm guessing some sort of reserving of address 0x20006800/0x30006800 would be advisable.

[Alice_Yang]

Hello Charles,

In your project, do you use TrustZone or config secure address?

As far as I know If debug the secure project, before next time to debug,we need to erase the chip first.

Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[andrew_lonsdale]

Hi Alice,

Thanks for replying once again. You may be on to something.

I am not using TrustZone or Secure mode as far as I know. However, in the debug console, I do see the following line:

"processor is in secure mode"

Now, the problem only occurs when I have sufficient code so that the receiving buffer of a DMA covers address 0x20006800. If this is not the case, then the project loads and runs fine.

So that suggests to me that when the load fails, the debug startup is incorrectly detecting that the processor is in secure mode.

Properties-> C/C++ Build->Settings->TrustZone Project Type = None for both the Compiler and Linker.

Does this help diagnose the problem?

Regards

Charles