NMI and the SSL:adi_int_CECHook, where's the RTN?

the datasheet describes NMI signal behavior

the PRM is pretty clear wrt nesting.  only interrupts (IVG5 - IVG15) can be nested.

By datasheet I have to assume you mean "ADSP-BF537 Blackfin Processor Hardware Reference.pdf"

It only says, quote:

    "It should be noted that emulation, reset, NMI, and exception events, as
    well as hardware error (IVHW) and core timer (IVTMR) interrupt requests,
    enter the interrupt processing chain at the ILAT level and are not affected
    by the system-level interrupt registers (SIC_IWR, SIC_ISR, SIC_IMASK,
    SIC_IARx)."

While this is rather cryptic, it doesn't relate to the pin behaviour. The rest is related to the watchdog's use of NMI.

Or "ADSP-BF531_BF532_BF533.pdf" which says, quote:

    "Nonmaskable Interrupt (NMI) – The NMI event can be
    generated by the software watchdog timer or by the NMI
    input signal to the processor. The NMI event is frequently
    used as a power-down indicator to initiate an orderly shut-
    down of the system."

and

   "NMI I Nonmaskable Interrupt (This pin should be pulled low when not used.)"

What is a 'PRM' ?  Oh..., is it a programmer's reference manual?

The "Blackfin Processor Programming Reference, Revision 1.3 (Sep 2008)"  says:

    "If an exception occurs in an event handler that is already servicing
    an Exception, NMI, Reset, or Emulation event, this will trigger a
    double fault condition, and the address of the excepting instruction
    will be written to RETX."

which obviously means don't nest them, which is why I'm asking about the pin behaviour and how to cope with a long extended NMI assertion and not end up nesting.

It also discusses how the CEC provides edge sensivity for IVG7..IVG15 but not what the lower ones do.

Got it! In the "errata for Rev 1.3":

Does this mean that if the NMI assertion is very long, each RTN from the handler will immediately call back into the NMI handler until the NMI goes away?

I gather that saying "only interrupts (IVG5 - IVG15) can be nested" is answering "no"

to my question "Is  adi_int_CECHook() the way to get access to the NMI events?"

The "Device Drivers and System Services Manual for Blackfin Processors (50_dd_ss_proc_man_rev4.0.pdf)" says, quote:

    "In systems that employ Blackfin processors, often there are more potential
    interrupt sources than IVG levels. As stated above, some events (such as
    NMI) map one-to-one to an IVG level. Other events, typically infrequent
    interrupts such as peripheral error interrupts, are often “ganged” in a sin-
    gle IVG level.
    The interrupt manager allows the application to execute complete control
    over how interrupts are handled, whether they are masked or unmasked,
    whether they mapped one-to-one or ganged together, whether the proces-
    sor should be awakened to service an interrupt, and so on"...

which kind of implies I should use the interrupt manager of the SSL and thence

adi_int_CECHook() to access the NMI event.

I gather then that I should re-write the Event Vector Register to my own NMI handler and do the RTN myself?

You are correct, there is an issue with the current SSL Interrupt Manager and its handling of NMI.

The SSL Interrupt Manager allows you to hook IVG2 (NMI). The primary handler returns with an RTI, however, and needs to be modifed such that it returns with an RTN. The SSL Interrupt Manager will be modified in a fture release to address this issue.

In the meantime, you will need to manage EVT2 outside of the Interrupt Manager Service.