PCM9211EVM-U: TXOUT to MP0 causes TXOUT on MP1

Eric, when you write to register h78 in  both cases, please do a READ for those registers immediately and see what it reads. If read is  correct, I would put another READ at the very end of the script as well to see that it writes but then it get changed by something. or a conflict.

Regards,

Arash

Hi Arash,

okay i tried it and it is really interessting. Please see the script below. 

Script 

#Can't route LOCK to MP1 and TXOUT to MP0 thats why reversed
#w 80 78 dd -> causes disconnect
#w 80 78 bd -> causes TXOUT on MP0 and MP1 
w 80 78 bd
#w 80 78 db
r 80 78 01

#Set MPIO_A/B IO direction (not used)
w 80 79 00

#Set MPIO_C IO direction (not used)
w 80 7a 00

#Set MPIO_A/B IO output level (not used)
w 80 7b 00

#Set MPIO_C IO output level (not used)
w 80 7c 00

#7d MPIO_A/B IO input level (read only, not used)
#7e MPIO_C IO input level (read only, not used)
r 80 78 01

Readback 

r 80 78 01:
  BD 
r 80 78 01:
  DD 

I write 0xBD to the register 0x78 and the first readback is correct with 0xBD. But the last readback at the end shows 0xDD. But as you can see I do not write to the register again. I stripped down the script to avoid any other conflicts but it also happens when you just place these 3 lines into the script. 

w 80 78 bd
r 80 78 01
r 80 78 01

The first read will show the correct response 0xBD, the second read will show 0xDD. The board was resetted before of course. 

This is very strange. Do you have any explanation for this?

Best regards,

Eric 

Okay, so as I suspected , it rewrites it again with D . It is interesting but I am sure there is a logic behind it, we just need to find it out!

One way to investigate this, is to read all registers right after both reads and then compare and see what else has changed.  That is

w 80 78 bd
r all registers
r all registers

(Compare the above 2 separate reads using any software  such as Beyond Compare or similar- programs)

You can also WRTIE 0xDB  and do the same reads for this case again and now compare this set of reads with the previous  case to see what has changed.( I think the first read of this case (0xbd) should match with the first read of the other case (*0xdb)  but the second read would be different. 

Another experiment that you can do is to pick another  cases other than LOCK and TXOUT  ( for example MCKO or something else) and do the swap of registers to see if it reads correctly or it rewrites it again.

It is very interesting thing and I  have never seen this before, probably something is conflicting this register and overwrites it )

Regards,

Arash

Hey Arash,

so i tried what you said. By the way "r all registers" is not working. It gives an error in the command window. I used instead "r 80 20 5e" which is used in the example script to read out all registers. This worked correctly. Here you can see the difference. 

The 08 08 in line 3 are just the registers 0x38, 0x39 which are read only so thats not a problem. Then as expected in line register 0x78 has changed from 0xBD to 0xDD. The last regsiter is register 0x7D which is not used. It is not in the datasheet so i could even skip it by reading one byte less. 

So it really seems that only register 0x78 has changed. But i noticed one thing. When I press "record" in the command window to see what happens, I can see that the CodeControl software adds the "w 80 78 DD" by itself. Please see the picture below:

Thats why the register value changes. So there are 2 questions from my side:

- Why does this happens?

- Do you think when I write the register 0x78 to 0xBD with my MCU in the later product it will work correctly or do you think the software prevents this setting due to some internal limitations?

By the way, same effect for MCKO or every other setting and TXOUT. It is always the same when TXOUT 0x0d is routed to MP0, it always apperas on MP1. Here a snippet of a different setting. CodeControl Software always writes 0xDD to 0x78 by its own. 

Best regards,

Eric

Hi Eric,

When I mentioned R all registers , I did not mean it is the script, it was the instruction only for debug procedure !! Probably I should have not put it in script format. 

I have never seen  a code being added to the script, but frankly I don't use CodeControl, instead I use the I2C master that comes with PPC3 (Pure Path Control)software. You can download PPC3 from ti site and its GUI looks identical to above, Try it with PPC3 and if it doesn't do it , it is a CodeControl related issue.

Another suggestion that I have is to set those registers to default and see if it adds the extra line at the end again or under what conditions it doesn't do it.

Regards,

Arash

Hi Arash,

thanks a lot for your update. I will retry it with PPC3 and let you know. I tried it with a MCU in parallel and there everything seems to work fine. Seems to be really a bug of CodeControl. Thanks for all your help. 

Best regards,

Eric