J784S4XEVM: Sensor Initialization

Harsha M Bhonsle

Part Number: J784S4XEVM

Hi Texas Instruments Support Team,

I am working with the TI imaging framework and have a question regarding the image sensor initialization flow. Currently, each application performs the following sequence:

appEnumerationImageSensor
appQueryImageSensor
appInitImageSensor
appStartImageSensor

We are noticing that this sequence introduces noticeable latency, and the overall initialization time is longer than expected when launching each application.

Our main requirement:
We want to avoid repeating this full initialization process in every application. Ideally, we would like to offload all initialization steps up to appStartImageSensor into a separate module or standalone application and have subsequent applications directly access the already‑initialized sensor state.

Before implementing such an approach, we would like to know:

Is there an officially recommended or supported method to persist sensor initialization across multiple applications?
For example, bypassing enumeration and initialization steps in the individual application and instead retrieving the initialized sensor configuration from a system-level service.
Can the sensor initialization be shifted to the MCU firmware or a centralized daemon so that applications do not need to re-run these steps?
If yes, what are the recommended APIs or sequences to achieve this?

Any guidance, best practices, or documentation references on optimizing or restructuring the sensor initialization workflow would be extremely helpful.

Thank you for your support.

2 months ago

0 Gokul S 2 months ago

TI__Mastermind 22090 points

Hi Harsha,

Image sensor control is handled in the mcu2_0 core, a72 core sends a remoteservicerun command to do the necessary operations.

You can refer to any vision_apps demos (single_cam or multi_cam demo) where the sensor_name is passed in every remoteservicerun call.

If you already hardcoded the name of the sensor you don't have to call enumeratesensor api's.

Harsha M Bhonsle said:
Can the sensor initialization be shifted to the MCU firmware or a centralized daemon so that applications do not need to re-run these steps?

You can initialize the sensor from any application/ core provided that you give the correct sensor name.

If your sensor is fixed, then you can do the init during the mcu2_0 boot time only and start the stream from application.

refer to this application node, for more details on optimizing sensor init time.

https://www.ti.com/lit/an/sprade5/sprade5.pdf?ts=1773113032469&ref_url=https%253A%252F%252Fwww.google.com%252F

Regards,
Gokul

0 Harsha M Bhonsle 2 months ago in reply to Gokul S

Prodigy 10 points

Gokul S said:
If your sensor is fixed, then you can do the init during the mcu2_0 boot time only and start the stream from application.

refer to this application node, for more details on optimizing sensor init time.

Following your guidance that, for a fixed sensor, we can perform sensor initialization during mcu2_0 boot and start the stream from the application, I have a follow‑up:

Our goal is to avoid the ~2.8–3.0 s latency we see only in appStartImageSensor. To achieve this, we would like to:

Run a persistent “init application” on mcu2_0 at boot which:
- Performs appEnumerationImageSensor, appQueryImageSensor, appInitImageSensor, and
- Also calls appStartImageSensor to start the sensor once, keeping the stream active.
Have subsequent main applications (started later) reuse the already-running stream, i.e., they should not run appStartImageSensor in the main application, but simply attach/consume frames from the active pipeline.

0 Gokul S 2 months ago in reply to Harsha M Bhonsle

TI__Mastermind 22090 points

Hi Harsha,

Harsha M Bhonsle said:
Our goal is to avoid the ~2.8–3.0 s latency we see only in appStartImageSensor

I don't think appStartImageSensor should take 3 s, it send only few commands to start the sensor, which sensor are you using ? can you check the commands need to send to start the sensor is correct, only the initialization (appInitImageSensor) of sensor can take more time.

Anyway, you have to create a capture node to dump the frames to the ddr, that capture node is process bound, you cannot create multiple capture nodes for the same virtual channels of csirx instance.

Harsha M Bhonsle said:
Have subsequent main applications (started later) reuse the already-running stream, i.e., they should not run appStartImageSensor in the main application, but simply attach/consume frames from the active pipeline.

I think you are asking something similar to DDS ?, we don't have any out of box implementation of such usecase.

There is a demo demonstration the buffer sharing across process ( with no-buffer copy) using unix sockets, you can refer to it https://software-dl.ti.com/jacinto7/esd/processor-sdk-rtos-jacinto7/11_01_00_04/exports/docs/vision_apps/docs/user_guide/group_apps_basic_demos_app_arm_fd_exchange.html

Regards,
Gokul

0 Harsha M Bhonsle 2 months ago in reply to Gokul S

Prodigy 10 points

Gokul S said:
I don't think appStartImageSensor should take 3 s, it send only few commands to start the sensor, which sensor are you using ?

We are using four IMX390 cameras, and only the appStartImageSensor() step is taking about 2.8–3 seconds. Since you mentioned this step should not take that long, could you please let us know if there is any way to reduce this startup time for IMX390 or if there are known delays when using four cameras? Any guidance on optimizing this step would be helpful.

0 Gokul S 2 months ago in reply to Harsha M Bhonsle

TI__Mastermind 22090 points

Hi Harsha,

The appnote I shared earlier also uses imx390 camera with ub953 serializer.

Refer to the section 2.5 Imaging Framework Optimizations to reduce the time using the broadcast mode.

Regards,
Gokul

0 Harsha M Bhonsle 2 months ago in reply to Gokul S

Prodigy 10 points

Gokul S said:
Refer to the section 2.5 Imaging Framework Optimizations to reduce the time using the broadcast mode.

I am not provided with the access for downloading the patch mentioned in the document. Could you please let me know how I can get access to dowload the patch file.

Regards,
Harsha M Bhonsle