N6 VENC causes I2C slave issues

[rphii]

Hi all,

 

Experiencing yet another hurdle using the STM32N6: I am running into the issue where if I run the VENC as the JPEG encoder, where I previously found out how to properly run it in the first place, I get issues in the I2C slave communication…!

 

Okay, what do I mean…

• i2c is configured as a slave. I receive/send all data via. DMA
• First stop for both directions of communication is the `HAL_I2C_AddrCallback`
• Maximum burst length of any i2c communication on my bus is 256 bytes
• The above mentioned limitation works very good and without issues, if I do not have the VENC running

 

Problems arise, when I turn on the VENC, encoding each 2nd frame on PIPE1 that comes in through the DCMIPP. It is configured to convert one frame of ARGB24 into a JPEG. I used the middlewares from https://github.com/STMicroelectronics/STM32CubeN6/ and snippets from the VENC_JPEG_Encoding example (commit 8ab3b641, which is the latest as of writing).

 

A list of some problems that I encounter, observed in parallel with an oscilloscope:

• No response; `HAL_I2C_AddrCallback` doesn’t even get called
• Read request gets aborted
• Corrupted communication (e.g. 0xFF repeated instead of my data)
• SDA won’t get released, it gets held low forever

 

As soon as I turn off the VENC all the issues go away.

 

Configuration:

• Time base: System tick timer is at priority 15
• All DMA involved in the I2C communication are set to “Very High” priority, with their interrupts at priority 14
• Both (event+error) i2c interrupts are set to priority 14 as well
• Additionally I have a timer interrupt at priority 10 that periodically checks whether or not to reinit the i2c peripheral (`HAL_I2C_ErrorCallback` error case or `HAL_I2C_ListenCpltCallback`) - For the moment this is absolutely necessary to ensure quick response times on the bus, because my main is too busy, lol
• I use mainly the CubeMX and the HAL library

 

Does anyone have a clue why the VENC would disturb the communication? I don’t know if the JPEG peripheral would fix that, but at the same time, I don’t want to use it because it is way slower (tens of milliseconds instead of like 4 that the VENC needs).

If you need more details to help me figure out what is going on, tell me what you need and I will provide them as best as I can.

 

Best regards, rphii

 

[Saket_Om]

Hello ​@rphii 

Could you configure the I2C interrupts and the DMA channels used for I2C RX/TX to the highest priority in the system, then test again with VENC enabled; since the issue only appears when the VENC/DCMIPP pipeline is running, this could be related to interrupt latency preventing the I2C slave from being serviced in time.

[rphii]

Hey ​@Saket_Om 

At first I thought that priority 15 would be the one with highest priority.

I changed the interrupts for I2C to priority 1. The default ones (NMI, hardfault, memory management, prefetch fault, undefined instruction, secure fault, system service call, debug monitor, pendable request, time base) are set to priority 0. The CSI is at 15, everything else is at 7+.

 

Now the next issue arose: Instead of the NVENC making things difficult for the I2C communication, it is the NPU. Now it’s exactly the other way round.

 

If you don’t have another suggestion, I’ll play around with the priorities, hoping to find a configuration that works...

[rphii]

Okay, quick update. I remembered that I used the `STAI_MODE_SYNC` method.

When I replace that with the `STAI_MODE_ASYNC` one, the communication seems to not break at first glance. Have to test if that is really true tho.

P.S. above I wrote NVENC but I obviously meant VENC, what a typo..

[rphii]

Alright, I saw this post here: 

where they talk something something about WFI something something.

Recall, the ASYNC code examples for the network use the LL_ATON_OSAL_WFE()...

• WFI = Wait for Interrupt
• WFE = Wait for Event

Seems similar, no?

Alright, the fix is actually really stupid simple.

    rc = stai_network_run(network_context, STAI_MODE_ASYNC);

    while((rc != STAI_DONE) && (rc != STAI_SUCCESS)) {
#if 0 /* simply DO NOT wait for an event here... */
        if(rc == STAI_RUNNING_WFE) {
            /* Wait for next event using OSAL primitive */
            LL_ATON_OSAL_WFE();
        }
#endif
        rc = stai_ext_network_run_continue(network_context);
    }

Now the I2C communication doesn’t immediately break into pieces.

However, for good measure, I also changed the IRQ priority, I don’t know and don’t care if that also helped (I believe it doesn’t really do much)

  /* initialize runtime */
  ret = stai_runtime_init();

  LL_ATON_OSAL_SET_PRIORITY(ATON_STD_IRQ_LINE, 12);

 

[rphii]

Alright, this is my 2nd time writing my reply here, since the first time the ST forum made it vanish, so I’ll keep it simpler.

This post 

 lead me down a rabbit hole and long story short, do this:

    rc = stai_network_run(network_context, STAI_MODE_ASYNC);

    while((rc != STAI_DONE) && (rc != STAI_SUCCESS)) {
#if 0 /* simply DO NOT WAIT FOR AN EVENT !!! */
        if(rc == STAI_RUNNING_WFE) {
            /* Wait for next event using OSAL primitive */
            LL_ATON_OSAL_WFE();
        }
#endif
        rc = stai_ext_network_run_continue(network_context);
    }

and for good measure...

  /* initialize runtime */
  ret = stai_runtime_init();

  LL_ATON_OSAL_SET_PRIORITY(ATON_STD_IRQ_LINE, 12); // for good measure