Malloc from ISR?

[groups at chichak.ca]

No, I expect that someone is just being clever. At startup, the USB device generates an init event. The author then brings up everything that is needed.

Out of the various people I have done a sanity check with, everybody agrees that malloc should not be called in an ISR.

I’ll see what I can do about writing it up and sending a message to ST.

Thanks,

Andrei

> On 2017-December-11, at 19:12, Joel Sherrill <joel at rtems.org> wrote:
> 
> 
> 
> See cpukit/libcsupport/src/malloc_deferred.c. It is definitely returning NULL because
> you shouldn't malloc from an ISR. malloc() is a non-deterministic operation. I am
> surprised that code was designed to do that.
> 
> Perhaps this code assumes the USB interrupt is serviced from a thread. The raw
> interrupt unblocks a thread to run this code.
> 
> --joel
> 
> On Mon, Dec 11, 2017 at 6:36 PM, Mr. Andrei Chichak <groups at chichak.ca <mailto:groups at chichak.ca>> wrote:
> (sorry if this ended up on the Devel list.)
> 
> I’m working with ST’s HAL USB stack, and to initialize the various structures, they use a USB interrupt as a trigger.
> 
> In this interrupt,  they malloc some space for a descriptor (504 bytes).
> 
> The RTEMS malloc always returns 0.
> 
> Is there a guard against calling malloc in an interrupt context?
> 
> I managed to get around the problem by doing a static allocation, but I was just wondering.
> 
> 
> Andrei
> 
> _______________________________________________
> users mailing list
> users at rtems.org <mailto:users at rtems.org>
> http://lists.rtems.org/mailman/listinfo/users <http://lists.rtems.org/mailman/listinfo/users>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20171211/4b86538c/attachment-0002.html>