#28

I am sorry but i really don’t agree with this.
First of the distinction you mention is not embedded in eurorack in any way (actually the only place i’ve seen it is i believe in Buchla systems where control and audio signals are separated). In eurorack you use the output of oscillators, self resonating filters, etc to trigger envelopes, to trigger sample and holds, switches, clock dividers, everything really. It’s part of the magic really.

Second of all teletype has 8 trigger inputs! which means it is meant to interact with the system and not only that, it obviously has comparators too so that it can be triggered by smoother curves like sine waves for example.

Of course one could use a dedicated module for clock but imo this is a unnecessary overlap when teletype is perfectly suited to perform more most of its duties and then some more. The only thing it needs is some protection.

So i truly believe it is a big problem for a module to leave you hanging in a performance ( i really couldn’t care less about “loosing” a few lines of code, no way i am going to forget them).
And i am not saying it should follow, i understand the hardware/software restrictions but definitely not hang.

#29

Hi @Greg, I agree that the system should not lock up ever. It’s never going to work at audio rate, but it should never completely lock up. Especially if all you need do is accidental run your LFO too fast.

I’ve yanked a Dr Octature out of my main case to bring over to my development mini case and have been able to recreate some of the effects you’ve been seeing.

I’m wondering if you’d consider trying a few things out to help me make sure what you’re seeing is what I’m seeing?

Could you try the script here on 2.0b8 again. When the Teletype locks up, can you disconnect all the cables and check to see if that makes the keyboard and screen responsive again. If not, can you then unplug and reconnect the keyboard, and see if that helps. For now, don’t worry about the TR/CV outputs misbehaving.

#30

I just tried this with the same effect - trigger ans CV outs are still working as the scripts suggest but no keyboard control.

Removing the cables has no effect, reconnecting the cable neither. Pressing the front panel button freezes tt then totally.

#31

Yes I also seen a variety of outcomes. Sometimes disconnecting the cables fixes things, sometimes disconnecting the keyboard fixes things, sometimes it’s just borked.

But I’ve got the serial port connected, and I’ve seen a few interesting things. Will investigate…

#32

I did a more elaborate trial and could not replicate this behaviour. I measured the trigger output A (with Logic’s param EQ Analyzer spectogram :wink:) and it worked up to frequency beneath 2k. I cranked it up to ultrasonic then and lost the keyboard but got it again when I went down into the normal audio range.

The script more or less worked over the whole audio range. The screen got very glitchy and I got audio pops when I typed the keyboard to see if it still there but there was an almost steady tone.

Also it did not really work with a sine wave as mentioned above, sounded crappy and did not give constant trigger LED flashing. But pulse was great untill deep into the audio range. I’ll try some wavetables now…:slight_smile:

#33

@Leverkusen and @Greg

Could you try running this firmware for me please? It’s basically 2.0b8 with a slight tweak to the event code. Please give it all the grief you can.

(deleted)

(and @Leverkusen thanks once again for all the testing and feedback you give :heart:)

edit, please try this version instead: teletype.zip (179.3 KB)

They’re basically the same, but this is closer to the actual change I would make.

Testing notes: instead of unplugging cables, try slowing your trigger input down

1 Like
Teletype 2.0 beta (release candidate 2 released 13th July 2017)
Teletype 2.0 beta (release candidate 2 released 13th July 2017)
#34

This is as much grief as I can give right now (actually it hurts a bit to to watch this):

1:
X MOD ADD X Y 60
CV 1 N X

2:
Y P.NEXT

Plus an eight step pattern and a 1000Hz pulse wave going into trigger input 1:
CV 1 goes to a LPG then…no oscillator used apart from teletype…:smiling_imp:

When I crank the oscillator up I loose keyboard control, the screen gets messy or tt freezes - everything is back when the oscillator is turned down again.

:grinning:

3 Likes
#35

My teletype is freezing up with the latest beta as well.

I have a simple ‘tuning’ patch.

