QSPI register corruption

[Giovanni]

Setting up the QSPI registers is done in a critical section so nothing should be able to touch them during the command setup.

Are there "fast interrupts" in the system? those could preempt into the critical section and do something that could trigger the address register clearing.

Also, it would be a good idea to check if there are stack overflows.

Giovanni

[steved]

No intentionally enabled fast interrupts (I think I might have checked for unintentional ones at some time, but I'll revisit that).

And no stack overflows - at least not according to both the ChibiStudio plugin and a cruder check of my own. Its an F767, so I've got the stack guard enabled.

I can confirm not operating in memory mapped mode; I mentioned using XIP without problems as strong evidence that it's not a hardware issue. Also, under the right circumstances I can do millions of reads from the QSPI Memory without a problem. (QSPI clock is well below the maximum).

Way back, I used the trace facility, coupled with register checks of the address register in context switches and ISR prologue/epilogue, to find the corruption seemed to occur when "chained" interrupts occured - i.e. two successive ISRs without returning to the main code in between.

Right now I've thinned down the code to the point of having just three threads active - main, idle, and one which is waiting for an event which is never triggered (and has nothing to do with QSPI). That has eliminated 80-90% of my code as being the problem - some is still linked in, but it's never started.
At present I've got most of the debug features (e.g. trace) disabled, and QSPI locks in wspiReceive() waiting for an operation to complete (for the thread to be resumed). This is in the initialisation part of the software - it never gets to the 'normal operation' part.
With a slightly different code set program initialisation completes OK, and it goes into a continuous loop reading sectors from QSPI memory. This continues working for relatively long periods - minutes or even hours.

Now testing using Chibi 20.3.4 and gcc 10.3.1, but have had this problem going back several versions - possibly as far back as Chibi 17. So it does point to something obscure I'm doing; just can't see it, though.

[Giovanni]

Hi,

Could you try the "alternate" Cortex-M port? it is an entirely different approach to the problem, especially interrupts handling.

Still having or not having the problem could give use some extra hints. Just swap the makefile to ./os/common/ports/ARMv7-M-ALT

This port is there for sandboxes but I am thinking to make it default, it has some advantages.

Giovanni

[steved]

Could you try the "alternate" Cortex-M port? it is an entirely different approach to the problem, especially interrupts handling.
Giovanni

Looks to be Chibi 21 only. Would it backport to Chibi 20, or do I need to move my software forward? (I've been trying not to change too much!)

[Giovanni]

Backporting would need some changes, RT went from 6 to 7.

Giovanni