PGA460: PGA460 and PGA460EVM

Hi Yoshifumi,

Can you tell me the following:

• Do you observe an issue in the checksum of each packet or do you only notice this once in a while?
• Can you probe the RX and TX lines with a logic analyzer and show me the logic analyzer output?
• If you add to add a pull-up resistor on the TX pin of the PGA460, does this fix your issue?

At higher baud rates, you can be more likely to get transmit and receive errors.  As an example, here is a snippet from a microcontroller user’s guide that shows how the UART TX and RX errors can increase at higher baud rates for that specific microcontroller family:

If it is available, can you try a lower-jitter clock source for the baud rate generator in your microcontroller to see if it makes a difference? 

Thank you,

Mekre

Dear Sir.

Thanks for your feedback.

So, I normally check several command and response as followings(hex value), @115.2k bps

init cmd reg cs diag resp CS
55 09 5F 97 40 81 7E -------> expected CS value :3E
55 09 60 96 40 44 FF -------> expected CS value :7B
55 09 61 95 40 56 FF -------> expected CS value :69
55 09 62 94 40 60 FF -------> expected CS value :5F
55 09 63 93 40 00 FF -------> expected CS value :BF
55 09 64 92 40 04 FF -------> expected CS value :BB
55 09 65 91 40 99 66 -------> expected CS value :26
55 09 66 90 40 CE 31 -------> expected CS value :F0
55 09 67 8F 40 73 FF -------> expected CS value :4C
55 09 68 8E 40 9C 63 -------> expected CS value :23
55 09 69 8D 40 E7 18 -------> expected CS value :D7

This beavior is 100% reporducible with no difference. If you say some error rate, then that couble be not reporducible?
We already built the desinged board including the IC and drivers.

About attached 1st figure;
I will attach some OSC waveform. upper one is sending command and lower is response.
I have no capability of logic analyzer now, so I read out bit data according to the location of 2x stop(Hi) bit and 1x start(Lo) bit position.
*One point, you can see the same waveforms on both, becuase our board has other converter circuit,
Uart signal goes to CAN tranceiver to initiate differential signal to send to twist pair lines and converted again to reciever side,
so "echo" signals are presented. I connected our UART sigal to TI borad just beofre PGA460 input(TXD, RXD).

About attached 2nd figure;
That is reference from TI-board. I picked TXD and RXD pinout to OSC.
There are 4 x send/receive signals per one "inteface mode" tranzaction(09 5F)
I saw the right response including CS (this case, 55 09 1F D7 -> 40 10 AF)
I also want to know the meaning of spike pulse on the response, is any description somewhere?

Again, thanks for your error exapmle table for IC. But, as I asid above, pesent error is not 100%-reproducing.
That could be a frequency matter?

Best regards,

Yoshifumi YAMAOKA

Dear Mekre. 

I found the reproducing procedure even at PGA460-Q1 EVM, not from our H/W about this. 

1. connnect TI board to PC, uart address is 0.

2. then at Interface Mode, send  CMD 25 (Threshold bulk write, sam as CMD 16)

write the following data 

81445660000499CE739CE738C8C8C80081445660000499CE739CE738C8C8C800

3. Then read 5F reg value by changing the baudrate from 115.2k to 57600.

please see attached screen shot. You can see different response....

I guess, even if I send register write command, still NVM are not written completely.

My concerning is our configuration procedure has something wrong, then this issue happend. So, I really need you to check the our configuration procedure and check if something missing.

Sorry, I copy our software configuration procedure with our protocol. But, I guess, that is better for yur check and correction if any. 

I share the acutal command I send using our IC
Protocol is
cmd_[address]_[CMD(dec)]_[data]

for example, in case cmd 0 22 1483
target uart address = 0
cmd = 22(dec) = Broadcast Register Write
reg address = 14(hex)
writng data = 83(hex)

" RET.OK " those lines are  -> SW response. 

*************** below is inital setting ****************************

