Page 2 of 3

Re: GCC 9

Posted: Fri Jun 05, 2020 8:34 am
by steved
Giovanni wrote:The general problem is: In an ISR epilogue how can I tell if the ISR is returning into normal code or into another ISR? The intrinsic used in the v6m port is bugged, it is done differently in v7m because that architecture has a dedicated status bit for this which is missing in M0.

Interesting, because I have an obscure bug which could be exactly that problem - except its on F767 using GCC V7.2.1, which should be OK. (And haven't seen the problem during more limited testing with other compiler versions). Is there any way to establish whether I have a compiler-created problem?

Re: GCC 9

Posted: Fri Jun 05, 2020 8:44 am
by Giovanni
If there is a problem then it is likely another problem, the v7m port does it in an entirely different way than v6m so it is not affected by that bug.

Do you have ISRs without macros in your system? those can cause a similar issue if placed at lower priority than any OS-aware ISR.

Giovanni

Re: GCC 9

Posted: Fri Jun 05, 2020 9:17 am
by steved
Giovanni wrote:Do you have ISRs without macros in your system? those can cause a similar issue if placed at lower priority than any OS-aware ISR.

No, all standard Chibi HAL ISRs.
(Just clutching at straws really; that one-line description seemed to describe my apparent problem so well!)

Re: GCC 9

Posted: Fri Jun 05, 2020 9:48 am
by Giovanni
Does the problem trigger assertions or other traps?

Giovanni

Re: GCC 9

Posted: Fri Jun 05, 2020 2:46 pm
by steved
Giovanni wrote:Does the problem trigger assertions or other traps?

Giovanni

No. The visible symptom is that the QSPI address register gets set to zero, which should never happen once the code is running.

I've added a check in the IRQ prologue and epilogue macros, and entry to the idle thread, and break on zero. The check always fails in the IRQ epilogue, when a nested interrupt has occurred. I've attached an example trace. The two interrupts involved vary - I think one has always been one of the CAN interrupts (Tx or Rx); the other may be a timer, UART...
Hardware is an F767 Nucleo on a carrier board.

Logically the problem is somewhere in my software - but I can't see it! Everything else is running solidly.

Re: GCC 9

Posted: Fri Jun 05, 2020 3:15 pm
by Giovanni
Have you tried swapping OSPI and CAN IRQ priorities and making other similar changes? not a solution for sure but it could give us hints about the nature of the problem.

Giovanni

Re: GCC 9

Posted: Fri Jun 05, 2020 6:26 pm
by steved
Giovanni wrote:Have you tried swapping OSPI and CAN IRQ priorities and making other similar changes? not a solution for sure but it could give us hints about the nature of the problem.

Giovanni

No, not yet - I've actually had to put this one aside in favour of some more urgent stuff at the moment. Playing with IRQ priorities is next on my list when I can get back to it.

Re: GCC 9

Posted: Sat Jun 06, 2020 10:47 am
by mobyfab
Hello,

Could you update the warning messages for stable branches?

Thanks!

Re: GCC 9

Posted: Sat Jun 06, 2020 11:03 am
by Giovanni
Hi,

Already done.

Giovanni

Re: GCC 9

Posted: Sat Jun 06, 2020 1:12 pm
by Giovanni
Commit on 20.3 failed because conflict, it is done now.

Giovanni