On 04/04/2019 15:23, Joel Sherrill wrote:
On Thu, Apr 4, 2019 at 7:28 AM Sebastian Huber
<sebastian.hu...@embedded-brains.de
<mailto:sebastian.hu...@embedded-brains.de>> wrote:
Hello,
On 04/04/2019 14:09, Catalin Demergian wrote:
> Hi Andrei,
> thank you for the elaborated answer !
>
> I checked my STM32 Cube settings, I have 3 enabled interrupts
and they
> all have the preemption priority/sub priority set to zero !
> it seems I ran into the same issue you had in 2015 :)
> I will take your advice - change the priorities, regenerate the
code
> and see what happens.
I mentioned this possible problem some months ago:
https://lists.rtems.org/pipermail/users/2018-September/032600.html
Andrei's answer is definitely a bit more elaborate.
Thanks Andrei! I am glad you are past this but let's do a post-game
analysis of what
could be better next time so no one else suffers as much. These are
random ideas
and I am open to more.
+ Could this be detected at run-time during setup with a debug option?
This is difficult. Something from the outside destroys your operating
system data structures. This is similar normal memory corruption.
+ Could this be written up in the BSP Guide so at least there is a
place to reference?
Perhaps in a generic section on dealing with interrupt controllers
At least for ARM it is documented in the CPU Supplement:
https://docs.rtems.org/branches/master/cpu-supplement/arm.html#interrupt-processing
However, who knows that this manual exists and reads it? I would place
this information in the user manual, but this was rejected.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users
