V Rising Error

[Aide Broeckel]

Iam working with the CLB to implement a communication protocol. I am currently debugging the part where a rising edge is detected in the SIMO channel of SPIA in order to trigger a FSM. The FSM is not triggered as expected because the rising edge detection is not working fine. The SPI signal is passed throughthe local signals to the boundary input.

To debug this, I outputed throught the xbar again two signals. First, the boundary in throught an outlut and then to the xbar. Second, the signals that is comming before the rising edge filter i.e. the SPI signal, to the output xbar.

In yellow is the signal measured at the spi input, in this case the GPIO8. In red, the clock generated when the FSM is triggered. In green the SPI signal seen at the inputxbar and in blue the suposed rising edge detection.

It is clear that the signal is not working fine because there is no rising edge at that point. Which signal am i suposed to see if worked fine? Also, how it is possible to ensure that the signal is prperly passed to the CLB? I read the manual and i could not find more errors in the code. The code is as follows:

As a side note, I also tried to change the Boundary in1 signal that detects the rising edge with different filters, disabling sync and using other paths like using the global signals but in the oscilloscope, there was no change at all so I am guessing that the mux boundary selection is not ok but I can not find where is the error.

If you're using SysConfig (which is highly recommended, especially for configuring the CLB), can you try to generate the simulation file and either run GTKWave or attach that here? You can find instructions on using the simulation tool here. I would recommend setting the boundary input as some square wave to see what the input becomes for the CLB.