[2022-04-08 17:51:19.575] => cmd 0 22 1483
[2022-04-08 17:51:35.926] RET: OK
[2022-04-08 17:51:35.926] => cmd 0 22 1588
[2022-04-08 17:51:36.035] RET: OK
[2022-04-08 17:51:36.035] => cmd 0 22 1680
[2022-04-08 17:51:36.129] RET: OK
[2022-04-08 17:51:36.145] => cmd 0 22 1766
[2022-04-08 17:51:36.239] RET: OK
[2022-04-08 17:51:36.239] => cmd 0 22 18FD
[2022-04-08 17:51:36.332] RET: OK
[2022-04-08 17:51:36.332] => cmd 0 22 19FF
[2022-04-08 17:51:36.442] RET: OK
[2022-04-08 17:51:36.442] => cmd 0 22 1A00
[2022-04-08 17:51:36.536] RET: OK
[2022-04-08 17:51:36.536] => cmd 0 22 1B40
[2022-04-08 17:51:36.645] RET: OK
[2022-04-08 17:51:36.645] => cmd 0 22 1C8C
[2022-04-08 17:51:36.754] RET: OK
[2022-04-08 17:51:36.754] => cmd 0 22 1D80
[2022-04-08 17:51:36.863] RET: OK
[2022-04-08 17:51:36.863] => cmd 0 22 1ED4
[2022-04-08 17:51:36.957] RET: OK
[2022-04-08 17:51:36.957] => cmd 0 22 1F14
[2022-04-08 17:51:37.066] RET: OK
[2022-04-08 17:51:37.066] => cmd 0 22 207F
[2022-04-08 17:51:37.160] RET: OK
[2022-04-08 17:51:37.160] => cmd 0 22 217F
[2022-04-08 17:51:37.254] RET: OK
[2022-04-08 17:51:37.254] => cmd 0 22 2211
[2022-04-08 17:51:37.379] RET: OK
[2022-04-08 17:51:37.379] => cmd 0 22 2300
[2022-04-08 17:51:37.473] RET: OK
[2022-04-08 17:51:37.473] => cmd 0 22 24EE
[2022-04-08 17:51:37.582] RET: OK
[2022-04-08 17:51:37.582] => cmd 0 22 2519
[2022-04-08 17:51:37.676] RET: OK
[2022-04-08 17:51:37.676] => cmd 0 22 264F
[2022-04-08 17:51:37.785] RET: OK
[2022-04-08 17:51:37.785] => cmd 0 22 2700
[2022-04-08 17:51:37.879] RET: OK
[2022-04-08 17:51:37.879] => cmd 0 22 2800
[2022-04-08 17:51:37.988] RET: OK
[2022-04-08 17:51:37.988] => cmd 0 22 2909
[2022-04-08 17:51:38.098] RET: OK
[2022-04-08 17:51:38.098] => cmd 0 22 2A09
[2022-04-08 17:51:38.192] RET: OK
[2022-04-08 17:51:38.192] => cmd 0 22 4000
[2022-04-08 17:51:38.301] RET: OK
[2022-04-08 17:51:38.301] => cmd 0 22 418A
[2022-04-08 17:51:38.395] RET: OK
[2022-04-08 17:51:38.395] => cmd 0 22 420C
[2022-04-08 17:51:38.504] RET: OK
[2022-04-08 17:51:38.504] => cmd 0 22 43F9
[2022-04-08 17:51:38.598] RET: OK
[2022-04-08 17:51:38.598] => cmd 0 22 44A5
[2022-04-08 17:51:38.722] RET: OK
[2022-04-08 17:51:38.722] => cmd 0 22 4503
[2022-04-08 17:51:38.816] RET: OK
[2022-04-08 17:51:38.816] => cmd 0 22 462D
[2022-04-08 17:51:38.926] RET: OK
[2022-04-08 17:51:38.926] => cmd 0 22 477E
[2022-04-08 17:51:39.019] RET: OK
[2022-04-08 17:51:39.019] => cmd 0 22 4867
[2022-04-08 17:51:39.113] RET: OK
[2022-04-08 17:51:39.128] => cmd 0 22 4900
[2022-04-08 17:51:39.222] RET: OK
[2022-04-08 17:51:39.222] => cmd 0 22 4ACD
[2022-04-08 17:51:39.316] RET: OK
[2022-04-08 17:51:39.316] => cmd 0 22 4B00
[2022-04-08 17:51:39.441] RET: OK
[2022-04-08 17:51:39.441] => cmd 0 22 4C80
[2022-04-08 17:51:39.535] RET: OK
[2022-04-08 17:51:39.535] => cmd 0 22 4D00
[2022-04-08 17:51:39.659] RET: OK
[2022-04-08 17:51:39.659] => cmd 0 25 81 44 56 60 00 04 99 CE 73 9C E7 38 C8 C8 C8 00 81 44 56 60 00 04 99 CE 73 9C E7 38 C8 C8 C8 00
[2022-04-08 17:51:39.754] RET: OK
[2022-04-08 17:51:39.754] => cmd 0 12 000000000000000000000000000000000000000083888066FDFF00408C80D4147F7F1100EE198F00000000
[2022-04-08 17:51:39.863] RET: OK
[2022-04-08 17:51:39.878] => cmd 0 10 4068
[2022-04-08 17:51:39.972] RET: OK
[2022-04-08 17:51:39.972] => cmd 0 10 4001
[2022-04-08 17:51:40.066] RET: OK
[2022-04-08 17:51:40.066] =>

