LA Trigger not working on latest firmwares

[banban]

Hi,

I'm implementing a Python library to interface OpenScope MZ (I'll publish it open source when ready). In my application, I need the trigger out functionality, which I have been able to achieve by toggling the TRGOUT pin on the Trig2 function (Trigger.c). I also need the trigger in functionality, which does not seem to be implemented. In such case, I thought that using the LA would be enough, but it seems that on latest firmwares the LA trigger is broken. It seems to work on 1.4.0, however, on Github only 1.296.0 firmware is available. So I can't get TRGIN+TRGOUT combination to work...

My questions:

- Is this a known issue?

- Could you upload all firmware versions to GH? It would certainly help to debug the issues by looking at changelog...

Thanks,

[AndrewHolzer]

Hey Banban,

Trigger In functionality hasn't been implemented in the firmware. We reserved those pins for future implementation but as you've noticed we haven't done so yet. I'll speak to Keith about getting the latest/all the firmware version(s) onto GitHub. He's out until next week, so I ask for your patience until we can get you the updated firmware.

Can you please elaborate on how you were using the LA trigger to accomplish your goal? I'll see how I can help you here but I need some more information to do so.

Thank you,
Andrew

[banban]

So LA can be configured as a trigger IN in the end. For example configuring D1 to trigger on rising/falling edge, will emulate trigger IN when an external signal toggles D1.  That's enough for what I'm doing, but, unfortunately LA trigger is broken on recent firmwares (it can't be used at all).

I have been able to configure it and make it work by adding this dirty hack to the firmware:

diff --git a/ParseOpenScope.cpp b/ParseOpenScope.cpp
index 02a1105..96e4579 100644
--- a/ParseOpenScope.cpp
+++ b/ParseOpenScope.cpp
@@ -6339,7 +6339,7 @@ STATE OSPAR::ParseToken(char const * szToken, uint32_t cbToken, JSONTOKEN jsonTo
                         fReady          &= (fConfig || pjcmd.trigger.rgtte[i].pstate->processing == Waiting);
                         fLANeeded       |= (pjcmd.trigger.rgtte[i].instrID == LOGIC1_ID);
                     }
-
+                    fReady=true;
                     if(fReady)
                     {

Regarding trigger out, it would be helpful to know if the trigger condition on the comparators/LA can directly toggle TRGOUT pin (to avoid interrupt latencies I'm seeing now by toggling TRGOUT on Trig2()). This is what I have done to have trigger out:

diff --git a/Initialize.cpp b/Initialize.cpp
index 9c37aa3..68bf12b 100644
--- a/Initialize.cpp
+++ b/Initialize.cpp
@@ -344,6 +344,10 @@ STATE InitInstruments(void)
     // BUTTON 1 as in input
     TRISGbits.TRISG12 = 1;
 
+    // Trigger out
+    TRISAbits.TRISA5 = 0;
+    LATAbits.LATA5 = 0;
+
     //**************************************************************************
     //*****************************  Set Pin Usage  ****************************
     //**************************************************************************
diff --git a/OpenScope.h b/OpenScope.h
index c570b91..02328a8 100644
--- a/OpenScope.h
+++ b/OpenScope.h
@@ -1904,6 +1904,8 @@ extern "C" {
     #define PIN_CS_MRF  LATB,   (1 << 15)   // RB15, pin 56
 #endif
 
+#define PIN_TRGOUT   LATA, (1 << 5)   // Trigger out
+
 // gpio macros
 #define SetGPIO(a,c)  SetGPIO2(a,c)
 // #define SetGPIO2(a,b,c) {if(c==0) a##CLR = b; else a##SET = b;}
diff --git a/Trigger.c b/Trigger.c
index 13bee28..b8afb65 100644
--- a/Trigger.c
+++ b/Trigger.c
@@ -56,6 +56,8 @@ static void Trig2(void)
     int32_t laDMATrig2;
     uint16_t ChangeNotice;
 
+    static uint8_t toggle;
+
     // Most likely order is we will be working on ch1 of the OSC, then ch2, than the LA
     laDMATrig1  = DCH7DPTR;     // hard coded this to the LA DMA pointer
     ch2DMATrig1 = DCH5DPTR;     // hard coded this to the ADC2 DMA pointer
@@ -78,6 +80,14 @@ static void Trig2(void)
     IEC3CLR = _IEC3_CNEIE_MASK;
     IFS3CLR = _IFS3_CNEIF_MASK;
 
+    // toggle trigger out
+    if (toggle) {
+      toggle = 0;
+      SetGPIO(PIN_TRGOUT, 1);
+    } else {
+      toggle = 1;
+      SetGPIO(PIN_TRGOUT, 0);
+    }
     // average out our trigger points
     // this is only to sync the instruments together in timing
     // it is not used for searching   

 

[banban]

Has anybody had time to take a look into this problem?

Thanks

[Fa-b]

Hey banban,

I have not tried to mess with the openscope firmware myself yet and I'm not much experienced with pic32 MCU's, so I don't know if there is a possibility to toggle a GPIO directly through the same hardware modules used for the trigger. But there might be.

So I will just tell you what comes to my mind looking at your software TRIGGER_OUT approach:

1. Keep in mind that you are working on a 32 bit MCU that is able to do 32 bit operations in hardware, use size_t (falls back to uint32_t) rather than uint8_t unless really necessary.

2. Put your piece of code directly to the interrupt service routine for the LA to save some more time:

void __attribute__((nomips16, at_vector(_CHANGE_NOTICE_E_VECTOR),interrupt(IPL6SRS))) TrigISR2LA(void)
{
	//put code here
    Trig2();
}

 

3. The algorithm you're using to toggle an output pin comes down to this C code:

if (toggle) {
	toggle = 0;
	if (1 == 0) {
		LATA &= ~(1 << 5);
	} else {
		LATA |= (1 << 5);
	}
} else {
	toggle = 1;
	if (0 == 0) {
		LATA &= ~(1 << 5);
	} else {
		LATA |= (1 << 5);
	}
}

 

while this would be enough:

LATA ^= (1 << 5);

while '^' is the bitwise XOR operator, no need for a toggle variable.

 

Depending on the C compiler you're using (optimizations), the generated assembly from the C code can be really inefficient. This is another reason why I would not try to modify the firmware myself.

 

What latencies are you seeing anyway?

 

Regards

Fabian

[banban]

Hi Fabian,

 

Thanks for the suggested optimization. What about the other questions?

- LA trigger is not working with latest firmwares

- Could you publish latest firmwares on GH, as well as MPLAB project files?

 

Thanks

[Fa-b]

Hi banban,

 

There is an open issue #6 on github about the MPLAB-X IDE project files (see here). Though, i don't think this will happen since the firmware appears to have been developed using Arduino 1.6.9 IDE. Here is a resource explaining why:

https://blog.digilentinc.com/digilent-core-on-arduino/

The Digilent Core for Arduino IDE comes with a compiler, so I suggest you stick with that.

The latest available firmware is indeed available on github (v1.296.0). I agree it is very confusing but '1.296.0' does not mean '1.2.9.6.0', so Digilent has made a huge step forward from the previous version available on github (1.6.0). I can confirm that LA trigger does not work on that latest firmware and unfortunately I could not find version 1.6.0 using waveforms live. I was however able to flash version 1.9.0 and it appears that LA trigger is not broken there! So chances are high it is working on 1.6.0 as well. I suggest you 'git checkout -b <branch-name> d05afb1' rather than trying to find the responsible piece(s) of code, and see if that works for you.

 

@Digilent: At least, versions that you make available for flashing through Waveforms Live should be available as source code as well. From 1.6.0 to 1.296.0, there has been no information on what has changed in the openscope. Though, the minor-version increase is massive. Why not use the patch-version if those changes contain mainly bugfixes and really minor changes that may be unstable? It appears now, that one of those patches has introduced a major bug and it will be nearly impossible for us to fix that without your help. Migrating back to 1.6.0, nobody knows what features will be lost/broken...

 

Regards

Fabian

[banban]

Hi Fabian,

As you may have seen in the patch above, I already found a hack to make LA trigger work again. It’s a dirty solution but it works... 

Regarding versions, 1.310 is also advertised on WL but not on Github. Unfortunately using the versions you suggest is not an option as the datalogger is not implemented on them.

I hope that the support improves for this product if it is continued to be sold. Also, if it is open source the development should happen on GH. Version tracking is crucial to spot this kind of bugs.

[Fa-b]

Hi banban,

Sorry, I have not seen version 1.310.0 when I checked.

I agree with you, therefore I have just opened an issue on GitHub:

https://github.com/Digilent/openscope-mz/issues/7

Please +1 for it to be considered by Digilent.

 

Regards

Fabian

[AndrewHolzer]

Hi @banban & @Fa-b,

I've pushed the most recent firmware version onto GitHub. I don't have a changelog for the changes from 1.296.0 to 1.301.0, but moving forward each release of the firmware will be posted to the repository along with a changelog for the update. I hope that this will help with bug fixes in the future.

I also spoke to Keith about the LA trigger where he and I both confirmed that it is working on the latest firmware. We tested this using WaveForms Live and connecting LA channel 1 up to a source producing a square wave at a fixed frequency. Can either of you please clarify how you came to find the LA trigger isn't working as expected? As you, banban, are trying to make a Python interface, it is possible that you aren't configuring the trigger properly. WFL issues a trigger.setParameters command when the user clicks Run. This command sets the source instrument you want to trigger on and the rising & falling bitmask for the trigger conditions.

I'll be looking for your updates regarding the LA trigger issue,
Andrew

[Fa-b]

Hi @AndrewHolzer,

Thanks for updating the version on GitHub. I can't tell why, but version 1.301.0 is not shown for me using WFL:

 

Version 1.296.0 is the latest version I can find scrolling the list. Can this be a regional thing?!

Looking at the code differences from your GH update, I assume this won't have an effect on the LA trigger anyways. So I will just do as you requested using v1.296.0:

 

- Starting WFL and connecting to the device (tested both WIFI and UART).

- On the OSC page changing trigger source to LA

- press run without modifying the trigger configuration.. works (All triggers off):

 

- Changing any of the trigger slopes (in this case Ch1 to falling edge) and pressing start again prompts the following toast:

 

 

During writing, I have just realized that I might be missing an additional step for this to work. Since I have not actually needed the LA trigger-in functionality, I have never thought about actually configuring the GPIO's through the 'Digital' tab.

Doing that once after the OpenScope has powered up solves the whole issue. So it appears the GPIO's are initialised to an incompatible state for the LA. Maybe this is the same issue @banban faces using his python library.

Let's wait and see what he will say.

 

Thanks again, regards

Fabian

[AndrewHolzer]

@Fa-b,

It is possible that your browser could be caching the results of the firmware version list operation. You might try a force refresh on the page to see if that fixes the issue. If that doesn't work, I'd like you to try a different browser to see if you can see version 1.301.0 there. If you can, then please go back to your regular browser, and visit the WaveForms Live settings page. Expand the Advanced portion and click the Change Console Log button, and choose Console to enable logging to the browser's console. Open the console (usually with Ctrl + Shift + i), and then visit the Update Firmware page. Capture the console output, and send it to me through a PM.

You could also try clearing the browser cookies and cache, however this would mean WaveForms Live would forget your devices, so I only advise you do this if you are okay with this happening.

Regards,
Andrew

[Fa-b]

Hi @AndrewHolzer,

You were right. I went to the Developer Tools' Application Settings and cleared the site data one after the other. But luckily it was neither cache nor cookies, but the IndexedDB storage that caused this issue.

I looked a bit deeper:

The reason for this issue appears to be the advanced settings. After clearing IndexedDB I get this list of firmware versions from 'update-firmware.ts':

["0.176.0", "0.185.0", "0.283.0", "0.339.0", "0.352.0", "0.354.0", "0.355.0", "0.358.0", "0.369.0", "0.371.0", "0.374.0", "0.387.0", "0.392.0", "0.414.0", "0.423.0", "0.428.0", "0.533.0", "1.2.0", "1.4.0", "1.37.0", "1.286.0", "1.294.0", "1.295.0", "1.296.0", "1.301.0"]

 

When I go to the Advanced Settings in WFL and opt-in to 'Use Dev Firmware Builds', I will afterwards receive this list of firmware versions:

["0.176.0", "0.185.0", "0.218.0", "0.243.0", "0.283.0", "0.319.0", "0.320.0", "0.321.0", "0.326.0", "0.334.0", "0.336.0", "0.339.0", "0.352.0", "0.354.0", "0.355.0", "0.356.0", "0.358.0", "0.369.0", "0.379.0", "0.381.0", "0.385.0", "0.386.0", "0.387.0", "0.391.0", "0.392.0", "0.397.0", "0.399.0", "0.414.0", "0.415.0", "0.416.0", "0.417.0", "0.418.0", "0.423.0", "0.428.0", "0.516.0", "0.529.0", "0.533.0", "1.1.0", "1.2.0", "1.4.0", "1.5.0", "1.9.0", "1.19.0", "1.24.0", "1.27.0", "1.30.0", "1.32.0", "1.35.0", "1.37.0", "1.56.0", "1.61.0", "1.71.0", "1.84.0", "1.94.0", "1.95.0", "1.102.0", "1.105.0", "1.107.0", "1.110.0", "1.115.0", "1.120.0", "1.123.0", "1.190.0", "1.194.0", "1.200.0", "1.202.0", "1.208.0", "1.214.0", "1.217.0", "1.219.0", "1.223.0", "1.226.0", "1.229.0", "1.231.0", "1.233.0", "1.238.0", "1.239.0", "1.243.0", "1.245.0", "1.246.0", "1.251.0", "1.253.0", "1.254.0", "1.259.0", "1.260.0", "1.262.0", "1.269.0", "1.276.0", "1.279.0", "1.285.0", "1.286.0", "1.288.0", "1.291.0", "1.294.0", "1.295.0", "1.296.0"]

Note that now the latest firmware version '1.301.0' is not listed anymore.

So this switch was actually what was causing me not to see the latest firmware. I'm guessing the Dev-Builds list is simply not up-to-date yet.

 

Thanks and regards

Fabian