For the blue signal, I assume you just routed the boundary input after rising edge detection to an OUTLUT for the output? It also looks like your SPI signal is a bit noisy, which made the rising edge detect go high a little earlier than it probably should have (although it's hard for me to tell how far off it is time-wise in the scope shot).

Thank you for your fast response. Please, see the attached file in this message. The image is the simulation of the CLB tool for a sqaure wave signal in boundary 1. In the simulation I assumed that the rising edge filter would be a kind of square wave signal, for each rising edge found at the input, something like the counter match signal respone (Short square pulse). Red signal is an start signal i use(GPREG), in green, the rising edge detection; in orange, the output of the clock generation(Note that it is inverted), finally, the blue signal is the mode0 of the counter in charge of grenerating the clock signal. As you can see, as soon as boundary in1 is 1, the counter start signal is triggered and there is a delay of half a period of the clock signal.

The scope is configured to 2us division, this means the we are talking of a rising detection 4us eralier than it should have. Also, note that the spi signal is noisy because the probe is not referenced to gnd but the green signal in the scope capture is pretty clean.

PD: PLease note that the period in the gtk wave is half the period of the oscilloscope capture. Do not take into account that difference as i was testing with difference clk frequencies but the behavior has to be exactly the same

I think I don't quite fully understand the issue, I thought the issue was you weren't seeing the rising edge detection occur, but it looks like you're having a problem with the timing not being correct. Can you please elaborate on your statement below?

Please also try to use the latest version of C2000Ware, based on your simulation it looks like you have a previous version. There have been a few fixes and notes added to the CLB Tool since the version you have, which may be of use. For the simulation, the names of the signals will be more descriptive and will be something I can replicate on my side more easily.

Sorry for the late reply, I have been doing intensive testing and I found what the issue was. The CLB was correctly correctly programmed. However, as I am using interrupts, it seems like the interrupt triggered before the CLB was totally configured. Therefore, the rising edge filter was not enabled so it was impossible that it worked. Thank you anyway for your help. I could came accros with this solution thanks to having the conversation with you.

I wanted to thank you for your tutorial (GitHub - mestaki/qiime2-to-BugBase), since I'm trying to use Bugbase for some time.

Firstly I tried this summer following their Documentation, and unsuccessfully.

Today I've tried your tutorial to the letter, it generated all the files quickly and without problems but still when I upload them to the web app of Bugbase I get this message: There was an error while parsing your data. Please ensure your OTU and mapping files follow the format explained in the documentation. OTU tables must be the json version of biom.

I'm at my wits end.

Hi @anamarija,

Glad that little tutorial is finally getting some use

The first thing that sticks out to me is your metadata first column name #SampleID. There is a note in my tutorial regarding this:

Hi, thank for extra fast reply!

I changed it, but it seems there is a problem with biom file, because when I upload it without metadata it still gets the same error. I also tried with your data from the tutorial, but have the same issue.

It appears that the BugBase documentations has changed a bit since last I made that tutorial. In fact the first header now is required to be #SampleID instead, not sample-id as my tutorial says.

The fact that this works for you but only without the metadata file suggests that there is some special character or formatting issue that does not meet their requirements. I would carefully check their requirements again. Take extra care looking for hidden characters/spaces if your metadata file was used something like excel.

Hi @Mehrbod_Estaki,

thank you for sharing your protocol. It worked well for me. I have one more question. The OTU table that BugBase requires has to be picked against greengenes databse (16s). And the OTU table prepared in your way contains OTUID (first column), taxonomy (last columns), and the rest of the columns are feature frequency data fro each sample. Would you think a biom (json) file with only taxonomy column and sample feature frequency data (line the following) work? Thank you!

Screen Shot 2020-09-29 at 10.57.39 AM20161078 319 KB

3.1.3, gives me a java.sql.SQLException: Invalid parameter index 1. error, or a Parameter #1 has not been set error. Any clues? I'm literally just trying to do the most basic rising input possible for a SELECT * query and I had the same issue with another database last week, which all of a sudden started working.

The app interface claims to populate the SQL query template for you on the right-hand side, but it does so incorrectly: it only populates half of it. It populates the rising column in the query template but not the table name. Select the table, select batch type rising, select the rising column, copy and paste the SQL template into the SQL section but modify the table name.

It sounds like a silly problem that you should have caught, but it's not. The app claims to populate the SQL query template for you, but it only populates part of it. Ridiculously unexpected. For anyone having this problem, this is a Splunk QA team problem not a user problem.

Contacting the manufacturer didn't help much: they asked me to install Windows and run the disk check utility from there or connect it as an external drive to a Windows host and test it there.

I did both and no errors were encountered.

I also checked it with the utility they provide (see screenshot below). I then used the image I made with clonezilla to return to Ubuntu, and I found that the SATA PHY error count is nearing 300 errors!

Run fsck -f on your SSD after booting with a Live-USB when the partition is not mounted. Another option is running fsck -f from grub - How to fsck hard drive while hard drive is unmounted, using bootable USB stick?.

As mentioned in comments a bad SATA cable can cause errors. But as this answer points out, a loose connection can also cause errors. To rule out a bad/loose connection, remove the plugs from your SSD, blow compressed air over them and the male pins on the drive and firmly reseat the cables.

As a compromise between the negative answer (return it) and the positive answer (nothing is wrong), my inclination would be to run fsck on every boot. If an error is discovered the boot is paused and you can read the error message. To summarize the link use:

Others mentioned replacing the SATA cable which is problematic for a laptop. As a compromise consider unplugging all cables on the drive side, using compressed air on male and female ends and then plugging the cables back in firmly.

Firstly, the first screenshot contains raw data and you cannot draw any conclusions about it. I have no idea what use its creator thinks that data would be to anybody, but it doesn't really mean anything. Unless the meaningful columns can be reached by scrolling right in the window or something.

The log of "errors" is relatively typical for a drive. These do not necessarily indicate unrecoverable errors or even problems with the drive itself; their reports are vague, so you can't tell what actually happened from this except that it was during DMA transfer at the controller, but if anything was important it would be reflected in the overall health report. In particular, these ones could be something fairly innocent like writes that were cancelled at the controller end, or the OS requesting some feature during load that the drive doesn't support, which may be entirely normal when probing device capabilities.

3a8082e126