MCU-PLUS-SDK-AM243X: Hardware question: custom board problem communication between am243x and m3.

Hello Jun Tu,

Jun Tu said:

After building a customized board, the internal communication between the AM243x and the M3 is not functioning, and the board gets stuck at the Sciclient indefinitely.

Can you please confirm for which operation R5F/M4F core is not getting any response from M3 core ?

Since all device management and security operations handled by DMSC (M3) Core  like, reset, clock, interrupts and security functionality etc. through SCI client calls.

So, definitely R5F / M4F core should send the SCI client request to get a response from M3 Core.

Tell me the SCI client API with what parameters are sending when M3 is not responding.

Regards,

Anil.

Hi, Swargam, we can be sure, it is a hardware problem.  after production, 40% of boards has this problem. 

we are trying to run sciclient_ccs_init.release.out, and reach hello world.    but with 50% of these defect boards, it can't reach hello world. 

Then, I build sciclient_ccs_init.debug.out. For defect board,  it will stuck at this message. (For good board, it won't have this problem.) 

but what could be the pin affect this behavior, there are too much pins to compare. do you have a list?  there are too many pins to compare, so far we didn't find the difference.  So if there are list of possible pininput corrupt the communication.

So two reason. 1. data send to dmsc is corrupted.   (looks like the issue) 2. we don't receive the ack whatever back.

which list of pins will affect bus between m3 and r5f?

so eventually, the defect board, will stuck at sciclient_waitformessage forever. 

by using debug, we found, CUR_CNT, is already not right when sent the message. 

Jun Tu said:

but what could be the pin affect this behavior, there are too much pins to compare. do you have a list?  there are too many pins to compare, so far we didn't find the difference.  So if there are list of possible pininput corrupt the communication.

Hello Jun,

You are talking about which pins ?

I really don't understand the above point.

Typically to configure GPIO pins we never  calls SCI client .

The sysfw has a bin file which will include in SBL and SBL will initialize SYSFW.

This is how we are following the method to initialize SYSFW on AM64X/AM243X devices .

Regards,

Anil.

Hi, Swargam:

We are encountering a hardware issue with our customized board. It seems that there might be a problem with either a bad pull-up or a bad ground on some pin, or possibly a mistake in the design or assembly. About 50% of the boards are functioning correctly, but the other half are experiencing issues.

Due to the large number of pins, it is very challenging to pinpoint which specific pin might be causing the problem or generating noise.

From a software perspective, the issue manifests as a failure during the sciclient wait. This indicates that the communication between the R5F and M3 processors is breaking down.

Could you help us understand how to approach diagnosing this issue, both from a hardware and software standpoint, to identify the problematic pin(s) and resolve the communication failure?

Thanks.


By the way, Software gpio init has nothing to do with that, I completely agreed with you. Typically to configure GPIO pins we never  calls SCI client ..  It is definitely a hardware problem. it might be some noise added into internal bus between r5f and m3.

or can you point me a internal hardware schematics for r5f and m3, so we can take a look which pin might affect bus communication between r5f and m3. Thanks

Hi, Anil, Thanks, after we focues on the reset pin that you just mentioned, we found the problem and now, it run succesfully. 

Again, many thanks for your support.