BRT Community

Please login or register.

Login with username, password and session length
Advanced search  

News:

Welcome to the Bridgetek Community!

Please read our Welcome Note

Technical Support enquires
please contact the team
@ Bridgetek Support

Please refer to our website for detailed information on all our products - Bridgetek - Bridging Technology

Author Topic: RST_PULSE after ACTIVE  (Read 163 times)

Rudolph

  • Sr. Member
  • ****
  • Posts: 296
    • View Profile
RST_PULSE after ACTIVE
« on: May 13, 2022, 09:39:12 PM »

Continuing from here http://www.brtcommunity.com/index.php?topic=388.0 since this is kind of off-topic there.

So, there is the recommendation that appeared in the version 2.2 of the BT81x programming guide to issue a host command "RST_PULSE" right after "ACTIVE".

I was concerned that this would further delay the startup by at least 20ms.

I just tried this with a RVT101HVBNWC00-B since the board that is connected to my RVT70HSBNWC00-B does not have pins attached to connect a logic-analyzer.

The good news is, adding a "RST_PULSE" after "ACTIVE" makes no difference at all.
The bad news is, well, it makes no difference at all.

The trace shows there is an inital group of host commands.
0x44 0x00 0x00 CLKEXT
0x61 0x46 0x00 CLKSEL to configure 72MHz
0x00 0x00 0x00 ACTIVE

0x68 0x00 0x00 RST_PULSE

Then there is 41ms delay from my software before the next activity on the SPI starts.
0x30 0x20 0x00 0x00 0x00 - reading the chip ID

On the first two reads there is no answer from the BT817.
On the third read there is a reaction on the MISO line:
0x00 0x4A 0x43 0x42 0x7C - chip ID sucessfully read

This sequence is exactly the same with or without RST_PULSE.

Next reading REG_CPURESET and the return-value is 0x02 - the touch-controller still is in reset.
On the next read 1ms later the return-value is 0x00.
Again, same with or without RST_PULSE.


The BT817 is doing just fine.
I can not even make it not start right now, no RST_PULSE, no toggle of the PD line, cold-start, warm-start, it always starts.
Three host commands, 41ms pause, 0x7c response on the third read.


I changed my delay to 42ms -> 0x7c response on the first read.

Now this is interesting, when I extend the delay, REG_CPURESET does not return 0x00 earlier.
44ms, 54ms, 154ms - the first reading of REG_CPURESET, after REG_ID returned 0x7c, always returns 0x02.
The second reading with 1ms delay in between returns 0x00.
Removing the 1ms delay between REG_CPURESET reads shows that 0x00 is returned on the tenth read with my SPI settings.
So there actually is a connection between reading REG_ID, EVE needs about 50µs after REG_ID returned 0x7c before REG_CPURESET returns 0x00.
There is the potential to shave off 900µs from the startup-time. :-)


More seriously, I am not sure what to take away from this experiment.
From what I have seen so far the requirement of having a RST_PULSE right after ACTIVE makes no sense since it
does not seem to change the startup in any way.
Same as adding a plain 300ms delay makes no sense when the BT81x are up and running much earlier.
Logged