M:
L 1 4: TR.PULSE I
I:
M 200
L 1 4: CV I N 12

keyboard and screen still work, but the all the jacks freeze up after about 30 minutes…

#36

Brill, this is also what I’ve seen with the tweaked firmware.

You could always try the zip file posted above. In theory the bug that’s been causing the audio rate issues is probably affecting a lot of other things too. I’m trying to think it through a bit more, but basically every time ‘something’ happens there is a tiny chance that part of the Teletype get’s corrupted. When running the triggers at audio rate that will manifest itself much much sooner. But it may also explain why there are issues with longer running scripts too.

I need to start winding down for bed time now. Tomorrow I’ll completely hijack this thread and call together a conclave of the coders to discuss the tiny change I need to make to libavr32. If anyone else would like to try the firmware in this post and report back that would be incredibly helpful.

5 Likes
#37

CONCLAVE OF CODERS.

That sounds really geeky, but also really mysterious and cool.

2 Likes
#38

Conclave Assemble!

@tehn @zebra @scanner_darkly @ngwese @bpcmusic

A bit of background. If you run audio rate triggers above a certain frequency into the Teletype, it becomes unresponsive and may crash. If it doesn’t crash and you back off the rate, one of the following will happen:

  • everything goes back to normal
  • back to normal, but the keyboard needs an unplug and reconnect to start working again
  • back to normal, but the CV and triggers get stuck

The last 2 issues are ones that seem to crop up repeatedly and even on other modules (e.g. needing to replug the grid on Ansible).

If I change all the IRQ masking in event.c to mask SYS_IRQ_PRIORITY rather than APP_TC_IRQ_PRIORITY, suddenly all the audio rate crashes go away. The system is still unresponsive with audio rate triggers, but as soon as they slow down everything is fine again. No stuck CV or triggers, no issues with the keyboard.

My strong suspicion is that there is some code somewhere that is calling into the event code at SYS_IRQ_PRIORITY, thus bypassing the current mask (I’ve tried looking…). But that the likelihood of it happening simultaneously with another call is very low. This is why the issue manifests itself reliably with audio rate triggers (high event density), and also why we see it when modules have been powered up for a long time.

I propose that we increase the IRQ masking to SYS_IRQ_PRIORITY, while it would be nice to get to the bottom of it, I haven’t the time (or the JTAG) to do it. And even if we did find the offending piece of code, there is an argument to be made that the event handling code is of such critical importance to the well being of the system that it should be masked at the highest level anyway.

However this change is in libavr32 and so will affect all the modules (possibly fixing some bugs in them too!). So before I make the change, I wouldn’t mind some of your collective time to think if there is anything I’ve missed or if I’m being daft in some way.

The diff is as follows:

