Hello,
I believe I posted this before, but your documentation is inconsistent and I believe it is wrong.
DS_FT800 states:
"Wake up from POWERDOWN state requires the host to pull the PD_N pin down and
release, a low to high transition enables the 1.2V regulator. POR generated when 1.2V
is stable and FT800 will switch to STANDBY mode after internal oscillator and PLL are up
(maximum 20ms from PD_N rising edge). The clock enable sequence mentioned in
section 4.2.3 shall be executed to proper enable the system clock."
That is a clear and concise statement that the 20ms delay after raising PD_N is required and why.
In the FT81x datasheet this was changed to:
"When in the POWER DOWN state, if the device enters this state via an SPI command, then only the SPI
ACTIVE command will bring the device back to the ACTIVE state, provided PD_N pin is also high.
However, if PD_N is used instead, then making PD_N high followed by a SPI ACTIVE command will wake
up the device."
and
"From the SLEEP state, the host MPU sends an SPI ACTIVE command to wake the FT81x into the ACTIVE
state. The host needs to wait for at least 20ms before accessing any registers or commands. This is to
guarantee the clock oscillator and PLL are up and stable."
This contradicts the FT800 datasheet.
This is also found now in the BT88x, BT817/8, BT815/6 - and I believe it is wrong.
It also contradicts this statement in the BT8178 datasheet:
"After reset the BT817/8 will be in the SLEEP state. Upon receiving the SPI ACTIVE command (or
CLKEXT followed by SPI ACTIVE command if external clock source is used), the clock oscillator and
PLL will start up. Once the clock is stable, the chip will check and repair its internal RAM, running the
configuration and then entering into normal operations. The boot-up may take up to 300ms to
complete. During boot up process, software should not access BT817/8 register or RAM except reading
REG_ID and REG_CPURESET."
So one paragraph states that the host must not read any register directly after ACTIVE,
the other states reading REG_ID is fine.
The BT817/8 programming guide has this:
host_command(ACTIVE);//send host command "ACTIVE" to wake up
delay(300ms);
while (0x7C != rd8(REG_ID));
This is at least consistent with the description as it has a delay() between ACTIVE and reading REG_ID.
Now checking what Bridgetek is using in their own code I found this:
// Reset the display
MCU_Delay_20ms();
HAL_PowerDown(1);
MCU_Delay_20ms();
HAL_PowerDown(0);
MCU_Delay_20ms();
...
// Set active
HAL_HostCmdWrite(0, 0x00);
// Read REG_ID register (0x302000) until reads 0x7C
uint8_t val;
while ((val = HAL_MemRead8(EVE_REG_ID)) != 0x7C)
{
MCU_Delay_20ms();
(void)val;
}
So what is does is adding a delay after setting PD_N to high and it has no delay whatsoever between ACTIVE and the first reading of REG_ID.
To my experience and in accordance with the FT800 datasheet, this is correct.
The delay after setting PD_N is for the EVE chip to go from POWERDOWN to STANDBY.
And reading REG_ID directly after ACTIVE is not a problem, the EVE chip does not answer though untill the internal startup is done which I just measured for a BT817 to happen 43ms after ACTIVE.
The next thing is, why are you using:
host_command(CLKEXT);
host_command(CLKSEL);
host_command(RST_PULSE);
host_command(ACTIVE);
And not:
host_command(RST_PULSE);
host_command(CLKEXT);
host_command(CLKSEL);
host_command(ACTIVE);
From the BT817/8 datasheet:
RST_PULSE
So what this meant to say is "host commands"?
Ok, if that is the case, the order should not matter as long as RST_PULSE comes before ACTIVE.
I believe I posted this before, but your documentation is inconsistent and I believe it is wrong.
DS_FT800 states:
"Wake up from POWERDOWN state requires the host to pull the PD_N pin down and
release, a low to high transition enables the 1.2V regulator. POR generated when 1.2V
is stable and FT800 will switch to STANDBY mode after internal oscillator and PLL are up
(maximum 20ms from PD_N rising edge). The clock enable sequence mentioned in
section 4.2.3 shall be executed to proper enable the system clock."
That is a clear and concise statement that the 20ms delay after raising PD_N is required and why.
In the FT81x datasheet this was changed to:
"When in the POWER DOWN state, if the device enters this state via an SPI command, then only the SPI
ACTIVE command will bring the device back to the ACTIVE state, provided PD_N pin is also high.
However, if PD_N is used instead, then making PD_N high followed by a SPI ACTIVE command will wake
up the device."
and
"From the SLEEP state, the host MPU sends an SPI ACTIVE command to wake the FT81x into the ACTIVE
state. The host needs to wait for at least 20ms before accessing any registers or commands. This is to
guarantee the clock oscillator and PLL are up and stable."
This contradicts the FT800 datasheet.
This is also found now in the BT88x, BT817/8, BT815/6 - and I believe it is wrong.
It also contradicts this statement in the BT8178 datasheet:
"After reset the BT817/8 will be in the SLEEP state. Upon receiving the SPI ACTIVE command (or
CLKEXT followed by SPI ACTIVE command if external clock source is used), the clock oscillator and
PLL will start up. Once the clock is stable, the chip will check and repair its internal RAM, running the
configuration and then entering into normal operations. The boot-up may take up to 300ms to
complete. During boot up process, software should not access BT817/8 register or RAM except reading
REG_ID and REG_CPURESET."
So one paragraph states that the host must not read any register directly after ACTIVE,
the other states reading REG_ID is fine.
The BT817/8 programming guide has this:
host_command(ACTIVE);//send host command "ACTIVE" to wake up
delay(300ms);
while (0x7C != rd8(REG_ID));
This is at least consistent with the description as it has a delay() between ACTIVE and reading REG_ID.
Now checking what Bridgetek is using in their own code I found this:
// Reset the display
MCU_Delay_20ms();
HAL_PowerDown(1);
MCU_Delay_20ms();
HAL_PowerDown(0);
MCU_Delay_20ms();
...
// Set active
HAL_HostCmdWrite(0, 0x00);
// Read REG_ID register (0x302000) until reads 0x7C
uint8_t val;
while ((val = HAL_MemRead8(EVE_REG_ID)) != 0x7C)
{
MCU_Delay_20ms();
(void)val;
}
So what is does is adding a delay after setting PD_N to high and it has no delay whatsoever between ACTIVE and the first reading of REG_ID.
To my experience and in accordance with the FT800 datasheet, this is correct.
The delay after setting PD_N is for the EVE chip to go from POWERDOWN to STANDBY.
And reading REG_ID directly after ACTIVE is not a problem, the EVE chip does not answer though untill the internal startup is done which I just measured for a BT817 to happen 43ms after ACTIVE.
The next thing is, why are you using:
host_command(CLKEXT);
host_command(CLKSEL);
host_command(RST_PULSE);
host_command(ACTIVE);
And not:
host_command(RST_PULSE);
host_command(CLKEXT);
host_command(CLKSEL);
host_command(ACTIVE);
From the BT817/8 datasheet:
RST_PULSE
| Send reset pulse to BT817/8 core. The behaviour is the same as POR except those settings done through SPI commands will not be affected |
So what this meant to say is "host commands"?
Ok, if that is the case, the order should not matter as long as RST_PULSE comes before ACTIVE.