---> End of our configuration.

*********************** below is register check command and response **********************************

[2022-04-08 17:52:10.402] cmd 0 09 5F
[2022-04-08 17:52:10.480] RET: 40 81 7E
[2022-04-08 17:52:10.480] => cmd 0 09 60
[2022-04-08 17:52:10.590] RET: 40 44 FF
[2022-04-08 17:52:10.590] => cmd 0 09 61
[2022-04-08 17:52:10.684] RET: 40 56 FF
[2022-04-08 17:52:10.684] => cmd 0 09 62
[2022-04-08 17:52:10.793] RET: 40 60 FF
[2022-04-08 17:52:10.793] => cmd 0 09 63
[2022-04-08 17:52:10.887] RET: 40 00 FF
[2022-04-08 17:52:10.887] => cmd 0 09 64
[2022-04-08 17:52:11.011] RET: 40 04 FF
[2022-04-08 17:52:11.011] => cmd 0 09 65
[2022-04-08 17:52:11.106] RET: 40 99 66
[2022-04-08 17:52:11.106] => cmd 0 09 66
[2022-04-08 17:52:11.215] RET: 40 CE 31
[2022-04-08 17:52:11.215] => cmd 0 09 67
[2022-04-08 17:52:11.309] RET: 40 73 FF
[2022-04-08 17:52:11.309] => cmd 0 09 68
[2022-04-08 17:52:11.418] RET: 40 9C 63
[2022-04-08 17:52:11.418] => cmd 0 09 69
[2022-04-08 17:52:41.848] RET: 40 E7 18
[2022-04-08 17:52:41.848] => cmd 0 09 5F
[2022-04-08 17:53:06.764] RET: 40 81 7E
[2022-04-08 17:53:06.764] => cmd 0 09 60
[2022-04-08 17:53:06.858] RET: 40 44 FF
[2022-04-08 17:53:06.874] => cmd 0 09 61
[2022-04-08 17:53:06.983] RET: 40 56 FF
[2022-04-08 17:53:06.983] => cmd 0 09 62
[2022-04-08 17:53:07.077] RET: 40 60 FF
[2022-04-08 17:53:07.077] => cmd 0 09 63
[2022-04-08 17:53:07.186] RET: 40 00 FF
[2022-04-08 17:53:07.186] => cmd 0 09 64
[2022-04-08 17:53:07.280] RET: 40 04 FF
[2022-04-08 17:53:07.280] => cmd 0 09 65
[2022-04-08 17:53:07.389] RET: 40 99 66
[2022-04-08 17:53:07.389] => cmd 0 09 66
[2022-04-08 17:53:07.483] RET: 40 CE 31
[2022-04-08 17:53:07.483] => cmd 0 09 67
[2022-04-08 17:53:07.608] RET: 40 73 FF
[2022-04-08 17:53:07.608] => cmd 0 09 68
[2022-04-08 17:53:07.701] RET: 40 9C 63
[2022-04-08 17:53:07.701] => cmd 0 09 69baud
[2022-04-08 17:53:39.688] RET: 40 E7 18
[2022-04-08 17:53:39.688] => baud
[2022-04-08 17:54:00.918] RET: 115200
[2022-04-08 17:54:00.918] =>

 Best reagrds,

