<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 2019-April-04, at 7:23 AM, Joel Sherrill <<a href="mailto:joel@rtems.org" class="">joel@rtems.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><br class=""></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 4, 2019 at 7:28 AM Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de" class="">sebastian.huber@embedded-brains.de</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello,<br class="">
<br class="">
On 04/04/2019 14:09, Catalin Demergian wrote:<br class="">
> Hi Andrei,<br class="">
> thank you for the elaborated answer !<br class="">
><br class="">
> I checked my STM32 Cube settings, I have 3 enabled interrupts and they <br class="">
> all have the preemption priority/sub priority set to zero !<br class="">
> it seems I ran into the same issue you had in 2015 :)<br class="">
> I will take your advice - change the priorities, regenerate the code <br class="">
> and see what happens.<br class="">
<br class="">
I mentioned this possible problem some months ago:<br class="">
<br class="">
<a href="https://lists.rtems.org/pipermail/users/2018-September/032600.html" rel="noreferrer" target="_blank" class="">https://lists.rtems.org/pipermail/users/2018-September/032600.html</a><br class="">
<br class="">
Andrei's answer is definitely a bit more elaborate.<br class=""></blockquote><div class=""><br class=""></div><div class="">Thanks Andrei! I am glad you are past this but let's do a post-game analysis of what</div><div class="">could be better next time so no one else suffers as much. These are random ideas</div><div class="">and I am open to more.</div></div></div></div></blockquote><div><br class=""></div>If I am setting up a new project, I’ll grab the BSP, or even just start a new project in eclipse, put together a model in CubeMX and - BAM - run into this issue.</div><div><br class=""></div><div>I’ve seen this before, so I know where to go in my email stash to find my writeup of the solution and go and fix the interrupt priorities. But this only happens about once a year, so I don’t reflexively remember the minutia. </div><div><br class=""></div><div>Someone, other than me, will get mislead by the defaults in CubeMX and take the default 0 priorities and trip over the stupid rules. Without Cube, you’ll still get 0 priorities. Or you can choose your own priorities, but you need to know the stupid rule and use large value interrupt priorities.</div><div><br class=""></div><div>So, how do we let people know that this is an issue with the STM32 series? Maybe an STM32 appendix to the c-user guide. That could be a good place to put stuff like “UART3 is used as a console on pins X and Y. To change these pins, alter these values in the BSP and rebuild”.</div><div><br class=""></div><div>In the mean time, I’m just starting another project using an STM32F4 and RTEMS and I just remembered that I haven’t set the interrupt priorities properly. SIGH.</div><div><br class=""></div><div>A</div><div><br class=""></div></body></html>