- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
I am designing a firmware using PSOC creator for PSOC5LP and I would like to use SR-FF components in my design.
In my design some of SR-FF will have '0' logic on both S and R input pins after power on.
In that case what would be the output?
Many thanks.
Solved! Go to Solution.
- Labels:
-
PSoC 5LP
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
My sincere apologies for the confusion caused. We discussed with component experts and found that SR FF is implemented using D FF. Since the D FF is initialized to zero at power up and device reset, the initial state of SR FF after reset and power up will also be zero.
You can also have a look at the PSoC 3, PSoC 4, and PSoC 5LP Digital Design Best Practices Appnote: https://www.cypress.com/file/179061/download
Best Regards
Ekta
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
When both S and R are 0, SR FF will keep the "previous" Q value.
Then what is the previous Q for the device just exited from reset?
In the TRM UDB chapter, Figure 21-3. Macrocell Architecture
the DFF shown there must be the one to hold the value.
But without knowing the default/initial value of RSEL I could not tell if it gets reset.
Then I tried to find registers for UDB in the Register TRM
1.3.667 B[0..3]_UDB00_A0 ~ 1.3.1103 B[0..3]_UDB15_MC_00
seem to be holding UDB related values.
Except the ones with "F" in the name, whose Reset value are R/W:UUUUUUUU,
all other values are reset to R/W:00000000, so odds are high that the Q is reset to 0.
But with my poor knowledge I could not affirm which register is the one to hold the value.
Then I created a simple project with the schematic
and main.c
======================
#include "project.h"
#include "stdio.h"
char str[128] ; /* print buffer */
void print(char *str)
{
UART_PutString(str) ;
}
void splash(void)
{
sprintf(str, "SR FF Test (%s %s)\n", __DATE__, __TIME__) ;
print(str) ;
}
void init_hardware(void)
{
Control_Reg_Write(0) ;
UART_Start() ;
CyGlobalIntEnable; /* Enable global interrupts. */
}
int main(void)
{
uint8_t value = 0 ;
uint8_t control = 0 ;
init_hardware() ;
splash() ;
value = Status_Reg_Read() ;
sprintf(str, "Initial Value of SR FF = %d\n", value) ;
print(str) ;
for(;;)
{
Control_Reg_Write(control) ;
CyDelayUs(1) ;
value = Status_Reg_Read() ;
sprintf(str, "R = %d, S = %d, Value = %d\n",
(control >> 1) & 0x01,
control & 0x01,
value) ;
print(str) ;
control = (control + 1) % 4 ;
CyDelay(1000) ;
}
}
======================
The result Tera Term log was
As far as I tested, the initial value of SR FF was always 0.
So for a casual project we may assume that the initial value of SR FF is 0,
but for a critical project such as a life threatening one,
I would add a program or circuit to clear the value at the beginning of the project.
moto
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks a lot Ekta and Moto for your answers.
This issue is crucial in my design and I can not have random initial outputs.
Ekta, your answer is an official cypress answer?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
> This issue is crucial in my design and I can not have random initial outputs.
If that is the case, I would modify my schematic like
And set the initial value of CLR_REG to 1.
And add control to CLR_REG_Write in my init_hardware() function
==================
void init_hardware(void)
{
CLR_REG_Write(1) ; /* reset connected register */
Control_Reg_Write(0) ;
CLR_REG_Write(0) ; /* release reset to the register */
UART_Start() ;
CyGlobalIntEnable; /* Enable global interrupts. */
}
==================
Now I don't have to rely on my luck or device specific implementation of the initialization.
moto
P.S.
> Ekta, your answer is an official cypress answer?
If it is the case, I wish it was stated somewhere I could find...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks Moto,
This will certainly work. But as I your test shows, it is all most sure that the initial output of SR-FF is '0' by design and not random.
So, I still want to know the official cypress answer.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Nimrod,
For S-R flip-flops in general the output Q is undefined when the inputs are both zero.
The best way to handle this is to activate set/reset inputs at initialization, so the best thing might be to use a D flip-flop Component instead of an S-R flip-flop Component. The DFF has both synchronous and asynchronous set and reset inputs.
Best Regards
Ekta
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Ekta,
Thanks but your current answer contradict your first answer.
I would like to know what is the official cypress stand on this issue because it is fundamental and it affects not just my design but others as well.
If you are not a cypress representative please do not reply.
Although resetting the SR FF manually will work, it is not elegant and in a design with many SR FF it will consume resources. If SR-FF output is truly random at start than using SR FF without the suggested workaround can throw the design to any possible state which make the SR FF unusable.
I don't think that is the case and I will explain why:
As mentioned on SR FF datasheet. The SR FF uses one macrocell:
The macrocell basic building block for creating flip flops is the D FF:
The D-FF initial state is actually mentioned in the datasheet and it is '0':
The question is how cypress implemented the SR FF. If it is implemented as simple as this:
Than the output at startup will be always '0' (as seen in Moto experiment).
Anyway cypress has implemented the SR FF, the initial resetting of D FF will most likely reset the SR FF output as well.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
My sincere apologies for the confusion caused. We discussed with component experts and found that SR FF is implemented using D FF. Since the D FF is initialized to zero at power up and device reset, the initial state of SR FF after reset and power up will also be zero.
You can also have a look at the PSoC 3, PSoC 4, and PSoC 5LP Digital Design Best Practices Appnote: https://www.cypress.com/file/179061/download
Best Regards
Ekta