Yoshifumi YAMAOKA

Hi Yoshifumi,

Can you set UART_DIAG=0 and let me know what you values you get for the diagnostic byte?

Thank you,

Mekre

Dear SIr, 

You means the attached screen shot? Oh, Mismatched WIdths? 

Rgs,

Yamaoka

Dear Sir,

again. I really see this Diag. I also tried to start EVM "after loading some configuration data from Memory Map". Then, tried this writitng, then no Diag error.

So,  I guess, when our IC send the TH bulk register write command, IC finished with Diag error. But, then I do not know how to fix this. Is any command is missing before sending  this CMD 09?

Rgs

Yamaoka

Excuse me again. 

I want to know the actual command (right procedure) set which your EVM board doing during the config file loading at "memory map" .In case I skip this procedure, I got some diag error by every register byte wriitng in interface mode. So, it looks something missing from our commands. 

Rgs,

yoshifumi Yamaoka  

Hi Yoshifumi,

Can you try adding a pull-up resistor on the TX pin of the PGA460 to see if it helps?

Thank you,

Mekre

Dear Mekre,

I just want to confirm, now I'm under checking the response behavior on the TI's baughter board. So, your request is 

1. Put the pull-up rsister on the TI's board, that means modify the TI's board.

2. Then, by skipping initial config file loading, using the GUI's inface mode, send the register writing command and check the Diag response.

Is corect? 

Rgs,

Yoshifumi YAMAOKA

Hello, Mekre,

I put the 3.3k pull-up resister to 3.3V. Now, TX singal pull up to 3.3V at normal, therefore can not see the short pulse at start ppoint of response  and no singal tailing on the end. But, behavior looks no difference. Please see attached screen shot in case register read. 

One point, now I see MIsmatched WIdths diag is initiated, so Diag byte changed from 40 to 44, then CS value also changed on the last byte. 

Other point, 

just after start GUI, I can see CRC error. But it cuased by nismatching when start up ...

Also, when th bulk data write, I  can not see error., but not sure if this behavior is true or not. 

Best regards,

Yoshifumi Yamaoka

Dear Mekre-san, 

I also tried to trigger PGA460A on the TI-board by our IC's software. I set the Uart_Diag =0, So, in this case, if the same issue may happned by our IC, then we could get the Diag response "44" from TX lines. But, actual Diag response is "40". So, I guess this "width mistach error" not happned by driving our IC.

See attached log list. 

I also checked the written register bulk valeus... The readout says those parameters are written properly. And only response at 115.2k baudrate is wrong. Response at 57600 baudrate is fine.

I guess, there is wrong response only from 115.2k bps baudrate... That might happen everytime? 

Please advise your suggestion.

Rgs,

Yoshifumi Yamaoka

Dear Mekre-san, 

I also add the our IC board and IC information, we  use for PGA460-inmplemented development board. 

uC is "Renesus RL78/G13", 16-Bit Single-Chip Microcontrollers

https://www.renesas.com/jp/ja/document/man/rl78g13-users-manual-hardware?language=en

the development board for thi Renesus IC is (It looks Japanese products,  but you may see circuit information of this  board in EN, see PDF-link below)

https://www.marutsu.co.jp/pc/i/239824/

https://www.marutsu.co.jp/contents/shop/marutsu/datasheet/BLUEBOARD-RL78G13_64PIN.pdf

I see some spec of error value at UART application inside Renesus PR78/G13, but not sure those are impact on the 115.2k communication. 

1. I need your adive if UART application using ths uC at 115.2k bps baudrate makes probelm in CS response. 

