sorry I didn't make it clearer. This is not about a builderror. Both designs are compiled successfully and there is no error from the static timing analysis. But the design, where the P1_7 is not connected, always returns bytes not received at the UART.
Depending on what you change in the topsheet (&that causes IMHO a different placement in the PLD/UDBs) the receiving of the UART sometimes will fail. Exactly I could not comprehend, how this is related exactly. I saved these two configurations as reproducible examples.
It is very difficult to find that bug when not all information is present. Please reduce your project to a minimal version that still shows the error and upload that to the community. Use "Create Workspace Bundle" to generate the .zip file.
Are you using a Cypress kit or a self made PCB? Is there a chance to test your project using a CY8CKIT-059?
I understand Hari's concern. I work with RF transmit and receive products. Normally having a "floating" wire stub is not recommended. It's the equivalent of a dipole antenna.
As Hari suggested, remove the stub and try your test again. If the problem goes away, great. If not, there is another problem at hand.
Remember, SW is also at play with your isr_Rx. It is possible that you might not be processing your interrupts fast enough. Are you checking for the FIFO being empty before you exit your isr_RX()? If not and you are assuming you are only getting one byte per isr_Rx (normally a reasonable assumption), you could be slowly accumulating bytes in your FIFO and eventually you will get a FIFO overrun.
Check your SW to see if you disable interrupts for an significant amounts of time. Also check to see if any other interrupts might be hogging the CPU.
I learned MANY years ago that it is wise to only spend the minimal time in an interrupt that is physically possible. This allows all interrupts to be processed in a timely fashion. The best practice is to get the interrupt, read (or write) the data and/or registers that caused the interrupt and place the newly acquired information in a place in RAM, then exit the ISR. The CPU during non-interrupt processing can perform more CPU-intensive operations on the incoming data will less time-criticality.
I understand your concerns about the lack of information.
But please also understand my dilemma. The problem only occurs in the more or less product (UART communicates via Modbus with Coriolis sensor) and only when I change something in the topsheet.
So if I put the complete project here (which I don't really want to do), it doesn't help much. If I compare the two projects only the report file shows a different partioning of the logic.
(@Len: if I only remove the stub nothing changes in the synthesized logic. This is only a graphical issue in the top sheet editor)
I then narrowed it down so that I suspect the error directly in the UART. The above two configurations are only examples. (&now also checked in to GIT so it's always accessible for me)
I had also a configuration with HSO_0 & P1_7 connected to RX & RX-ISR, and the byte lost happens. (but something else was changed in the topsheet, which caused the error in the UART)
There you could see directly at the oscilloscope, although the signal at the HSO_0 pin (the input of the UART component) is a perfect signal, the UART did not signal the reception of the byte via RX_ISR (P1_7 remained low).
The ISR configuration of the UART is only set at the start of the program & then never changed again.
So for me this really looks like a problem in the UART component.
BLUE: RX on pin HSO_0
RED: RX-ISR on Pin P1_7
=> signal driven all from synth. HW, so no SW involved at all. For me it looks like sometimes the UART is missing the falling edge of the start byte...
More or less guessing:
Self-made PCB? Cypress Kit?? Not yet answered
Frequency of HFCLK? Try to increase to max. This is used for edge detecting in USB.
self made pcb. But please not I use extra pin to log RX data. So if there should be a glitch on this line which disturbs the UART, this should also be seen on this pin. (in my case HSO_0).
I use CY8C5868AXI-LP035 device, there I didn't find a HFCLK setting in clk tab.
But I now looked inside the UART componet and as far as I understood they do the edge detect with the UART clk frequency.
Excerpt from B_UART_v_2_50:
Try changing bus clock and master clock to 48MHz. (HFCLK was the name for PSoC4, sorry)
According to timming report I'm limited to 30MHz.
I have tried with 30MHz. But I also have to adapt some timers which are running on bus clk. Therefore also the logic placemant in the PLD/UDBs changed (.rpt file shows changed layout, not only time and variable names)
On the other hand, the UART component is only clocked by the clock provided. Therefore a other busclk should not change anything (if the HW synthesis itself does not change, or the the resulting slight change in the UART clk frequency).
If you get a max. frequency of 37.2Mhz from the stat. timing anaylse and the component is clocked with 307.6kHz, a different partitioning in the logic cells should have no influence. (at least what I know from other programmable logic devices).
So for me look there must be a logic/race condition issue inside this component.
From a colleague from another department, I heard that he gets problems with the PSOC-USRT at temperature <-15°C.
This encourages me to assume that there is a problem in the component.
On the other hand, I'm surprised I'm the first one to notice that.
Except everyone assumes that something can always go wrong on the UART and don't look closer.
If I hadn't originally addressed the UART via DMA and looked there for the error, I might have left it with this explanation.
I have no idea how I could make a test case reproducible on a demoboard out of it. IMHO it really depends how the logic is synthetized into UDB/PLD...
Please confirm that there are no higher priority interrupts running that might cause the UART interrupt to fail.
And just to clarify the issue again, a byte is lost only when P1_7 is disconnected from Rx_ISR line? When P1_7 is connected, does everything work fine?
yes the UART interrupt has the highest priority. But this is not the issue because the UART didn't set his rx_interrupt line. (look at attached oscilloscope picture above)
To make it clear, I have now to saved projects which only differ that P1_7 is connected or not to RX_ISR line, that show this behaviour.
But you could mange with connected P1_7 to ISR line and change something else in topsheet (total independed component of UART), that this configuration will fail. Only the logic partition (of the UART?) inside the PLDs/UDBs has to change. So it also has nothing directly to do with connection to rx_isr line.
Unfortunatly I didn't save this configuration with connected P1_7 to rx_isr line. But I take the oscilloscope pictures above...
its me again. I solved the problem!
In my desperation I wanted to build myself a own UART-RX component. There I discovered what the problem of the UART is. Inside the UART component the CLK is synchronized (at least that's the comment of the used clk buffer in the UART VHDL code says so), but not the data input RX. Since the UART CLK is mostly derived from the bus clk, I don't quite understand why clk but not rx is synchroized (which normal came from outside).
With the rx signal it can go wrong if the falling edge of the rx coincides with the rising edge of the clock. Depending on how the logic is synthesizes, the internal delays could go wrong or not. (at least that's my explanation why it was dependent of the internal layout of the logic).
So sometime the falling edge is not detected, if it happens the same time the internal clk has rising edge.
If you now set a sync module or glitch filter before the rx input, the signal is synchronized and the problem no longer occurs. That's why I think many people who might have had the same problem don't see it. Because they think there was a spike/noise on the line and introduce a glitch filter on rx line. Which also results in a synchronisation of the signal to the internal clk domain.
I had a glitch filter inside right at the beginning, but apparently there was another error with the DMA that led to erroneous bytes. Since I didn't see any glitches on the oscilloscope, I removed the filter again.... (Also because in all UART examples known to me, the rx pin is directly connected)
Maybe it'll help somebody,
Congratulations! You've discovered metastability in electronics for yourself. See: Metastability (electronics) - Wikipedia
This condition is why most external inputs on the PSoC are synchronized to the BUS_CLK (Sync Mode:) to minimize this potential effect. If your UART clock is not synchronized to BUS_CLK or you selected "Sync Mode: Transparent", then that circuit can be susceptible to not meeting the data (Rx) setup or hold time requirements producing a possible metastable logic condition in one of the UART latches.
I don't know how long it took you to detect and fix this issue. For me, it took two weeks to capture the event then formulate the HW correction. From then on, I'm always aware of this condition when I design my logic. Thankfully, Cypress tried to create structures in the PSoC (including the SYNC component) to remove this issue from user designs.
Consider yourself blessed. You've learned a valuable lesson that will live 'in' you for the rest of your life as a circuit designer. I'm confident that there are untold number of logic designs launched out in the market that are prone to metastability but the designer never saw the issue show up in bench testing. If the designer did witness glitches in the data as you did but chalked it up to "uncorrectable transients".
Again, kudos to you for not being satisfied with an unexplained anomaly and for putting your circuit through what I call "saturation testing". With saturation testing, you stimulate the circuit continuously and at top speed while looking for extra or missing events. Many designers don't bother going that extra step leaving the customer to find issues in the field.
thanks for your comment I found now the real real issue what is going wrong on my side. (I was just wondering why not more people have a problem with that issue)
If I insert a input pin into the top sheet the sync mode of this pin is set to transparent by default! And not to double-sync as it is written in the documentation.
I'm using PSoC Creator 4.1 Update 1 (126.96.36.19910). I'm not sure if there is another setting in PSoC Creator which I have done wrong, that I get this default setting. If there is not another misconfiguration of my site, I would consider it a "dangerous" bug in the PSoC Creator.
As you said normaly the signal should be syncronized at the input pin.
If I connected the input pin directly to the UART (like in the code example) it was not synchronized and that causes the issue of lost byte.