STM32 DMA Interrupts don’t allow priority control about ada_drivers_library HOT 8 CLOSED

Sorry @simonjwright I've missed this one.

And of course I can’t declare my own, because that would mean attempting to attach two handlers to the same interrupt.

Did you check that? Because it's possible that if the DMA_Interupt_Controller defined in STM32.Device is not used, it will not be included in the final binary and therefore not attached to the interrupt.

Otherwise you are right, this is not flexible enough.

from ada_drivers_library.

I found out because I got a runtime error. However, I was using my cortex-gnat-rts which makes attempting to attach a second handler to an interrupt an error. I just chased through the GNAT GPL 2017 ravenscar-full-stm32f4 code and I think that that RTS doesn’t treat this as an error? I will give it a try.

from ada_drivers_library.

I tried attaching another handler to the DMA2_Stream6_Interrupt and GNAT GPL 2017 ravenscar-full-stm32f4 didn’t complain. I think this is quite a serious bug in the RTS (which handler gets used depends on elaboration order).

Did you check that? Because it's possible that if the DMA_Interupt_Controller defined in STM32.Device is not used, it will not be included in the final binary and therefore not attached to the interrupt.

Looking at the map file, I see

                0x0000000020010c20       0x30 /Users/simon/adacore/certyflie/Ada_Drivers_Library/arch/ARM/STM32/lib/stm32f407/libstm32f407.a(stm32-device.o)
                0x0000000020010c20                stm32__device__dma2_stream0
 .bss.stm32__device__dma2_stream1
                0x0000000020010c50       0x30 /Users/simon/adacore/certyflie/Ada_Drivers_Library/arch/ARM/STM32/lib/stm32f407/libstm32f407.a(stm32-device.o)
                0x0000000020010c50                stm32__device__dma2_stream1
 .bss.stm32__device__dma2_stream2
...

and I think what’s happening is that the elaboration code for STM32.Device creates all the DMA_Interrupt_Controllers, with the data in the appropriate slot, which creates references, so the BSS component gets linked. There won’t be separate function sections for the elaboration of the separate DMA_Interrupt_Controller instances.

from ada_drivers_library.

I tried attaching another handler to the DMA2_Stream6_Interrupt and GNAT GPL 2017 ravenscar-full-stm32f4 didn’t complain. I think this is quite a serious bug in the RTS (which handler gets used depends on elaboration order).

Hi Simon,

Here is my view on this:

In the RM C.3.1, 10/3 only talks about runtime reserved interrupts.

Moreover, 12/3 describes how handlers are restored after having been overwritten. and 14.1/3 explicitly allows attaching multiple handlers to interrupts.

Of course, with the ravenscar profile, 12/3 never happens as there's no termination of protected objects, but the elaboration of protected objects still apply, so 14.1/3 still partially applies.

I agree that it's not ideal, and maybe an extra pragma would be needed to prevent this behavior, but my conclusion is that we shouldn't raise a Program_Error upon multiple Attach_Handler to an interrupt.

Now to solve this specific issue, I'm pretty sure that using the proper pragmas to control the elaboration order would solve your issue and would ensure that the proper handler is always used, no matter what.

from ada_drivers_library.

Yes, but ... the person who implemented Ada.Interrupts for that RTS clearly thought PE was appropriate in some circumstances, since all the subprogram bodies raise it!

Not sure you’d need a pragma; this could be an implementation restriction.

from ada_drivers_library.

The explicit use of Ada.Interrupts is forbidden in Ravenscar, so that's expected:

No_Dynamic_Attachment: There is no call to any of the operations defined in package Ada.Interrupts (Is_Reserved, Is_Attached, Current_Handler, Attach_Handler, Exchange_Handler, Detach_Handler, and Reference).

Here I'm refering to the dynamic semantics of the Attach_Handler aspect that 14.1/3 covers.

from ada_drivers_library.

and I think what’s happening is that the elaboration code for STM32.Device creates all the DMA_Interrupt_Controllers, with the data in the appropriate slot, which creates references, so the BSS component gets linked. There won’t be separate function sections for the elaboration of the separate DMA_Interrupt_Controller instances.

So they end up in the binary even with --gc-sections, this is another problem with this approach.

I wanted to pre-declare all the DMA_Interrupt_Controller in STM32.Device to make it easier for users but it looks like there's too many drawbacks.

from ada_drivers_library.

Also done in #264

from ada_drivers_library.