TDA4VM: J7/TDA4VM boards have different behavior

Hi Carlo,

Please find answers to your questions below.

1) The remote processor firmwares must be loaded by u-boot or linux?

[Brijesh] both supports loading of firmwares, but typically they are loaded by uboot

2) Where are the MIPI CSI RX pin mux and setup happening?

[Brijesh] i think they are dedicated pins, no need to set pinmux

3) Is there a test app to run and check that all remote processors are up and running?

[Brijesh] yes, you could run ipc test vx_app_linux_arm_ipc.out file. This will send ipc to all running/enabled cores and tell if it ran fine.

4) Are there compiler options, tools or source code assertions/macros to detect memory leaks? In the faulty J7, the single_cam app has to be killed, it never returns cleanly.

[Brijesh] well what's the concern here? We have not any issue related memory. are you seeing any memory issue?

5) Are there any known issues in the fault J7 batches?

[Brijesh] Sorry did not get the question..

6) How can we proceed to solve this issue?

[Brijesh] Does the single cam application run fine on good SOM board?

Rgds,

Brijesh

Hi Brijesh in your message my replies :

Please find answers to your questions below.

1) The remote processor firmwares must be loaded by u-boot or linux?

[Brijesh] both supports loading of firmwares, but typically they are loaded by uboot

2) Where are the MIPI CSI RX pin mux and setup happening?

[Brijesh] i think they are dedicated pins, no need to set pinmux

​--->    So, the pins are always enabled? Is there any entry in the linux device tree?

3) Is there a test app to run and check that all remote processors are up and running?

[Brijesh] yes, you could run ipc test vx_app_linux_arm_ipc.out file. This will send ipc to all running/enabled cores and tell if it ran fine.

​---->   Ok, I've run it in both J7, the result is the same, all tests pass. 

4) Are there compiler options, tools or source code assertions/macros to detect memory leaks? In the faulty J7, the single_cam app has to be killed, it never returns cleanly.

[Brijesh] well what's the concern here? We have not any issue related memory. are you seeing any memory issue?

​---->  Among the last steps seems to be the allocated memory clean up. If the app gets stuck there might be an issue there. I've been modifying the SDK in all levels, mostly inserting debugging printf. Even in the "working" J7, sometimes the single_cam app gets stuck at exiting. I've got no clue why.

So, what is the recommended procedure to debug memleaks in the accelerators? Do all of them have memory protection set up and running? If not, it may be very hard to fix memleaks during development. Thanks for your advice.

5) Are there any known issues in the fault J7 batches?

[Brijesh] Sorry did not get the question..

6) How can we proceed to solve this issue?

[Brijesh] Does the single cam application run fine on good SOM board?

--->     Yes, but we still have one board that cannot be used.

​If there is no other solution to test here, can we somehow send the board for checking?

Rgds,

Brijesh

Hello Carlos,

Could you please share the log of single cam example for both the cases, ie where you are seeing memory leak or error while exiting and one where SOM board is not working.

Rgds,

Brijesh