2. If so, then how recover the probelm

* I shared those info just in case for your investigation. I still need your advise of any resolution about previous probelm we discussion before. 

Best regards,

Yoshifumi Yamaoka 

Hi Yamaoka-san,

Thank you for the details.  I will take a closer look tomorrow.

Regards,

Mekre

Hello, I took more data .

Results on 4/18/2022
1. checked the autual baudrate (estmated from bit pulse width) on PGA460 inside TI eval board using GUI.
In case of setting 115.2k bps, estimated baudarte is more than 4%, then response CS from CMD9 is okay. Same as setting 56700.
2. Also drived our developement board (Renesas RL79/G13).
@115,2k_bps setting, response CS are all wrong. The estimated baudrate is from 112.7k to 116.2k bps.
@56,7k_bps: response CS is okay.
Please take a look on screen shot from OSC, with logic analyzed results. The estimated baudrate by our IC is ~115.2k + a bit , so, it is critial to say actual baudrate is faster than 115.2k bps.... Looks the CS issue could be not by baudrate?

(note: from the analyzer logic issue, the output hex data is adding "1" at inital bit, so when you read data, please ignore the first "1".)
TX lines in PGA460A is pull-uped by 3.3k-ohm resister inside TI board. So, there in no tailing behavior on TX line signals.

Rgs,

Yoshfiumi Yamaoka

Hi Yamaoka-san,

Sorry for the delay.  We were out for holiday on Friday.

After startup, I would expect the THR_CRC_ERR flag to be asserted if you did not write the threshold values yet.  If you try to do a burst and listen operation without setting the thresholds, you also see the following dialog box:

If you click “Yes” to the above dialog box, the thresholds are initialized to mid-code and the error goes away.  If you manually set the thresholds, this should also clear the THR_CRC_ERR flag.

Also, I tried the procedure you mentioned and I did not observe any issues.  Here are the steps I followed:

1. Connect EVM to PC with uart address set to 0.
2. Send CMD 25 (broadcast threshold bulk write) with the data you mentioned. Here is the resulting screen shot: 
3. Then read 5F reg value. Even with a baud rate of 115200, I see 0x3E as the checksum instead of 0x7E.  Here is the screenshot of this:

Are you still observing issues when you follow the procedure above?

Regards,

Mekre

Hi Yamaoka-san,

I am more concerned about the stability of the clock.  The entries circled red in the picture below have a larger deviation from the average bitpulse.

Can you tell me what the “2” represents?  Is this the second trial of the bitpulse measurement or is that a specific byte within a packet?

The sync field is used by the PGA460 device to confirm the correct baud rate of the frame that is sent by the controller.  If the clock drifts from when the sync byte was received, then the PGA460 may assume an incorrect baud rate.  If possible, can you configure the baud rate generator to use a more stable clock source to see if that makes a difference?

Thank you,

Mekre

Dear Mekre,

1. About GUI issue

- I did burst and listen with THR_CRC_ERR flag, I never see he messgae, you mentioned. 

- Now error is gone, then I followed your procedure, I still see the wrong response of CS at 115.2k bps. 

-> I will check if any other difference inside our TI board. 

2. About your question about baudrate precison

- 1, 2, 3, 4, 5, 6, 20 means the number of command sending test Try.

- You may see another attached excel plot from data I shared.

Blue dots are TI-board results, Red dots are our uC results and black line is 115.2k bps. 

As you suggested distribution of red dots looks large, but I guess the mean values may be close to 115.2k bps. 

On the other hand, the estimated baudrate from TI-board looks too higer than 115.2kpbs.... That could be strange. 

The calculation way to get baudrate I conducted is 

1. check some of single bit pulse (0 ->1 -> 0) inside response data, then measured the duration (e.g. 8.3us...), my OSC has a feature to pick up those pulse width.

2. then just invert this, e.g. 1/8.3us = 120481.9 bps .... 

Those make sense?

Regards,

Yoshifumi Yamaoka

Hi Yamaoka-san,