diff --git a/src/events.c b/src/events.c
index 34bff5a..b5df442 100644
--- a/src/events.c
+++ b/src/events.c
@@ -52,7 +52,7 @@
 // Returns non-zero if an event was available
 u8 event_next( event_t *e ) {
   u8 status;
-  cpu_irq_disable_level(APP_TC_IRQ_PRIORITY);
+  cpu_irq_disable_level(SYS_IRQ_PRIORITY);

   // if pointers are equal, the queue is empty... don't allow idx's to wrap!
   if ( getIdx != putIdx ) {
@@ -66,7 +66,7 @@ u8 event_next( event_t *e ) {
     status = false;
   }

-  cpu_irq_enable_level(APP_TC_IRQ_PRIORITY);
+  cpu_irq_enable_level(SYS_IRQ_PRIORITY);
   return status;
 }

@@ -79,7 +79,7 @@ u8 event_post( event_t *e ) {
    // print_dbg("\r\n posting event, type: ");
    // print_dbg_ulong(e->type);

-  cpu_irq_disable_level(APP_TC_IRQ_PRIORITY);
+  cpu_irq_disable_level(SYS_IRQ_PRIORITY);

   // increment write idx, posbily wrapping
   saveIndex = putIdx;
@@ -93,7 +93,7 @@ u8 event_post( event_t *e ) {
     putIdx = saveIndex;
   }

-  cpu_irq_enable_level(APP_TC_IRQ_PRIORITY);
+  cpu_irq_enable_level(SYS_IRQ_PRIORITY);

   if (!status)
     print_dbg("\r\n event queue full!");

Well the minutiae of interrupts are indeed mysterious, but oh-so very not cool.

3 Likes
#39

how strange…

as far as i can tell, SYS_IRQ_PRIORITY is only used for the PDCA transfer interrupt on aleph. it’s important that this be uninterrupted by event processing. but we can work around that in a different way if/when we really get around to merging the codebases (sorry.)

My strong suspicion is that there is some code somewhere that is calling into the event code at SYS_IRQ_PRIORITY

that would make sense. but i have also failed to spot anything in teletype or libavr32 code (including asf.) neither a usage of SYS_IRQ_PRIORITY, nor anything ridiculous like INTC_register_interrupt(foo, foo, 1). there are some drivers that set their own interrupts, notably USB host. this uses UHD_USB_INT_LEVEL. i guess thats where i would continue looking.

anyways… yeah i don’t see a problem with that for trilogy/TT/ansible. but we really should know what is causing this.

#40

My gut reaction was that it is in the USB code, but it’s not based on any hard evidence. Just some odd interactions between pressing keys and the “event queue full” message displayed over serial.

Yeah we should. I just haven’t got the time at the moment.

I’ll cut a new Teletype 2.0 beta tomorrow or Wednesday with the change in it, in the hopes that more people test the code. (So that I can be sure it really does fix the issues we’ve seen.)

2 Likes
#41

It sounds very reasonable to me - especially if it keeps the unit from getting totally borked and requiring a reboot. It is clearly a “test it and see” kind of change at this point given your early validation.

I’ll make it a point to ensure that those using expanders are totally clear on the fact that three or more devices requires a powered bus board in order to ensure stability as well. Not related - but can be confused with other problems due to the similarity of symptoms.

You’ve done some damn fine work on this stuff, @sam.

#42

trying to wrap my head around it a bit. i searched for all ISR registrations in TT/asf code and only see the following:

SYS_IRQ_PRIORITY 1 - not used anywhere
APP_TC_IRQ_PRIORITY 2 - timer interrupts
UI_IRQ_PRIORITY 3 - trigger and front panel button interrupts
UDD_USB_INT_LEVEL 0 - USB
UHD_USB_INT_LEVEL 0 - USB
CONF_TWI_IRQ_LEVEL 3 - i2c

hitting trigger inputs at high rate would mean that trigger interrupts are disabled most of the time, which would result in screen not getting refreshed / keyboard less responsive since those are driven by timers (and even then they would probably fail to add an event since the queue is likely full from trigger events). but i don’t understand how changing to SYS_IRQ_PRIORITY results in less crashing… perhaps it’s simply because timer interrupts are not disabled anymore?

how does masking work exactly? does it mask the specified group only or everything above / or below as well? also, what happens if a function disables an interrupt level but while it’s executed another ISR is called which also disables/enables the same level? does that mean that the 2nd ISR would re-enable it while the first ISR still expects it to be disabled?

edit: found some info, if i’m reading correctly 3 is the highest priority and masking does disable the specified level and anything below. so it looks like the change simply stops timer interrupts being disabled when events are added/retrieved… which is strange as i would expect it to be less stable if an event was added while it was already in event_post, and not disabling timers would make this more likely to happen.

3 Likes
#43

Awesome @scanner_darkly

AVR32101: Configuring the AVR32 Interrupt Controller

According to that PDF, interrupts from highest priority to lowest are (page 3):

  • NMI
  • 3
  • 2
  • 1
  • 0

I’ll admit, going by the names in conf_tc_irq.h (below), I’d assumed that SYS_IRQ_PRIORITY had higher priority than UI_IRQ_PRIORITY. My mistake?

#define SYS_IRQ_PRIORITY       1
#define APP_TC_IRQ_PRIORITY    2
#define UI_IRQ_PRIORITY        3

That seems too high then?

Also, reading that document, I’m not entirely sure that masking a given interrupt will disable lower priority ones. Only that it disables the given interrupt.

Also, what exactly is the deal with interrupt groups?

I’m going to do some more tests today.

#44

tl;dr: see the next post

Right while you’re all asleep, I’m going to start systematically working through this…

Test will be an output from Dr. Octature (i.e. self oscillating filter sine wave) into trigger 1.

The contents of script 1 will vary.

I’ll test for a crash by removing the trigger, replugging the keyboard, and seeing if the front panel button works.

09:51am

Clean checkout of b1817b6.

With an empty script 1, crash after a few minutes.

With TR.P 1 in script 1, either a crash or stuck trigger out.

10:11am

Clean checkout of b1817b6. Plus change to init_teletype.c as follows (make the trigger interrupts use APP_TC_IRQ_PRIORITY):

   gpio_enable_pin_interrupt( A07,      GPIO_RISING_EDGE);

   // PA00-A07
-  INTC_register_interrupt( &irq_port0_line0, AVR32_GPIO_IRQ_0, UI_IRQ_PRIORITY);
+  INTC_register_interrupt( &irq_port0_line0, AVR32_GPIO_IRQ_0, APP_TC_IRQ_PRIORITY);

   // PA08 - PA15
-  INTC_register_interrupt( &irq_port0_line1, AVR32_GPIO_IRQ_0 + (AVR32_PIN_PA08 / 8), UI_IRQ_PRIORITY);
+  INTC_register_interrupt( &irq_port0_line1, AVR32_GPIO_IRQ_0 + (AVR32_PIN_PA08 / 8), APP_TC_IRQ_PRIORITY);

   // PB08 - PB15
   // INTC_register_interrupt( &irq_port1_line1, AVR32_GPIO_IRQ_0 + (AVR32_PIN_PB08 / 8), UI_IRQ_PRIORITY);

With TR.P 1 in script 1, no crashes until you do something with the keyboard. And even then typing text works fine, but up or down arrow, or tab crashes immediately. Is it the keyboard or is it the screen drawing? Is it possible that we’re deadlocking on APP_TC_IRQ_PRIORITY somehow?

10:17am

Retesting clean checkout of b1817b6.

Can use the keyboard without causing an immediate crash.

10:27am

Clean b18117b6 with the following change (re-enable GPIO interrupt after event is posted).

diff --git a/src/init_teletype.c b/src/init_teletype.c
index 1dca206..2f762c3 100644
--- a/src/init_teletype.c
+++ b/src/init_teletype.c
@@ -77,10 +77,10 @@ __attribute__((__interrupt__))
 static void irq_port0_line0(void) {
   for(int i=0;i<8;i++) {
     if(gpio_get_pin_interrupt_flag(i)) {
-      gpio_clear_pin_interrupt_flag(i);
       // print_dbg("\r\n # A00");
       event_t e = { .type = kEventTrigger, .data = i };
       event_post(&e);
+      gpio_clear_pin_interrupt_flag(i);
     }
   }
 }
@@ -89,10 +89,10 @@ static void irq_port0_line0(void) {
 __attribute__((__interrupt__))
 static void irq_port0_line1(void) {
     if(gpio_get_pin_interrupt_flag(NMI)) {
-      gpio_clear_pin_interrupt_flag(NMI);
       // print_dbg("\r\n ### NMI ### ");
       event_t e = { .type = kEventFront, .data = gpio_get_pin_value(NMI) };
       event_post(&e);
+      gpio_clear_pin_interrupt_flag(NMI);
     }
 }

Wow, makes a big difference to responsiveness. Some keyboard input get’s through. Sometimes the screen redraws don’t always complete, is that code re-entrant safe?

With TR.P 1 in script 1, trigger output still gets stuck. Haven’t seen any crashes yet though. Regardless I think this change is worth keeping.

10:37am

As 10.27am, but also commenting out all the IRQ masking in events.c

diff --git a/src/events.c b/src/events.c
index 34bff5a..1b2c241 100644
--- a/src/events.c
+++ b/src/events.c
@@ -52,7 +52,7 @@
 // Returns non-zero if an event was available
 u8 event_next( event_t *e ) {
   u8 status;
-  cpu_irq_disable_level(APP_TC_IRQ_PRIORITY);
+  //cpu_irq_disable_level(APP_TC_IRQ_PRIORITY);
   
   // if pointers are equal, the queue is empty... don't allow idx's to wrap!
   if ( getIdx != putIdx ) {
@@ -66,7 +66,7 @@ u8 event_next( event_t *e ) {
     status = false;
   }
 
-  cpu_irq_enable_level(APP_TC_IRQ_PRIORITY);
+  //cpu_irq_enable_level(APP_TC_IRQ_PRIORITY);
   return status;
 }
 
@@ -79,7 +79,7 @@ u8 event_post( event_t *e ) {
    // print_dbg("\r\n posting event, type: ");
    // print_dbg_ulong(e->type);
 
-  cpu_irq_disable_level(APP_TC_IRQ_PRIORITY);
+  //cpu_irq_disable_level(APP_TC_IRQ_PRIORITY);
   
   // increment write idx, posbily wrapping
   saveIndex = putIdx;
@@ -93,7 +93,7 @@ u8 event_post( event_t *e ) {
     putIdx = saveIndex;
   } 
 
-  cpu_irq_enable_level(APP_TC_IRQ_PRIORITY);
+  //cpu_irq_enable_level(APP_TC_IRQ_PRIORITY);
 
   if (!status)
     print_dbg("\r\n event queue full!");

No crashes. Feels dirty. System responsiveness is impressive though.

10:44am

Combination of 10.27am and 10.11am, but not 10.37am.

e.g. trigger inputs at APP_TC_IRQ_PRIORITY and re-enabling GPIO interrupt after event is posted.

Instant lockup as soon as trigger occurs.

11:10am

As 10.27am, but with aggressive interrupt masking:

diff --git a/src/events.c b/src/events.c
index 34bff5a..3901f12 100644
--- a/src/events.c
+++ b/src/events.c
@@ -52,8 +52,9 @@
 // Returns non-zero if an event was available
 u8 event_next( event_t *e ) {
   u8 status;
-  cpu_irq_disable_level(APP_TC_IRQ_PRIORITY);
-  
+
+  irqflags_t flags = cpu_irq_save();
+
   // if pointers are equal, the queue is empty... don't allow idx's to wrap!
   if ( getIdx != putIdx ) {
     INCR_EVENT_INDEX( getIdx );
@@ -66,7 +67,8 @@ u8 event_next( event_t *e ) {
     status = false;
   }
 
-  cpu_irq_enable_level(APP_TC_IRQ_PRIORITY);
+  cpu_irq_restore(flags);
+
   return status;
 }
 
@@ -79,8 +81,8 @@ u8 event_post( event_t *e ) {
    // print_dbg("\r\n posting event, type: ");
    // print_dbg_ulong(e->type);
 
-  cpu_irq_disable_level(APP_TC_IRQ_PRIORITY);
-  
+  irqflags_t flags = cpu_irq_save();
+
   // increment write idx, posbily wrapping
   saveIndex = putIdx;
   INCR_EVENT_INDEX( putIdx );
@@ -93,7 +95,7 @@ u8 event_post( event_t *e ) {
     putIdx = saveIndex;
   } 
 
-  cpu_irq_enable_level(APP_TC_IRQ_PRIORITY);
+  cpu_irq_restore(flags);
 
   if (!status)
     print_dbg("\r\n event queue full!");

Bomb proof again.

cpu_irq_save implicitly disables all interrupts.

FYI @zebra cpu_irq_save is used in a few places in the ASF, e.g. in sysclk, osc, twi, and usbb_host as well as pdca.

11:15am

Have tested the 11:10am code with also changing the GPIO interrupts to APP_TC_IRQ_PRIORITY (see 10.11am).

Everything is still rock solid (c.f. 10.44am)

Conclusions coming up…

11:40am

Once more for luck, so 11:10am code, plus less aggressive IRQ masking.

But saving and restoring mask status

diff --git a/src/events.c b/src/events.c
index 34bff5a..b7777cb 100644
--- a/src/events.c
+++ b/src/events.c
@@ -52,8 +52,13 @@
 // Returns non-zero if an event was available
 u8 event_next( event_t *e ) {
   u8 status;
-  cpu_irq_disable_level(APP_TC_IRQ_PRIORITY);
-  
+
+  bool app_tc = cpu_irq_level_is_enabled(APP_TC_IRQ_PRIORITY);
+  bool ui = cpu_irq_level_is_enabled(UI_IRQ_PRIORITY);
+
+  if (app_tc) cpu_irq_disable_level(APP_TC_IRQ_PRIORITY);
+  if (ui) cpu_irq_disable_level(UI_IRQ_PRIORITY);
+
   // if pointers are equal, the queue is empty... don't allow idx's to wrap!
   if ( getIdx != putIdx ) {
     INCR_EVENT_INDEX( getIdx );
@@ -66,7 +71,9 @@ u8 event_next( event_t *e ) {
     status = false;
   }
 
-  cpu_irq_enable_level(APP_TC_IRQ_PRIORITY);
+  if (app_tc) cpu_irq_enable_level(APP_TC_IRQ_PRIORITY);
+  if (ui) cpu_irq_enable_level(UI_IRQ_PRIORITY);
+
   return status;
 }
 
@@ -79,8 +86,12 @@ u8 event_post( event_t *e ) {
    // print_dbg("\r\n posting event, type: ");
    // print_dbg_ulong(e->type);
 
-  cpu_irq_disable_level(APP_TC_IRQ_PRIORITY);
-  
+  bool app_tc = cpu_irq_level_is_enabled(APP_TC_IRQ_PRIORITY);
+  bool ui = cpu_irq_level_is_enabled(UI_IRQ_PRIORITY);
+
+  if (app_tc) cpu_irq_disable_level(APP_TC_IRQ_PRIORITY);
+  if (ui) cpu_irq_disable_level(UI_IRQ_PRIORITY);
+
   // increment write idx, posbily wrapping
   saveIndex = putIdx;
   INCR_EVENT_INDEX( putIdx );
@@ -93,7 +104,8 @@ u8 event_post( event_t *e ) {
     putIdx = saveIndex;
   } 
 
-  cpu_irq_enable_level(APP_TC_IRQ_PRIORITY);
+  if (app_tc) cpu_irq_enable_level(APP_TC_IRQ_PRIORITY);
+  if (ui) cpu_irq_enable_level(UI_IRQ_PRIORITY);
 
   if (!status)
     print_dbg("\r\n event queue full!");

Rock solid

3 Likes
#45

Okay here is what I’ve figured out.

When you mask an interrupt level, it only masks that level, not lower priority ones too.

(unless someone can point to a document where it contradicts that, proving negative statements is hard…)

Conclusion, either mask all applicable levels, or all interrupts.

Interrupt masks are stored in the ‘status register’ (SR) and are not shadowed/saved in an interrupt

So if you use cpu_irq_disable_level then you should save the existing value to restore it when you cpu_irq_enable_level.

Proposal 1

Make the following change in init_teletype.c:

diff --git a/src/init_teletype.c b/src/init_teletype.c
index 1dca206..2f762c3 100644
--- a/src/init_teletype.c
+++ b/src/init_teletype.c
@@ -77,10 +77,10 @@ __attribute__((__interrupt__))
 static void irq_port0_line0(void) {
   for(int i=0;i<8;i++) {
     if(gpio_get_pin_interrupt_flag(i)) {
-      gpio_clear_pin_interrupt_flag(i);
       // print_dbg("\r\n # A00");
       event_t e = { .type = kEventTrigger, .data = i };
       event_post(&e);
+      gpio_clear_pin_interrupt_flag(i);
     }
   }
 }
@@ -89,10 +89,10 @@ static void irq_port0_line0(void) {
 __attribute__((__interrupt__))
 static void irq_port0_line1(void) {
     if(gpio_get_pin_interrupt_flag(NMI)) {
-      gpio_clear_pin_interrupt_flag(NMI);
       // print_dbg("\r\n ### NMI ### ");
       event_t e = { .type = kEventFront, .data = gpio_get_pin_value(NMI) };
       event_post(&e);
+      gpio_clear_pin_interrupt_flag(NMI);
     }
 }

This isn’t specific to the issue we’re seeing but I think it makes sense, I’d also make it on all the other devices. In effect it also acts as a slight rate limiter on triggers too.

Proposal 2

Mask and restore IRQ levels in events.c. Either by masking/restoring both APP_TC_IRQ_PRIORITY & UI_IRQ_PRIORITY, or by masking/restoring all interrupts.

I’m in favour of masking all interrupts. It’s done it plenty of other places in the ASF (git grep cpu_irq_save), including sysclk, osc, usbb, twi, pdca. I can conceive of scenarios where only masking the 2 levels will still result in issues unless we have constant vigilance against them. So unless someone wants to step up for that responsibility I’d rather take the more extreme approach and make my life easier.

@zebra if you think this is going to cause Aleph big problems, let me know and we can see what we can work out.

I’m going to cut a new release of the Teletype 2.0 beta with those changes in it, just to get it in peoples’ hands for testing. I’ve only got till Saturday before I need to move my Teletype back into it’s case, and then testing becomes really hard.

2 Likes
Teletype 2.0 beta (release candidate 2 released 13th July 2017)
#46

The following commit screws up Ansible:

Basically a TR.PULSE 5, locks the trigger high, and it never comes back down. Though a TR 5 0 will bring it back to 0.

So close… anyone know the Ansible code well enough to tell me why?

edit:

Right, there are a bunch of

cpu_irq_enable_level(APP_TC_IRQ_PRIORITY);
cpu_irq_disable_level(APP_TC_IRQ_PRIORITY);

calls through out the Ansible source code, and also in libavr32.

If my above theories are correct, then that will not be compatible with my flag saving way of doing to same thing.

I’ve commented out all of those calls, and that’s made the trigger pulses work again. That’s obviously very crude. I will try writing a more correct replacement later on today. But I’m would really appreciate some help with testing the Ansible stuff, otherwise I’m fighting on too many fronts.

#47

no, it should be ok.

the whole reason we have separate levels is just to be able to explicitly mask some but not others at certain times, like when we want to stop UI and timer processing while saving to sdcard. the event q crticial section isn’t actually one of those times (though it is important to do something to make sure BEES patches can’t accidentally halt sdcard transfers in the middle of an operation… not your problem)

maybe a clarification about priority levels: as you say, they aren’t nested and masking one doesn’t affect the others. the difference between level 0 and level 3 is that the latter has more shadowed registers, so context changes are faster. thus, higher levels are for interrupts requiring lower latency. SYS_IRQ_LEVEL doesn’t need lowest latency. it’s arguable that UI and APP should be switched.

Basically a TR.PULSE 5, locks the trigger high, and it never comes back down. Though a TR 5 0 will bring it back to 0.

i am not familiar with the ansible code, will have a look though…

1 Like