Since the maximum baud rate supported by the PGA460 is 131.5 kbps, I am more concerned about the clock drifting within a packet than having a baud rate slightly higher than 115.2ksps.

Are you able to measure the duration of the different bits within a packet?  Can you try a more stable clock source for your microcontroller?

Regards,

Mekre 

Hello, Mekre-san, 

Please see the todays's results. I used the same but new board. See red dots (blue TI data are same as yesterday). 

- Today, I never see lower baudrate, but distribution is not good. 

- I also checked the other pulse durations...It' hard, but I never see a big distribution, even at last short bit including "7" our of "7E"

- Sorry, for more precise setting, I have another discussion inside my HW team. 

- I removed the circuit which related the "echo" signal, we saw befoe. But the results are same. 

I have another two questions and confirmations. 

1. In this UART comunication, we DO NOT NEED to connet CLK signal to PGA460. Is correct?

2. when our bulk writing, our IC send 

cmd 0 25 81 44 56 60 00 04 99 CE 73 9C E7 38 C8 C8 C8 00 81 44 56 60 00 04 99 CE 73 9C E7 38 C8 C8 C8 00

cmd 0 12 000000000000000000000000000000000000000083888066FDFF00408C80D4147F7F1100EE198F00000000

cmd 0 10 4068

cmd 0 10 4001

Last two commands are related with register 0x40. So, write 0x68, then write 0x01 for Programming.... This procedure is right?

Best regards

Yoshifumi YAMAOKA

Hi Yamaoka-san,

We recommend connecting the SCLK pin to GND if you are using UART instead of SPI.  Doing this prevents noise from triggering the clock input.

The procedure you mentioned for writing to EEPROM is correct.  After doing this, you could also read register 0x40 to see if the EE_PRGM_OK is set as expected.

Regards,

Mekre

Dear Mekre-san, 

Thanks for your feedback. 

1. I tried to put the CLK signal from our IC, but there is no siginificant change. But, our dev board doesn't  have this feature(it's my special debugging), so if recommended we can not implement. 

2. Thanks for your confimration, I got the response from 0x40 as 40 84 3B. So, looks good.

According to previuous discussion, may be the individual bit width might shifted (very) slightly each other, then we could not get right response as CS at 115.2K bps...

I discussed with our System Team, then, becuase we already finish the the board development, so additional mdification inside is hard. Therefore, now I would take;

1. Changing the baudrate speed setting lower in our dev IC, then check the response CS behavior.

2. then try to get the maximum speed limit which support the right CS response. 

We need to get best effort of total system procedure cycle, so this is important, for customer. 

Best regards,

Yoshifumi YAMAOKA

Hi Yamaoka-san,

I believe what you mentioned would be the best way to proceed.

Regards,

Mekre

Dear Mekre-san,

Excuse me I forgot to ask you some points around this issue. 

1st point:

1. I guess, the acutal value of baudrate itself is not critical, becuase PGA460 detect baudrate automatically by input pulse signal..Is correct?. So, reason of error may be caused by shifting or drifiting the acutal bit pulse, then that is critical. 

2. If so, then you have any requirement for stability spec for the input signal on the baudrate? Especially for support 115.2kbps? 

3. Also, TI's evaluation board could meet the spec. Is any information about the requirements?

4. May be, the point chould be frequency of the Crystal for IC. We can not make some over-clocking, but can consider on selecting better crystals which has more stale spec.. 

2nd point: 

1. Could you advise the baudrate detection algorithm? I guess, PGA460 estimates the baudrate from the waveform of input signal. So, how about the PGA460 estimate the baudrate? the First input bit to RX lines? The first 55 would be 0101 0101, then that could be the better sample to estimate the baudrate?

2. Because, in case I shifted the baudrate lower then I need to know which point of signal bits I need to observe. 

Please advise,

 Yoshifumi Yamaoka 

Hi Yamaoka-san,

Yes, the PGA460 would determine the baud rate based on the timing of the sync field.  Section 7.3.6.2.1.1 of the datasheet provides more info on the baud rate detection algorithm. 

Could you also try adding a large delay between consecutive commands to see if it makes a difference?  For the delay, you could use 20 ms.

In addition, could you try adding a small delay (200 us) between consecutive bytes within a packet?  I am curious to see if this makes a difference.

Regards,

Mekre

Hello, 

I found the condtion to clear the CS response bug. 

Register 1Eh bit7 = IO_IF_SEL should be 0 insted 1 (see attached)

I need the reason why.....

 > cmd 0 09 5F
RET: 40 81 3E
=> cmd 0 09 5F
RET: 40 81 3E
=> cmd 0 09 60
RET: 40 44 7B
=> cmd 0 09 61
RET: 40 56 69
=> cmd 0 09 62
RET: 40 60 5F
=> cmd 0 09 63
RET: 40 00 BF
=> cmd 0 09 64
RET: 40 04 BB
=> cmd 0 09 65
RET: 40 99 26
=> cmd 0 09 66
RET: 40 CE F0
=> cmd 0 09 67
RET: 40 73 4C
=> cmd 0 09 68
RET: 40 9C 23
=> cmd 0 09 69
RET: 40 E7 D7
=> cmd 0 11
RET: 40 000000000000000000000000000000000000000083888066FDFF00408C8054147F7F1100EE198F00000000 71
=> cmd 0 15
RET: 40 81445660000499CE739CE738C8C8C80081445660000499CE739CE738C8C8C800 D8
=> cmd 0 09 5F
RET: 40 81 3E
=> cmd 0 09 60
RET: 40 44 7B
=> baud
RET: 115200

Hi Yamaoka-san,

Can you tell me if you have the IO pin of the PGA460 connected to anything?

Regards,

Mekre

Dear Mekre-san,

Sorry for late notice. I was in hoilday. 

It is OPEN ended. 

But opened land for reisistance is there. 

Rgs,

Yoshifumi Yamaoka

Hi Yamaoka-san,

Can you also try setting the IO_DIS bit to 1 while IO_IF_SEL=0?  Does this still fix the issue?  Since you are not using the IO pin for one-wire UART or the TCI interface, you should be able to disable it.

Regards,

Mekre

Dear Mekre-san,

I set 74(0111 0100) instead 54(0101 0100), then it looks okay. See the follwing  log.

I also found,

if I do bulk write NG dat set after reboot PGA460 circuit, then reproduce the CS errors. But, if I overwite the OK data set without reboot, then overwrite NG data again, the CS error not happnes....I guess that  should be somthing wrong...Could you check. 

Rgs,

Yoshifumi Yamaoka

=> cmd 0 10 4068
RET: OK
=> cmd 0 10 4001
RET: OK
=> cmd 0 22 1483
RET: OK
=> cmd 0 22 1588
RET: OK
=> cmd 0 22 1680
RET: OK
=> cmd 0 22 1766
RET: OK
=> cmd 0 22 18FD
RET: OK
=> cmd 0 22 19FF
RET: OK
=> cmd 0 22 1A00
RET: OK
=> cmd 0 22 1B40
RET: OK
=> cmd 0 22 1C8C
RET: OK
=> cmd 0 22 1D80
RET: OK
=> cmd 0 22 1ED4
RET: OK
=> cmd 0 22 1F14
RET: OK
=> cmd 0 22 207F
RET: OK
=> cmd 0 22 217F
RET: OK
=> cmd 0 22 2211
RET: OK
=> cmd 0 22 2300
RET: OK
=> cmd 0 22 24EE
RET: OK
=> cmd 0 22 2519
RET: OK
=> cmd 0 22 264F
RET: OK
=> cmd 0 22 2700
RET: OK
=> cmd 0 22 2800
RET: OK
=> cmd 0 22 2909
RET: OK
=> cmd 0 22 2A09
RET: OK
=> cmd 0 22 4000
RET: OK
=> cmd 0 22 418A
RET: OK
=> cmd 0 22 420C
RET: OK
=> cmd 0 22 43F9
RET: OK
=> cmd 0 22 44A5
RET: OK
=> cmd 0 22 4503
RET: OK
=> cmd 0 22 462D
RET: OK
=> cmd 0 22 477E
RET: OK
=> cmd 0 22 4867
RET: OK
=> cmd 0 22 4900
RET: OK
=> cmd 0 22 4ACD
RET: OK
=> cmd 0 22 4B00
RET: OK
=> cmd 0 22 4C80
RET: OK
=> cmd 0 22 4D00
RET: OK
=> cmd 0 25 81445660000499CE739CE738C8C8C80081445660000499CE739CE738C8C8C800
RET: OK
=> cmd 0 12 000000000000000000000000000000000000000083888066FDFF00408C8074147F7F1100EE198F00000000
RET: OK
=> cmd 0 10 4068
RET: OK
=> cmd 0 10 4001
RET: OK
=> cmd 0 09 5F
RET: 40 81 3E
=> cmd 0 09 60
RET: 40 44 7B
=> cmd 0 09 61
RET: 40 56 69
=> cmd 0 09 62
RET: 40 60 5F
=> cmd 0 09 63
RET: 40 00 BF
=> cmd 0 09 64
RET: 40 04 BB
=> cmd 0 09 65
RET: 40 99 26
=> cmd 0 09 66
RET: 40 CE F0
=> cmd 0 09 67
RET: 40 73 4C
=> cmd 0 09 68
RET: 40 9C 23
=> cmd 0 09 69
RET: 40 E7 D7
=> cmd 0 11
RET: 40 000000000000000000000000000000000000000083888066FDFF00408C8074147F7F1100EE198F00000000 51
=> cmd 0 15
RET: 40 81445660000499CE739CE738C8C8C80081445660000499CE739CE738C8C8C800 D8
=> cmd 0 09 5F
RET: 40 81 3E
=> cmd 0 09 60
RET: 40 44 7B

Hi Yamaoka-san,

Since you are not using the IO pin, I would recommend setting the IO_DIS bit to 1 while IO_IF_SEL=0.

I’m not sure I understand the second issue you mentioned in your last post.  Can you provide more of an explanation here?

Thank you,

Mekre

Dear Mekre-san, 

For a few weeks, we have disucussed about this CS response issue, the point is we found this issue every time on my ciruit and uC conditions. 

On the other hand, under enviironment in TI 's EVM board, we could not find this issue. Even if you and I write the our parameters. 

The main reason is the initial condittion of PGA460. As you know, at TI board, when start, to make the right communication, I need to initiatllly write the "right" parameters, for very debugging. 

As I mentioned, after this cs response error is cleared(means to write true parameters), then, after that, even if you over-write the "wrong" parameters, this CS response issue not happen anymore. That made some confusing.

If you use the only the TI board, may be, you never meet this behavior. You need the another debugging environment, like as simulating the actual development case, e.g. Eval board and uC, etc. 

1. After reboot, write this  parameters including IO_IF_SEL=1, then we nay find the this CS response error issue. 

2. But, after above, if you write the right parameters with IO_IF_SEL=0,  this error is cleared. 

3. Then, again, if you write the wrong parameters with IO_IF_SEL=1, YOU NEVER SEE this CS response error issue!

4. But, as I mentioned, if you power off the PGA460 once, then start again(reboot), and write the "wrong" parameters, you may see  CS response error issue. 

I guess, that could be a specific required condition then initalizing (never write IO_IF_SEL=1 at initalization). 

For our developemnt case, we never use this IO-pin, therefore  not sure if maks which kind of side effect...

You recommend not to set this,  but not required. You(TI) may write, for eample, in case no use IO-PIN mode from the  beginning, we must deactivate this functions. Also, I guess even if this setting is not registrated, the CS response error issue amy not happen  at all. 

I need offical  answer and feedback from TI  engineering about this issue. 

Regrads,

Yoshifumi YAMAOKA

Hi  Yamaoka-san,

I have sent you an E2E friend request to discuss this further.

Regards,

Mekre

Dear Mekre-san, 

could you write down the summary of last discussion with you about this topics? 

After confirmation, I would like to close this item. as I said. 

Rgs,

Yamaoka